On Thu, Sep 3, 2009 at 4:05 PM, Mark Lord<liml@xxxxxx> wrote: > Tejun Heo wrote: >> >> Hello, >> >> Mike Hokenson wrote: >>> >>> (sorry, resent to linux-ide without the html) >>> >>> On Mon, Aug 31, 2009 at 9:02 AM, Tejun Heo <tj@xxxxxxxxxx> wrote: >>>>> >>>>> [ 6.312129] ata2.00: qc timeout (cmd 0xa1) >>>>> [ 6.312135] ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4) >>>>> [ 11.352006] ata2: link is slow to respond, please be patient >>>>> (ready=0) >>>>> [ 16.336009] ata2: device not ready (errno=-16), forcing hardreset >>>>> [ 21.532007] ata2: link is slow to respond, please be patient >>>>> (ready=0) >>>>> [ 26.348009] ata2: SRST failed (errno=-16) >>>>> [ 31.544008] ata2: link is slow to respond, please be patient >>>>> (ready=0) >>>>> [ 36.360014] ata2: SRST failed (errno=-16) >>>>> [ 36.544307] ata2.00: ATAPI: ASUS DRW-2014L1T, 1.02, max UDMA/66 >>>>> [ 36.560317] ata2.00: configured for UDMA/66 >>>>> [ 36.576547] scsi 1:0:0:0: CD-ROM ASUS DRW-2014L1T >>>>> 1.02 PQ: 0 ANSI: 5 >>>> >>>> "libata.force=2:udma33" would force it to udma/33 but I don't think >>>> that would be the problem here. IDENTIFY doesn't use udma anyway. >>>> Does the problem go away if you do "libata.force=2:pio0"? >>> >>> Thanks for the suggestion, but it didn't help. libata is setup as a >>> module in Debian's kernel, so I created a /etc/modprobe.d/libata.conf >>> with "options libata force=2:pio0" and rebuilt initrd. This appears to >>> have properly registered the force flag, but it seems to have only >>> been applied once the kernel worked through the issue with the >>> controller/port: >>> >>> [ 3.985969] usbhid: v2.6:USB HID core driver >>> [ 6.316130] ata2.00: qc timeout (cmd 0xa1) >>> [ 6.316135] ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4) >>> [ 11.356004] ata2: link is slow to respond, please be patient (ready=0) >>> [ 16.340004] ata2: device not ready (errno=-16), forcing hardreset >>> [ 21.536004] ata2: link is slow to respond, please be patient (ready=0) >>> [ 26.352504] ata2: SRST failed (errno=-16) >>> [ 31.548004] ata2: link is slow to respond, please be patient (ready=0) >>> [ 36.364514] ata2: SRST failed (errno=-16) >>> [ 36.548307] ata2.00: ATAPI: ASUS DRW-2014L1T, 1.02, max UDMA/66 >>> [ 36.548323] ata2.00: FORCE: xfer_mask set to pio0 >>> [ 36.564827] ata2.00: configured for PIO0 >>> [ 36.565669] scsi 1:0:0:0: CD-ROM ASUS DRW-2014L1T >>> 1.02 PQ: 0 ANSI: 5 >>> >>> I'm not sure if this is due to a modular libata or if that's just the >>> way it is with this particular problem.. >> >> Yeah, PIO0 is forced for initial probing anyway, so the parameter is a >> bit bogus in this case. I'm out of ideas. Mark, marvell 88se6121 is >> timing out the initial IDENTIFY but successfully probes it after a >> couple of resets. Any ideas? > > .. > > I haven't really been following along. But.. I have zero information > here about the Marvell 6121 --> it's supposedly an AHCI chip, isn't it? > > The device that's failing is an optical drive. These often won't respond > to many commands until the onboard firmware finishes examining whatever disc > happens to be inserted, which can take longer than the time we normally > allow. > I wonder if it has anything to do with that ? I think it can be used with AHCI. I remember having some problems a while back after a change went into the AHCI driver that caused it to take over for the PATA port on the Marvell controller, disabling my cdrom drive. I had to disable AHCI, downgrade the kernel, comment the PCI id in ahci.c, or dump the PATA drive and it sounds like I just commented out the PCI id until I got a SATA cdrom - http://marc.info/?t=120996413200002&r=1&w=2 I don't believe mine is using AHCI right now though, the pata_marvell module is loaded and I see this in dmesg: [ 0.985842] ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 6 ports 3 Gbps 0x3f impl SATA mode I have 6 SATA through ICH9R (4 internal, 2 external) and 1 SATA & 1 PATA through the Marvell controller. I assume the 6 it's talking about are the 6 on the ICH9R. There are no other entries like that (if it were to print more for another controller). [ 1.016364] scsi0 : ahci [ 1.018207] pata_marvell 0000:03:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 1.018235] pata_marvell 0000:03:00.0: setting latency timer to 64 [ 1.026464] scsi1 : ahci [ 1.026509] scsi2 : pata_marvell [ 1.026654] scsi3 : ahci [ 1.026735] scsi4 : pata_marvell [ 1.026759] ata7: PATA max UDMA/100 cmd 0xcc00 ctl 0xc880 bmdma 0xc400 irq 16 [ 1.026761] ata8: PATA max UDMA/133 cmd 0xc800 ctl 0xc480 bmdma 0xc408 irq 16 [ 1.027120] scsi5 : ahci [ 1.027306] scsi6 : ahci [ 1.027394] scsi7 : ahci [ 1.027479] ata1: SATA max UDMA/133 abar m2048@0xf9fff000 port 0xf9fff100 irq 28 [ 1.027482] ata2: SATA max UDMA/133 abar m2048@0xf9fff000 port 0xf9fff180 irq 28 [ 1.027484] ata3: SATA max UDMA/133 abar m2048@0xf9fff000 port 0xf9fff200 irq 28 [ 1.027486] ata4: SATA max UDMA/133 abar m2048@0xf9fff000 port 0xf9fff280 irq 28 [ 1.027488] ata5: SATA max UDMA/133 abar m2048@0xf9fff000 port 0xf9fff300 irq 28 [ 1.027490] ata6: SATA max UDMA/133 abar m2048@0xf9fff000 port 0xf9fff380 irq 28 (the ataX number changed for some reason on my last reboot:) [ 6.368129] ata8.00: qc timeout (cmd 0xa1) [ 6.368134] ata8.00: failed to IDENTIFY (I/O error, err_mask=0x4) ... [ 36.616318] ata8.00: configured for UDMA/66 Anyway, this failed to IDENTIFY / slow to respond / SRST message appears regardless of a disc being in the drive. The only time it doesn't appear is if I move the drive to the ICH9R controller. If this is due to some drive initialization, I would have expected to see the same or a similar error on both, but it only happens on the Marvell controller. I've had a SATA hard drive on the Marvell SATA port before and there were no errors. This is my second SATA DVD drive and they both have the same problem. Maybe it's just not a very good controller and it's doing bad/unexpected things.. I definitely wouldn't be using it if I had an(other) open port on the ICH9R. Thanks, Mike -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
