Thanks everyone, looks like the problem is solved. For benefit of others who may experience same issue, here is what I've done: - upgraded firmware on ST32000542AS disks - from CC34 to CC35. It must be done using onboard SATA in Native IDE (not RAID/AHCI) mode. After reconnecting them back to HBA, size of one of the offenders fixed itself! - ran hdparm -N p3907029168 /dev/sdx command on other two disks and it worked (probably it works straight after reboot) Now mdadm -D shows the array as clean, degraded with one disk kicked out, which is another story :) now need to resync array and restore two LVs which hasn't mounted :( On Tue, Sep 13, 2011 at 8:29 PM, Roman Mamedov <rm@xxxxxxxxxx> wrote: > On Tue, 13 Sep 2011 19:05:41 +1000 > Andriano <chief000@xxxxxxxxx> wrote: > >> Connected one of the offenders to HBA port, and hdparm outputs this: >> >> #hdparm -N /dev/sdh >> >> /dev/sdh: >> max sectors = 3907027055/14715056(18446744073321613488?), HPA >> setting seems invalid (buggy kernel device driver?) > > You could just try "hdparm -N p3907029168" (capacity of the 'larger' disks), but that could fail if the device driver is indeed buggy. > > Another possible course of action would be to try that on some other controller. > For example on your motherboard you have two violet ports, http://www.gigabyte.ru/products/upload/products/1470/100a.jpg > those are managed by the JMicron JMB363 controller, try plugging the disks which need HPA to be removed to those ports, AFAIR that JMicron controller works with "hdparm -N" just fine. > > -- > With respect, > Roman > -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
