Hi.
I've run into a problem with the lastest kernel (2.6.22.1) and a drive set to
spinup on set_features.
..
ATA device, with non-removable media
powers-up in standby; SET FEATURES subcmd spins-up.
Model Number: WDC WD3200JS-57PDB0
Serial Number: X
Firmware Revision: 21.00M21
...
* Power-Up In Standby feature set
* SET_FEATURES required to spinup after power up
...
Jul 12 23:47:22 sysreset kernel: ata6: SATA link up 1.5 Gbps (SStatus 113
SControl 300)
Jul 12 23:47:22 sysreset kernel: ata6.00: ATA-7: WDC WD3200JS-57PDB0, 21.00M21,
max UDMA/133
Jul 12 23:47:22 sysreset kernel: ata6.00: 625142448 sectors, multi 0: LBA48 NCQ
(depth 1)
Jul 12 23:47:22 sysreset kernel: ata6.00: failed to IDENTIFY (SPINUP failed,
err_mask=0x1)
Jul 12 23:47:22 sysreset kernel: ata6.00: revalidation failed (errno=-5)
Jul 12 23:47:22 sysreset kernel: ata6: failed to recover some devices, retrying
in 5 secs
Jul 12 23:47:22 sysreset kernel: ata6: SATA link up 1.5 Gbps (SStatus 113
SControl 300)
Jul 12 23:47:22 sysreset kernel: ata6.00: failed to IDENTIFY (SPINUP failed,
err_mask=0x1)
Jul 12 23:47:22 sysreset kernel: ata6.00: revalidation failed (errno=-5)
Jul 12 23:47:22 sysreset kernel: ata6.00: limiting speed to UDMA/133:PIO3
Jul 12 23:47:22 sysreset kernel: ata6: failed to recover some devices, retrying
in 5 secs
Jul 12 23:47:22 sysreset kernel: ata6: SATA link up 1.5 Gbps (SStatus 113
SControl 300)
Jul 12 23:47:22 sysreset kernel: ata6.00: failed to IDENTIFY (SPINUP failed,
err_mask=0x1)
Jul 12 23:47:22 sysreset kernel: ata6.00: revalidation failed (errno=-5)
Jul 12 23:47:22 sysreset kernel: ata6.00: disabled
It would be handy to see those messages again with real timestamps on them.
Ryan, could you add CONFIG_PRINTK_TIME=y into your .config and rebuild/retry ?
The interesting thing is that after displaying that, the drive has in fact spun
up.
I'm not sure why it's getting an error returned, but chaning the err_mask line
to read "if (err_mask && err_mask != 0x01)" corrects the problem and the drive
spins up and ID's normally:
Yeah, I believe that for WD drives. Their firmware has *always* been peculiar.
In fact, the WD Raptor drives I used to have here had similar, though not
identical,
problems with the "jumper-enabled" power-on-in-standby version. I never did
figure
those ones out.
But yes, perhaps your suggestion of just ignoring the device's response
may be best. Are you sure it spins up on the very first attempt?
Also, could you add this printk() line to just before your err_mask hack:
printk("id[2]=0x%04x\n", id[2]);
If we see 0x738c reported from that, then we *know* we should just continue
rather than err'ing out as is presently done.
Thanks
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
