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