sata_nv times out for BD-ROM iHOS104-08
in [Kernel]
|
Prev: block: add a new flag to make request complete on submitted cpu
Next: [PATCH 01/25] x86: fix size for ex trampoline with 32bit
From: Cengiz Günay on 28 Feb 2010 12:30 Hi Tejun, On Mon, Feb 22, 2010 at 9:38 PM, Tejun Heo <tj(a)kernel.org> wrote: > On 02/22/2010 06:28 AM, Cengiz Günay wrote: >> I was able to read a regular DVD in the drive. According to dmesg the >> negotiated speed was down to UDMA/33, so I am not sure about the >> performance of the drive. > > Hmmm.... it could be that the drive is sending more data then > requested and the state machine in the controller doesn't like that > and fails to assert IRQ on the host side. You're still getting > timeouts on 96 byte dma inquiries. Can you please this patch? Before and after the swncq-atapi-pio patch I still get awful read times from the BD-ROM drive: $ time dd if=/dev/sr0 of=/dev/null bs=64k count=1024 67108864 bytes (67 MB) copied, 106.945 seconds, 628 kB/s => real 1m46.977s Compared to reading the same DVD in my DVD-ROM drive: $ time dd if=/dev/hda of=/dev/null bs=64k count=1024 67108864 bytes (67 MB) copied, 13.8403 seconds, 4.8 MB/s => real 0m13.860s I attached the full dmesg after the swncq-atapi-pio patch. -Cengiz
From: Tejun Heo on 2 Mar 2010 06:40 Hello, On 03/01/2010 02:24 AM, Cengiz Günay wrote: > Before and after the swncq-atapi-pio patch I still get awful read > times from the BD-ROM drive: > > $ time dd if=/dev/sr0 of=/dev/null bs=64k count=1024 > 67108864 bytes (67 MB) copied, 106.945 seconds, 628 kB/s > => real 1m46.977s Hmmm... the drive is timing out even on 4k READ10's. This shouldn't really be happening. Can you please try this one? -- tejun
From: Cengiz Günay on 8 Mar 2010 14:20 Hello, Sorry for the delay, I was confused about managing so many patches, but I realized that you're sending me cumulative patches that I can apply to the original. I just want to remind you that I still have the patches to the other two files: libata-eh.c libata-sff.c On Tue, Mar 2, 2010 at 6:48 AM, Tejun Heo <tj(a)kernel.org> wrote: > Hmmm... the drive is timing out even on 4k READ10's. This shouldn't > really be happening. Can you please try this one? Applied. It did not change anything visibly (dmesg attached). I have also been getting other SCSI errors since we started communicating with the device (search for sr0 in dmesg). I wonder if they give any hints? Here's one: sr 4:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE sr 4:0:0:0: [sr0] Sense Key : Aborted Command [current] [descriptor] Descriptor sense data with sense descriptors (in hex): 72 0b 00 00 00 00 00 0e 09 0c 00 00 00 02 00 00 00 20 00 00 a0 40 sr 4:0:0:0: [sr0] Add. Sense: No additional sense information sr 4:0:0:0: [sr0] CDB: Read(10): 28 00 00 00 00 00 00 00 40 00 end_request: I/O error, dev sr0, sector 0 Thanks, Cengiz
From: Robert Hancock on 8 Mar 2010 18:50 2010/3/8 Cengiz G�nay <cgunay(a)emory.edu>: > Hello, > > Sorry for the delay, I was confused about managing so many patches, > but I realized that you're sending me cumulative patches that I can > apply to the original. I just want to remind you that I still have the > patches to the other two files: libata-eh.c �libata-sff.c > > On Tue, Mar 2, 2010 at 6:48 AM, Tejun Heo <tj(a)kernel.org> wrote: >> Hmmm... the drive is timing out even on 4k READ10's. �This shouldn't >> really be happening. �Can you please try this one? > > Applied. It did not change anything visibly (dmesg attached). I have > also been getting other SCSI errors since we started communicating > with the device (search for sr0 in dmesg). I wonder if they give any > hints? Here's one: > > sr 4:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE > sr 4:0:0:0: [sr0] Sense Key : Aborted Command [current] [descriptor] > Descriptor sense data with sense descriptors (in hex): > � � � �72 0b 00 00 00 00 00 0e 09 0c 00 00 00 02 00 00 > � � � �00 20 00 00 a0 40 > sr 4:0:0:0: [sr0] Add. Sense: No additional sense information > sr 4:0:0:0: [sr0] CDB: Read(10): 28 00 00 00 00 00 00 00 40 00 > end_request: I/O error, dev sr0, sector 0 Don't think that part's very useful, that's just the after-effect of the timeouts in the driver.. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Tejun Heo on 8 Mar 2010 20:30
On 03/09/2010 04:17 AM, Cengiz Günay wrote: > Hello, > > Sorry for the delay, I was confused about managing so many patches, > but I realized that you're sending me cumulative patches that I can > apply to the original. I just want to remind you that I still have the > patches to the other two files: libata-eh.c libata-sff.c > > On Tue, Mar 2, 2010 at 6:48 AM, Tejun Heo <tj(a)kernel.org> wrote: >> Hmmm... the drive is timing out even on 4k READ10's. This shouldn't >> really be happening. Can you please try this one? > > Applied. It did not change anything visibly (dmesg attached). I have > also been getting other SCSI errors since we started communicating > with the device (search for sr0 in dmesg). I wonder if they give any > hints? Here's one: > > sr 4:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE > sr 4:0:0:0: [sr0] Sense Key : Aborted Command [current] [descriptor] > Descriptor sense data with sense descriptors (in hex): > 72 0b 00 00 00 00 00 0e 09 0c 00 00 00 02 00 00 > 00 20 00 00 a0 40 > sr 4:0:0:0: [sr0] Add. Sense: No additional sense information > sr 4:0:0:0: [sr0] CDB: Read(10): 28 00 00 00 00 00 00 00 40 00 > end_request: I/O error, dev sr0, sector 0 Hmmm... can you please post full dmesg? -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |