2.6.28-rc3 libata: still "failed to IDENTIFY" on bootup

2.6.28-rc3 libata: still "failed to IDENTIFY" on bootup

[Andreas Mohr]

Hello all,

on my Inspiron 8000, I keep getting this on bootup (including the
ensuing 3 x 5 second delay!):

ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xbfa0 irq 14
ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xbfa8 irq 15
Switched to high resolution mode on CPU 0
ata1.00: ATA-6: IC25N060ATMR04-0, MO3OAD0A, max UDMA/100
ata1.00: 117210240 sectors, multi 8: LBA48
ata1.01: ATAPI: TOSHIBA DVD-ROM SD-C2402, X021, max UDMA/33
ata1.00: configured for UDMA/100
ata1.01: configured for UDMA/33
ata2.01: failed to IDENTIFY (I/O error, err_mask=0x1)
ata2.01: failed to IDENTIFY (I/O error, err_mask=0x1)
ata2.01: failed to IDENTIFY (I/O error, err_mask=0x1)
ata2.00: ATAPI: SONY    CD-RW  CRX700E, 1.4u, max MWDMA2
ata2.00: configured for MWDMA2

This did not occur with kernels <= config-2.6.24-rc6 and did occur with _all_
kernels >= config-2.6.26-rc5, if I'm not entirely mistaken (I believe there has been
a large libata update in between).

# hdparm -I /dev/sr1

/dev/sr1:

ATAPI CD-ROM, with removable media
        Model Number:       SONY    CD-RW  CRX700E
        Firmware Revision:  1.4u
Standards:
        Likely used CD-ROM ATAPI-1
Configuration:
        DRQ response: 50us.
        Packet size: 12 bytes
Capabilities:
        LBA, IORDY(can be disabled)
        DMA: sdma0 sdma1 sdma2 mdma0 mdma1 *mdma2
             Cycle time: min=120ns recommended=120ns
        PIO: pio0 pio1 pio2 pio3 pio4
             Cycle time: no flow control=180ns  IORDY flow control=120ns
  


As you can see, ata2.00 AKA /dev/sr1 is a single-drive controller setup,
if only I knew whether it's hardware-configured
as Master / Slave or Cable Select...


Earlier kernels did not have any IDENTIFY bootup delay (both old-style ide
and my earlier libata configurations!), but I assume this ""problem"" occured
due to some _increase_ in verification functionality in later kernels,
not due to some stupid bug.

So, since earlier kernels did not annoy me with a 15-second delay
since they didn't detect a problematic controller port configuration,
what can we do about this now?

How can I figure out my controller configuration? The drive in question
is a removeable notebook CD writer.

If this turns out to be (e.g.) an "illegal" Master-only configuration
(thus with a "phantom" second drive), then is there a way to blacklist
(DMI etc.) my notebook model for this check?
And what if this happens to be a "legal" Cable Select setup which thus
shouldn't trigger this IDENTIFY problem?

Further thoughts?

Thanks a lot for your very nice ATA/IDE work,

Andreas Mohr

Re: 2.6.28-rc3 libata: still "failed to IDENTIFY" on bootup

[Tejun Heo]

Andreas Mohr wrote:
> on my Inspiron 8000, I keep getting this on bootup (including the
> ensuing 3 x 5 second delay!):
> 
> ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xbfa0 irq 14
> ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xbfa8 irq 15
> Switched to high resolution mode on CPU 0
> ata1.00: ATA-6: IC25N060ATMR04-0, MO3OAD0A, max UDMA/100
> ata1.00: 117210240 sectors, multi 8: LBA48
> ata1.01: ATAPI: TOSHIBA DVD-ROM SD-C2402, X021, max UDMA/33
> ata1.00: configured for UDMA/100
> ata1.01: configured for UDMA/33
> ata2.01: failed to IDENTIFY (I/O error, err_mask=0x1)
> ata2.01: failed to IDENTIFY (I/O error, err_mask=0x1)
> ata2.01: failed to IDENTIFY (I/O error, err_mask=0x1)
> ata2.00: ATAPI: SONY    CD-RW  CRX700E, 1.4u, max MWDMA2
> ata2.00: configured for MWDMA2
> 
> This did not occur with kernels <= config-2.6.24-rc6 and did occur
> with _all_ kernels >= config-2.6.26-rc5, if I'm not entirely
> mistaken (I believe there has been a large libata update in
> between).
> 
> # hdparm -I /dev/sr1
> 
> /dev/sr1:
> 
> ATAPI CD-ROM, with removable media
>         Model Number:       SONY    CD-RW  CRX700E
>         Firmware Revision:  1.4u
> Standards:
>         Likely used CD-ROM ATAPI-1
> Configuration:
>         DRQ response: 50us.
>         Packet size: 12 bytes
> Capabilities:
>         LBA, IORDY(can be disabled)
>         DMA: sdma0 sdma1 sdma2 mdma0 mdma1 *mdma2
>              Cycle time: min=120ns recommended=120ns
>         PIO: pio0 pio1 pio2 pio3 pio4
>              Cycle time: no flow control=180ns  IORDY flow control=120ns
>   
> 
> As you can see, ata2.00 AKA /dev/sr1 is a single-drive controller setup,
> if only I knew whether it's hardware-configured
> as Master / Slave or Cable Select...
> 
> Earlier kernels did not have any IDENTIFY bootup delay (both old-style ide
> and my earlier libata configurations!), but I assume this ""problem"" occured
> due to some _increase_ in verification functionality in later kernels,
> not due to some stupid bug.
> 
> So, since earlier kernels did not annoy me with a 15-second delay
> since they didn't detect a problematic controller port configuration,
> what can we do about this now?
> 
> How can I figure out my controller configuration? The drive in question
> is a removeable notebook CD writer.
> 
> If this turns out to be (e.g.) an "illegal" Master-only configuration
> (thus with a "phantom" second drive), then is there a way to blacklist
> (DMI etc.) my notebook model for this check?
> And what if this happens to be a "legal" Cable Select setup which thus
> shouldn't trigger this IDENTIFY problem?

Hmm... this is our second report on phantom device problem.  I thought
the initial one was controller/device specific but it looks like we
genuinely screwed up something here.  Can you please post the result
of "lspci -nn" and full kernel boot log?

Thanks.

-- 
tejun

Re: 2.6.28-rc3 libata: still "failed to IDENTIFY" on bootup

[Andreas Mohr]

[-- Attachment #1: Type: text/plain, Size: 1336 bytes --]

Hi,

On Tue, Nov 11, 2008 at 06:36:30PM +0900, Tejun Heo wrote:
> Andreas Mohr wrote:
> > If this turns out to be (e.g.) an "illegal" Master-only configuration
> > (thus with a "phantom" second drive), then is there a way to blacklist
> > (DMI etc.) my notebook model for this check?
> > And what if this happens to be a "legal" Cable Select setup which thus
> > shouldn't trigger this IDENTIFY problem?
> 
> Hmm... this is our second report on phantom device problem.  I thought
> the initial one was controller/device specific but it looks like we
> genuinely screwed up something here.  Can you please post the result
> of "lspci -nn" and full kernel boot log?

Attached.

But, yeah, it could just be an illegal factory-shipped hardware config, ya know
(need to investigate actual setup here, maybe it turns out to be
"combined Master/Slave" jumpering - with one Master drive only...)

Oh, and don't worry about the ominous
Maestro3: probe of 0000:02:03.0 failed with error -2
line - that's just yet another nice unrelated and unreported regression killing
my entire sound support... ;P
(I'm hitting kernel bugs and regressions left and right - and center! - lately;
no. 5 or 6 or even 7 in the last 2+ weeks, I stopped counting)
(just to clarify: the IDENTIFY issue here is _not_ a new regression OTOH)

Thanks a lot,

Andreas Mohr

[-- Attachment #2: dmesg.log.gz --]
[-- Type: application/x-gzip, Size: 16161 bytes --]

[-- Attachment #3: lspci_nn.log --]
[-- Type: text/plain, Size: 1202 bytes --]

00:00.0 Host bridge [0600]: Intel Corporation 82815 815 Chipset Host Bridge and Memory Controller Hub [8086:1130] (rev 02)
00:01.0 PCI bridge [0604]: Intel Corporation 82815 815 Chipset AGP Bridge [8086:1131] (rev 02)
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev 02)
00:1f.0 ISA bridge [0601]: Intel Corporation 82801BAM ISA Bridge (LPC) [8086:244c] (rev 02)
00:1f.1 IDE interface [0101]: Intel Corporation 82801BAM IDE U100 Controller [8086:244a] (rev 02)
00:1f.2 USB Controller [0c03]: Intel Corporation 82801BA/BAM USB Controller #1 [8086:2442] (rev 02)
01:00.0 VGA compatible controller [0300]: ATI Technologies Inc Rage Mobility M4 AGP [1002:4d46]
02:03.0 Multimedia audio controller [0401]: ESS Technology ES1983S Maestro-3i PCI Audio Accelerator [125d:1998] (rev 10)
02:06.0 Network controller [0280]: Texas Instruments ACX 100 22Mbps Wireless Interface [104c:8400]
02:0f.0 CardBus bridge [0607]: Texas Instruments PCI4451 PC card Cardbus Controller [104c:ac42]
02:0f.1 CardBus bridge [0607]: Texas Instruments PCI4451 PC card Cardbus Controller [104c:ac42]
02:0f.2 FireWire (IEEE 1394) [0c00]: Texas Instruments PCI4451 IEEE-1394 Controller [104c:8027]

Re: 2.6.28-rc3 libata: still "failed to IDENTIFY" on bootup

[Andreas Mohr]

Hi,

On Tue, Nov 11, 2008 at 05:11:13PM +0100, Andreas Mohr wrote:
> But, yeah, it could just be an illegal factory-shipped hardware config, ya know
> (need to investigate actual setup here, maybe it turns out to be
> "combined Master/Slave" jumpering - with one Master drive only...)

OK, I researched this some more.

When booting with the CDRW removed from the slot the IDENTIFY issue
does NOT occur!
This drive (Dell P/N 996NF) does not have any hardware jumper, but
probably is configured via firmware variants (like many notebook drives
seem to be).
Visited BIOS settings, no clues or settings there.
Not the faintest clue as to what the drive is configured as internally,
although many notebook drives seem to be shipped as Cable Select (but definitely
not all!!).


At http://www.clave.gr.jp/ml/bsd-nomads/200011/msg00068.html , it's BSD(!)
which is showing an identify retried exceeded error with the CRX700E !!!!
Note that this seems to be a THINKPAD here, thus the other OEM (IBM) which there
are CRX700E firmware updates available for.


Some remotely useful (added for reference) URLs might be
http://forums.techguy.org/hardware/348262-dell-2nd-hd-media-bay.html
http://www.notebook-doctor.com/it-pi-n-DVD_Writer_for_Dell_Latitude_D510-pId-238000.html
http://www.motherboardpoint.com/t43872-dimension-8200-is-it-cable-select.html
http://www.wer-weiss-was.de/theme21/article4243889.html


Hmm, now if this drive happened to be configured as Cable Select as I'd guess it is:
do we have a problem here?? IOW are we mis-handling non-explicitly configured
(i.e., CSEL) setups?

...but:
when searching for the "identify retried exceeded" BSD error message
the CRX700E-mentioning page is the _only_ one that comes up on Google!!
(IOW, it strongly looks like this issue seems quite isolated to CRX700E drives
only and we should find a way to implement an IDENTIFY-timeout-related blacklist flag,
for CRX700E, somehow).

...right?

(BTW, does a drive firmware have to do something special to obey
Cable Select protocol properly, and would this thus indicate a firmware bug indeed?)

Thanks,

Andreas

Re: 2.6.28-rc3 libata: still "failed to IDENTIFY" on bootup

[Tejun Heo]

[-- Attachment #1: Type: text/plain, Size: 649 bytes --]

Andreas Mohr wrote:
> when searching for the "identify retried exceeded" BSD error message
> the CRX700E-mentioning page is the _only_ one that comes up on Google!!
> (IOW, it strongly looks like this issue seems quite isolated to CRX700E drives
> only and we should find a way to implement an IDENTIFY-timeout-related blacklist flag,
> for CRX700E, somehow).
> 
> ...right?
> 
> (BTW, does a drive firmware have to do something special to obey
> Cable Select protocol properly, and would this thus indicate a firmware bug indeed?)

I think libata screwed up somewhere.  Can you please apply the attached
patch and report the kernel log?

-- 
tejun

[-- Attachment #2: phantom-debug.patch --]
[-- Type: text/x-patch, Size: 1639 bytes --]

diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
index 4b47394..abbb5f0 100644
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -1226,11 +1226,16 @@ fsm_start:
 		} else {
 			/* ATA PIO protocol */
 			if (unlikely((status & ATA_DRQ) == 0)) {
+				ata_dev_printk(qc->dev, KERN_INFO, "XXX status=0x%x hdiag=%d\n",
+					       status, qc->dev->horkage & ATA_HORKAGE_DIAGNOSTIC);
+
 				/* handle BSY=0, DRQ=0 as error */
-				if (likely(status & (ATA_ERR | ATA_DF)))
+				if (likely(status & (ATA_ERR | ATA_DF))) {
 					/* device stops HSM for abort/error */
 					qc->err_mask |= AC_ERR_DEV;
-				else {
+					if (qc->dev->horkage & ATA_HORKAGE_DIAGNOSTIC)
+						qc->err_mask |= AC_ERR_NODEV_HINT;
+				} else {
 					/* HSM violation. Let EH handle this.
 					 * Phantom devices also trigger this
 					 * condition.  Mark hint.
@@ -1838,6 +1843,8 @@ unsigned int ata_sff_dev_classify(struct ata_device *dev, int present,
 
 	/* determine if device is ATA or ATAPI */
 	class = ata_dev_classify(&tf);
+	ata_dev_printk(dev, KERN_INFO, "XXX sff_dev_classify present=%d hdiag=%d tf=%02x:%02x:%02x class=%d\n",
+		       present, dev->horkage & ATA_HORKAGE_DIAGNOSTIC, tf.lbal, tf.lbam, tf.lbah, class);
 
 	if (class == ATA_DEV_UNKNOWN) {
 		/* If the device failed diagnostic, it's likely to
@@ -1981,6 +1988,7 @@ int ata_sff_softreset(struct ata_link *link, unsigned int *classes,
 		devmask |= (1 << 0);
 	if (slave_possible && ata_devchk(ap, 1))
 		devmask |= (1 << 1);
+	ata_link_printk(link, KERN_INFO, "XXX devmask=%x\n", devmask);
 
 	/* select device 0 again */
 	ap->ops->sff_dev_select(ap, 0);

Re: 2.6.28-rc3 libata: still "failed to IDENTIFY" on bootup

[Andreas Mohr]

[-- Attachment #1: Type: text/plain, Size: 488 bytes --]

Hi,

On Wed, Nov 12, 2008 at 11:35:02AM +0900, Tejun Heo wrote:
> Andreas Mohr wrote:
> > (BTW, does a drive firmware have to do something special to obey
> > Cable Select protocol properly, and would this thus indicate a firmware bug indeed?)
> 
> I think libata screwed up somewhere.  Can you please apply the attached
> patch and report the kernel log?

OK, here it is.

Note that the error delay did NOT occur now (probably because you
actively avoided it I guess).

Thanks!

Andreas

[-- Attachment #2: dmesg_phantom-debug.log.gz --]
[-- Type: application/x-gzip, Size: 18813 bytes --]