| Message ID | 20110217095815.GN19830@htj.dyndns.org |
|---|---|
| State | Not Applicable |
| Delegated to: | David Miller |
| Headers | show |
On Thu, 17 Feb 2011 10:58:15 +0100, Tejun Heo wrote: > Hello, > > On Thu, Feb 17, 2011 at 03:23:13PM +1100, Steven Haigh wrote: >> I might have acted a bit prematurely on this. After booting off the >> CentOS 5.5 installation DVD, I noticed that the esata drive at the >> same problem. After lots of cable swapping and testing, I have found >> that the esata cable may be faulty as a direct SATA -> drive >> connection works perfectly. >> >> I am unsure however why my previous test of plugging the esata drive >> directly to the onboard SATA controller worked - however now this >> also fails. >> >> I shall attempt to try some different eSATA cables and report back >> if I manage to isolate the issue directly to the sata_sil module. > > It's probably dependent on timing and not completely reliable. It's > rather complicated. The AC_ERR_NODEV_HINT thing is there primarily > for PATA controllers so that they don't spend time trying to probe > empty ports. > > Does the following patch resolve the problem? > > diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c > index d4e52e2..d08383f 100644 > --- a/drivers/ata/libata-core.c > +++ b/drivers/ata/libata-core.c > @@ -1908,7 +1908,13 @@ retry: > err_mask = ata_do_dev_read_id(dev, &tf, id); > > if (err_mask) { > - if (err_mask & AC_ERR_NODEV_HINT) { > + /* > + * AC_ERR_NODEV_HINT is primarily used to detect empty PATA > + * ports. Some SATA devices incorrectly trigger it. > + * Ignore if the physical link is positively online. > + */ > + if ((err_mask & AC_ERR_NODEV_HINT) && > + !ata_phys_link_online(ata_dev_phys_link(dev))) { > ata_dev_printk(dev, KERN_DEBUG, > "NODEV after polling detection\n"); > return -ENOENT; With this patch applied, my rebuilt kernel based on 2.6.32.26 (due to Xen Dom0 requirements) gives the following: ata9: exception Emask 0x10 SAct 0x0 SErr 0x50000 action 0xe frozen ata9: SError: { PHYRdyChg CommWake } ata9: hard resetting link ata9: SATA link up 1.5 Gbps (SStatus 113 SControl 310) ata9.00: failed to IDENTIFY (I/O error, err_mask=0x202) ata9: hard resetting link ata9: SATA link up 1.5 Gbps (SStatus 113 SControl 310) ata9.00: failed to IDENTIFY (I/O error, err_mask=0x202) ata9: hard resetting link ata9: SATA link up 1.5 Gbps (SStatus 113 SControl 310) ata9.00: failed to IDENTIFY (I/O error, err_mask=0x202) ata9: hard resetting link ata9: SATA link up 1.5 Gbps (SStatus 113 SControl 310) ata9: EH complete I would really like to eliminate the possibility of it being my esata enclosure or the sata -> esata cable by using another cable and/or array for testing. New cables will be a few days off as I don't have any of these cables hanging around. My gut feeling says its the cable - as the enclosure works fine via the USB port - however that isn't conlusive proof that the esata port is working as it should! -- Steven Haigh Email: netwiz@crc.id.au Web: http://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897 Fax: (03) 8338 0299 -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello, On Fri, Feb 18, 2011 at 10:20:43AM +1100, Steven Haigh wrote: > With this patch applied, my rebuilt kernel based on 2.6.32.26 (due > to Xen Dom0 requirements) gives the following: > > ata9: exception Emask 0x10 SAct 0x0 SErr 0x50000 action 0xe frozen > ata9: SError: { PHYRdyChg CommWake } > ata9: hard resetting link > ata9: SATA link up 1.5 Gbps (SStatus 113 SControl 310) > ata9.00: failed to IDENTIFY (I/O error, err_mask=0x202) > ata9: hard resetting link > ata9: SATA link up 1.5 Gbps (SStatus 113 SControl 310) > ata9.00: failed to IDENTIFY (I/O error, err_mask=0x202) > ata9: hard resetting link > ata9: SATA link up 1.5 Gbps (SStatus 113 SControl 310) > ata9.00: failed to IDENTIFY (I/O error, err_mask=0x202) > ata9: hard resetting link > ata9: SATA link up 1.5 Gbps (SStatus 113 SControl 310) > ata9: EH complete So, retrying doesn't help at all. > I would really like to eliminate the possibility of it being my > esata enclosure or the sata -> esata cable by using another cable > and/or array for testing. New cables will be a few days off as I > don't have any of these cables hanging around. My gut feeling says > its the cable - as the enclosure works fine via the USB port - > however that isn't conlusive proof that the esata port is working as > it should! Yeah, it looks like something is wrong with the setup. Please let us know how the testing goes with the new cable (hopefully shorter). Thanks.
On 18/02/2011 8:16 PM, Tejun Heo wrote: > Hello, > > On Fri, Feb 18, 2011 at 10:20:43AM +1100, Steven Haigh wrote: >> With this patch applied, my rebuilt kernel based on 2.6.32.26 (due >> to Xen Dom0 requirements) gives the following: >> >> ata9: exception Emask 0x10 SAct 0x0 SErr 0x50000 action 0xe frozen >> ata9: SError: { PHYRdyChg CommWake } >> ata9: hard resetting link >> ata9: SATA link up 1.5 Gbps (SStatus 113 SControl 310) >> ata9.00: failed to IDENTIFY (I/O error, err_mask=0x202) >> ata9: hard resetting link >> ata9: SATA link up 1.5 Gbps (SStatus 113 SControl 310) >> ata9.00: failed to IDENTIFY (I/O error, err_mask=0x202) >> ata9: hard resetting link >> ata9: SATA link up 1.5 Gbps (SStatus 113 SControl 310) >> ata9.00: failed to IDENTIFY (I/O error, err_mask=0x202) >> ata9: hard resetting link >> ata9: SATA link up 1.5 Gbps (SStatus 113 SControl 310) >> ata9: EH complete > > So, retrying doesn't help at all. > >> I would really like to eliminate the possibility of it being my >> esata enclosure or the sata -> esata cable by using another cable >> and/or array for testing. New cables will be a few days off as I >> don't have any of these cables hanging around. My gut feeling says >> its the cable - as the enclosure works fine via the USB port - >> however that isn't conlusive proof that the esata port is working as >> it should! > > Yeah, it looks like something is wrong with the setup. Please let us > know how the testing goes with the new cable (hopefully shorter). Hmmm - the replacement SATA -> eSATA cables arrived today and I still get the same problem. On a whim, I connected the same cable + adapter + cradle to my i7 system running Fedora 14. This is not a sata_sil based adapter, but I believe it may rule out both the cable & the cradle as faulty. [ 371.217646] ata6: exception Emask 0x10 SAct 0x0 SErr 0x4050002 action 0xe frozen [ 371.217700] ata6: irq_stat 0x00000040, connection status changed [ 371.217750] ata6: SError: { RecovComm PHYRdyChg CommWake DevExch } [ 371.217807] ata6: hard resetting link [ 376.326257] ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 376.347413] ata6.00: ATA-7: HDS728080PLA380, PF2OA60A, max UDMA/133 [ 376.347417] ata6.00: 160836480 sectors, multi 0: LBA48 [ 376.356485] ata6.00: failed to IDENTIFY (I/O error, err_mask=0x100) [ 376.356490] ata6.00: revalidation failed (errno=-5) [ 381.324129] ata6: hard resetting link [ 381.629014] ata6: SATA link down (SStatus 0 SControl 300) [ 381.629022] ata6: limiting SATA link speed to 1.5 Gbps [ 386.626909] ata6: hard resetting link [ 387.494543] ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 310) [ 387.533074] ata6.00: configured for UDMA/133 [ 387.533082] ata6: EH complete [ 387.533262] scsi 5:0:0:0: Direct-Access ATA HDS728080PLA380 PF2O PQ: 0 ANSI: 5 [ 387.533504] sd 5:0:0:0: Attached scsi generic sg3 type 0 [ 387.533721] sd 5:0:0:0: [sdc] 160836480 512-byte logical blocks: (82.3 GB/76.6 GiB) [ 387.533790] sd 5:0:0:0: [sdc] Write Protect is off [ 387.533794] sd 5:0:0:0: [sdc] Mode Sense: 00 3a 00 00 [ 387.533823] sd 5:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 387.534037] sdc: sdc1 [ 387.549830] sd 5:0:0:0: [sdc] Attached SCSI disk I found it interesting that the drive failed to ident multiple times, however retrying eventually worked. Could it just be that the cradle is slow to initialise and therefore the sata_sil adapter gives up before the cradle is actually ready? Following this logic, I tried powering up the cradle before connecting the esata cable. I don't see anything in dmesg connecting the esata cable AFTER the cradle has been powered on. Maybe the cradle disables the esata connection if theres no cable connected on powerup?
Hello, On Thu, Feb 24, 2011 at 01:24:21PM +1100, Steven Haigh wrote: > >Yeah, it looks like something is wrong with the setup. Please let us > >know how the testing goes with the new cable (hopefully shorter). > > Hmmm - the replacement SATA -> eSATA cables arrived today and I > still get the same problem. On a whim, I connected the same cable + > adapter + cradle to my i7 system running Fedora 14. This is not a > sata_sil based adapter, but I believe it may rule out both the cable > & the cradle as faulty. Hmmm... > [ 371.217646] ata6: exception Emask 0x10 SAct 0x0 SErr 0x4050002 > action 0xe frozen > [ 371.217700] ata6: irq_stat 0x00000040, connection status changed > [ 371.217750] ata6: SError: { RecovComm PHYRdyChg CommWake DevExch } > [ 371.217807] ata6: hard resetting link > [ 376.326257] ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 300) > [ 376.347413] ata6.00: ATA-7: HDS728080PLA380, PF2OA60A, max UDMA/133 > [ 376.347417] ata6.00: 160836480 sectors, multi 0: LBA48 > [ 376.356485] ata6.00: failed to IDENTIFY (I/O error, err_mask=0x100) > [ 376.356490] ata6.00: revalidation failed (errno=-5) > [ 381.324129] ata6: hard resetting link > [ 381.629014] ata6: SATA link down (SStatus 0 SControl 300) > [ 381.629022] ata6: limiting SATA link speed to 1.5 Gbps > [ 386.626909] ata6: hard resetting link > [ 387.494543] ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 310) > [ 387.533074] ata6.00: configured for UDMA/133 > [ 387.533082] ata6: EH complete > [ 387.533262] scsi 5:0:0:0: Direct-Access ATA > HDS728080PLA380 PF2O PQ: 0 ANSI: 5 > [ 387.533504] sd 5:0:0:0: Attached scsi generic sg3 type 0 > [ 387.533721] sd 5:0:0:0: [sdc] 160836480 512-byte logical blocks: > (82.3 GB/76.6 GiB) > [ 387.533790] sd 5:0:0:0: [sdc] Write Protect is off > [ 387.533794] sd 5:0:0:0: [sdc] Mode Sense: 00 3a 00 00 > [ 387.533823] sd 5:0:0:0: [sdc] Write cache: enabled, read cache: > enabled, doesn't support DPO or FUA > [ 387.534037] sdc: sdc1 > [ 387.549830] sd 5:0:0:0: [sdc] Attached SCSI disk > > I found it interesting that the drive failed to ident multiple > times, however retrying eventually worked. Well, yeah, IDENTIFY failure is still there. Controllers behave differently and some may have higher tolerance under certain circumstances but the setup just seems quite flimsy for whatever reason. > Could it just be that the cradle is slow to initialise and therefore > the sata_sil adapter gives up before the cradle is actually ready? > > Following this logic, I tried powering up the cradle before > connecting the esata cable. I don't see anything in dmesg connecting > the esata cable AFTER the cradle has been powered on. Maybe the > cradle disables the esata connection if theres no cable connected on > powerup? Is the cradle an active device or is it just power supply + eSATA->SATA gender? Oh, right, you said it also had USB connection, so it's an active device. Can you open it up and see which chip is there? Thanks.
On 24/02/2011 7:31 PM, Tejun Heo wrote: > Well, yeah, IDENTIFY failure is still there. Controllers behave > differently and some may have higher tolerance under certain > circumstances but the setup just seems quite flimsy for whatever > reason. Yeah - I noticed that. These things can never be simple, can they?! >> Could it just be that the cradle is slow to initialise and therefore >> the sata_sil adapter gives up before the cradle is actually ready? >> >> Following this logic, I tried powering up the cradle before >> connecting the esata cable. I don't see anything in dmesg connecting >> the esata cable AFTER the cradle has been powered on. Maybe the >> cradle disables the esata connection if theres no cable connected on >> powerup? > > Is the cradle an active device or is it just power supply + > eSATA->SATA gender? Oh, right, you said it also had USB connection, > so it's an active device. Can you open it up and see which chip is > there? Of course I can crack it open - thats what makes life fun! The top side of the internal PCB is fairly plain with just the SATA power & data sockets on it and the various USB ports and card sockets on the front. On the rear, we have a 30Mhz and a 12Mhz oscillator and 3 main CPU type chips. Near the card readers: GL826 / MX2AE08G08 / 842H35518 - I assume this is the IDE / CF / card IO chip. Near the rear: JMB352 / 0834 LGBA1 A / 370JF3011 - This looks to be hooked up via some capacitors to the DATA data lines on both sockets. If I haven't mentioned before, this is a 2 x SATA drive bay cradle. A third tiny chip near the JMB352 is: GL850A / MN2FA01G11 / 911SK03111 - Not 100% sure of the function of this chip by following the tracks, but it looks like it might be some kind of a clock source. That is a wild guess though! If you need photos, let me know and I'll make some up.
Hello, (cc'ing Justin) On Thu, Feb 24, 2011 at 08:53:15PM +1100, Steven Haigh wrote: > On 24/02/2011 7:31 PM, Tejun Heo wrote: > >Well, yeah, IDENTIFY failure is still there. Controllers behave > >differently and some may have higher tolerance under certain > >circumstances but the setup just seems quite flimsy for whatever > >reason. > > Yeah - I noticed that. These things can never be simple, can they?! > > >>Could it just be that the cradle is slow to initialise and therefore > >>the sata_sil adapter gives up before the cradle is actually ready? > >> > >>Following this logic, I tried powering up the cradle before > >>connecting the esata cable. I don't see anything in dmesg connecting > >>the esata cable AFTER the cradle has been powered on. Maybe the > >>cradle disables the esata connection if theres no cable connected on > >>powerup? > > > >Is the cradle an active device or is it just power supply + > >eSATA->SATA gender? Oh, right, you said it also had USB connection, > >so it's an active device. Can you open it up and see which chip is > >there? > > Of course I can crack it open - thats what makes life fun! > > The top side of the internal PCB is fairly plain with just the SATA > power & data sockets on it and the various USB ports and card > sockets on the front. > > On the rear, we have a 30Mhz and a 12Mhz oscillator and 3 main CPU > type chips. > > Near the card readers: > GL826 / MX2AE08G08 / 842H35518 - I assume this is the IDE / CF / > card IO chip. Yeah, that's the card reader. > Near the rear: > JMB352 / 0834 LGBA1 A / 370JF3011 - This looks to be hooked up via > some capacitors to the DATA data lines on both sockets. If I haven't > mentioned before, this is a 2 x SATA drive bay cradle. This is the SATA part. > A third tiny chip near the JMB352 is: > GL850A / MN2FA01G11 / 911SK03111 - Not 100% sure of the function of > this chip by following the tracks, but it looks like it might be > some kind of a clock source. That is a wild guess though! This is USB thingie. So, the offending part is JMB352. Justin, when JMB352 is doing e-SATA interface, it's failing IDENTIFY. sata_sil fails to recognize it and ahci (right? Steven) succeeds only after IDENTIFY failures and retries. Any ideas what's going on? When doing e-SATA, is the chip active or passive? ie. Does it just pass through the signals or do some meddling inbetween? Thanks.
On 11-02-24 05:06 AM, Tejun Heo wrote: > >> Near the rear: >> JMB352 / 0834 LGBA1 A / 370JF3011 - This looks to be hooked up via >> some capacitors to the DATA data lines on both sockets. If I haven't >> mentioned before, this is a 2 x SATA drive bay cradle. > > This is the SATA part. > >> A third tiny chip near the JMB352 is: >> GL850A / MN2FA01G11 / 911SK03111 - Not 100% sure of the function of >> this chip by following the tracks, but it looks like it might be >> some kind of a clock source. That is a wild guess though! > > This is USB thingie. > > So, the offending part is JMB352. Justin, when JMB352 is doing e-SATA > interface, it's failing IDENTIFY. sata_sil fails to recognize it and > ahci (right? Steven) succeeds only after IDENTIFY failures and > retries. Any ideas what's going on? When doing e-SATA, is the chip > active or passive? ie. Does it just pass through the signals or do > some meddling inbetween? Since this is a dual-SATA device, does it have TWO eSATA ports at the back, or just one? If the latter, then I'd expect to find a port-multiplier in the chain. Cheers -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 25/02/2011 3:21 AM, Mark Lord wrote: > On 11-02-24 05:06 AM, Tejun Heo wrote: >> >>> Near the rear: >>> JMB352 / 0834 LGBA1 A / 370JF3011 - This looks to be hooked up via >>> some capacitors to the DATA data lines on both sockets. If I haven't >>> mentioned before, this is a 2 x SATA drive bay cradle. >> >> This is the SATA part. >> >>> A third tiny chip near the JMB352 is: >>> GL850A / MN2FA01G11 / 911SK03111 - Not 100% sure of the function of >>> this chip by following the tracks, but it looks like it might be >>> some kind of a clock source. That is a wild guess though! >> >> This is USB thingie. >> >> So, the offending part is JMB352. Justin, when JMB352 is doing e-SATA >> interface, it's failing IDENTIFY. sata_sil fails to recognize it and >> ahci (right? Steven) succeeds only after IDENTIFY failures and >> retries. Any ideas what's going on? When doing e-SATA, is the chip >> active or passive? ie. Does it just pass through the signals or do >> some meddling inbetween? > > > Since this is a dual-SATA device, does it have TWO eSATA ports at the back, > or just one? If the latter, then I'd expect to find a port-multiplier in the chain. Hi Mark, There is only one eSATA port on the back of the cradle. From looking at the specs of the JMB352[1], it seems that it has the capability to have 3 SATA channels. Two are used for the cradle bays, the third for the uplink to the PC. The PDF states: "The SATA controller could be configured as host or device. The 3-port SATA II 3.0G controllers further supports the eSATA to dual SATA communication." [1] - http://www.jmicron.com/PDF/JMB352/JMB352.pdf
On 11-02-24 11:29 AM, Steven Haigh wrote: > > There is only one eSATA port on the back of the cradle. From looking at the > specs of the JMB352[1], it seems that it has the capability to have 3 SATA > channels. Two are used for the cradle bays, the third for the uplink to the PC. > > The PDF states: > "The SATA controller could be configured as host or device. The > 3-port SATA II 3.0G controllers further supports the eSATA to dual SATA > communication." > > [1] - http://www.jmicron.com/PDF/JMB352/JMB352.pdf It would be nice to know what that actually means. The only standard way for a single eSATA to connect to two SATA is via a SATA Port Multiplier. I wonder if that chip implements one? -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11-02-24 02:04 PM, Mark Lord wrote: > On 11-02-24 11:29 AM, Steven Haigh wrote: >> >> There is only one eSATA port on the back of the cradle. From looking at the >> specs of the JMB352[1], it seems that it has the capability to have 3 SATA >> channels. Two are used for the cradle bays, the third for the uplink to the PC. >> >> The PDF states: >> "The SATA controller could be configured as host or device. The >> 3-port SATA II 3.0G controllers further supports the eSATA to dual SATA >> communication." >> >> [1] - http://www.jmicron.com/PDF/JMB352/JMB352.pdf > > > It would be nice to know what that actually means. > The only standard way for a single eSATA to connect to two SATA > is via a SATA Port Multiplier. I wonder if that chip implements one? The product brief lists possible operation modes of the chip as: -- RAID0, RAID1, JBOD, or Port Multiplier So I would guess that the drive detection issues must have something to do with the operation mode. I wonder how one selects *which* mode should be used by the chip? Or quite likely the only hardware mode is "Port Multiplier", and the rest are just fakeraid things in software. You and Tejun ought to be able to collect some debugging info (eg. initial ATA register state on probe) to see if the device even tries to report itself as a port multiplier. Tricky stuff, undocumented hardware. -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 24/02/2011 9:06 PM, Tejun Heo wrote: > Hello, > > (cc'ing Justin) > > On Thu, Feb 24, 2011 at 08:53:15PM +1100, Steven Haigh wrote: >> On 24/02/2011 7:31 PM, Tejun Heo wrote: >>> Well, yeah, IDENTIFY failure is still there. Controllers behave >>> differently and some may have higher tolerance under certain >>> circumstances but the setup just seems quite flimsy for whatever >>> reason. >> >> Yeah - I noticed that. These things can never be simple, can they?! >> >>>> Could it just be that the cradle is slow to initialise and therefore >>>> the sata_sil adapter gives up before the cradle is actually ready? >>>> >>>> Following this logic, I tried powering up the cradle before >>>> connecting the esata cable. I don't see anything in dmesg connecting >>>> the esata cable AFTER the cradle has been powered on. Maybe the >>>> cradle disables the esata connection if theres no cable connected on >>>> powerup? >>> >>> Is the cradle an active device or is it just power supply + >>> eSATA->SATA gender? Oh, right, you said it also had USB connection, >>> so it's an active device. Can you open it up and see which chip is >>> there? >> >> Of course I can crack it open - thats what makes life fun! >> >> The top side of the internal PCB is fairly plain with just the SATA >> power& data sockets on it and the various USB ports and card >> sockets on the front. >> >> On the rear, we have a 30Mhz and a 12Mhz oscillator and 3 main CPU >> type chips. >> >> Near the card readers: >> GL826 / MX2AE08G08 / 842H35518 - I assume this is the IDE / CF / >> card IO chip. > > Yeah, that's the card reader. > >> Near the rear: >> JMB352 / 0834 LGBA1 A / 370JF3011 - This looks to be hooked up via >> some capacitors to the DATA data lines on both sockets. If I haven't >> mentioned before, this is a 2 x SATA drive bay cradle. > > This is the SATA part. > >> A third tiny chip near the JMB352 is: >> GL850A / MN2FA01G11 / 911SK03111 - Not 100% sure of the function of >> this chip by following the tracks, but it looks like it might be >> some kind of a clock source. That is a wild guess though! > > This is USB thingie. > > So, the offending part is JMB352. Justin, when JMB352 is doing e-SATA > interface, it's failing IDENTIFY. sata_sil fails to recognize it and > ahci (right? Steven) succeeds only after IDENTIFY failures and > retries. Any ideas what's going on? When doing e-SATA, is the chip > active or passive? ie. Does it just pass through the signals or do > some meddling inbetween? Has there been any progress on this as yet? I haven't heard anything in a while...
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c index d4e52e2..d08383f 100644 --- a/drivers/ata/libata-core.c +++ b/drivers/ata/libata-core.c @@ -1908,7 +1908,13 @@ retry: err_mask = ata_do_dev_read_id(dev, &tf, id); if (err_mask) { - if (err_mask & AC_ERR_NODEV_HINT) { + /* + * AC_ERR_NODEV_HINT is primarily used to detect empty PATA + * ports. Some SATA devices incorrectly trigger it. + * Ignore if the physical link is positively online. + */ + if ((err_mask & AC_ERR_NODEV_HINT) && + !ata_phys_link_online(ata_dev_phys_link(dev))) { ata_dev_printk(dev, KERN_DEBUG, "NODEV after polling detection\n"); return -ENOENT;