Re: sata_nv times out for BD-ROM iHOS104-08
Tejun Heo
On 12/23/2009 01:07 AM, Cengiz Gunay wrote:
> I was unable to get another driver like the SATA AHCI or one of the PATA
> drivers to take over this device. Is that even possible?
No.
> I would appreciate any suggestions and would happily debug this a little
> further. And, of course, happy holidays everybody. Details of my
> configuration follow.
Can you please try kernel parameter irqpoll? Also, does having a
readable media in the drive during boot make any difference?
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Tejun Heo
>
> On Wed, Dec 23, 2009 at 2:38 AM, Tejun Heo <t...@kernel.org
> <mailto:t...@kernel.org>> wrote:
>
> Can you please try kernel parameter irqpoll? Also, does having a
> readable media in the drive during boot make any difference?
>
>
>
> By the way, kernel 2.6.23.9 goes into an infinite loop at bootup with
> ata3 exception messages. I can write them down if it would help.
Hmmm... can you please take a photo? I don't think the controller has
anything to do with the issue but just in case can you please try it
with a different controller?
Cengiz Günay
> I don't think the controller has anything to do with the issue but
> just in case can you please try it with a different controller?
I tried the iHOS BD-ROM with a VIA VT6412 SATA controller today and it worked:
snippet from dmesg:
---
sata_via 0000:06:06.0: version 2.4
ACPI: PCI Interrupt Link [APC1] enabled at IRQ 16
sata_via 0000:06:06.0: PCI INT A -> Link[APC1] -> GSI 16 (level, low) -> IRQ 16
sata_via 0000:06:06.0: routed to hard irq line 5
scsi0 : sata_via
PM: Adding info for scsi:host0
PM: Adding info for No Bus:host0
scsi1 : sata_via
PM: Adding info for scsi:host1
PM: Adding info for No Bus:host1
scsi2 : sata_via
PM: Adding info for scsi:host2
PM: Adding info for No Bus:host2
ata1: SATA max UDMA/133 port i16@0x9000 bmdma 0xa000 irq 16
ata2: SATA max UDMA/133 port i16@0x9400 bmdma 0xa008 irq 16
ata3: PATA max UDMA/133 port i16@0x9800 bmdma 0xa010 irq 16
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata1.00: ATAPI: ATAPI iHOS104, WL08, max UDMA/100
ata1.00: configured for UDMA/100
scsi 0:0:0:0: CD-ROM ATAPI iHOS104 WL08 PQ: 0 ANSI: 5
---
output of lsscsi:
---
[0:0:0:0] cd/dvd ATAPI iHOS104 WL08 /dev/sr0
---
I also tried my sata_nv with a 64-bit kernel 2.6.22-3-amd64. I got
these messages where it looks like ata3 is finally reset and set at a
UDMA/66, but I don't get the drive recognized afterwards:
dmesg:
---
ata3.00: configured for UDMA/100
ata4: SATA link down (SStatus 0 SControl 300)
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata3.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in
ata3: soft resetting port
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata3.00: configured for UDMA/100
ata3: EH complete
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata3.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in
ata3: soft resetting port
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata3.00: configured for UDMA/100
ata3: EH complete
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata3.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in
ata3: soft resetting port
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata3.00: configured for UDMA/100
ata3: EH complete
ata3.00: limiting speed to UDMA/66:PIO4
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata3.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in
ata3: soft resetting port
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata3.00: configured for UDMA/66
ata3: EH complete
hdc: PIONEER DVD-RW DVR-111D, ATAPI CD/DVD-ROM drive
hdc: ATAPI 63X DVD-ROM DVD-R CD-R/RW drive, 2000kB Cache, UDMA(66)
---
I contacted LiteON technical support in the meantime, but they are no
help. They said they tested with one Linux system and it worked.
I will probably buy one of the above VIA cards and use it for this drive.
Thanks for helping!
--
Cengiz
Gregory Moyer
>
> help. They said they tested with one Linux system and it worked.
>
> I will probably buy one of the above VIA cards and use it for this drive.
>
> Thanks for helping!
I too am having the same problem with the iHOS104. I filed a bug
report against Ubuntu Karmic
(https://bugs.launchpad.net/ubuntu/+source/linux/+bug/344093). At
least one other person reporting on that same bug report has confirmed
the issue. We are both seeing the problem with nVidia chipsets using
the sata_nv driver. There is a lot of information in the report, so
I'll skip re-posting it all here. However, as the previous poster
mentioned, after contacting LiteOn support, I was told the drive works
in Mandriva 2007.0. I tried it and sure enough, it does. The other
poster in the linked report confirmed this as well, stating that for
that distribution, the kernel was at 2.6.17 and the sata_nv driver was
at 0.8. I have tried several distributions/kernels, including 2.6.32.
I have also tried a myriad of kernel and BIOS options, including all
of the ones mentioned so far in this thread. If I can help in any way
to get this resolved, please let me know. Thanks for taking the time
to look into it.
Ozan Çağlayan
> 2009/12/24 Tejun Heo <t...@kernel.org>:
>> I don't think the controller has anything to do with the issue but
>> just in case can you please try it with a different controller?
>
> I tried the iHOS BD-ROM with a VIA VT6412 SATA controller today and it worked:
>
I don't have the possibility to try with another controller but exactly the same issue with PIONEER DVD-RW DVRKD08RS:
[ 4.618380] ata1.00: ATAPI: PIONEER DVD-RW DVRKD08RS, 1.02, max UDMA/33
[ 4.618447] ata1: nv_mode_filter: 0x739f&0x739f->0x739f, BIOS=0x7000 (0xc000c700) ACPI=0x701f (60:600:0x13)
[ 4.625131] ata1.00: configured for UDMA/33
[ 4.625214] ata1.00: TEST_UNIT_READY failed (err_mask=0x2)
[ 4.838039] usb 3-2: new low speed USB device using ohci_hcd and address 2
[ 4.909709] input: PS/2 Mouse as /devices/platform/i8042/serio1/input/input6
[ 4.944821] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input7
[ 5.000029] Clocksource tsc unstable (delta = -254057140 ns)
[ 5.027063] usb 3-2: New USB device found, idVendor=05e3, idProduct=1205
[ 5.027071] usb 3-2: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[ 5.027078] usb 3-2: Product: USB Mouse
[ 5.027199] usb 3-2: configuration #1 chosen from 1 choice
[ 5.037758] input: USB Mouse as /devices/pci0000:00/0000:00:02.0/usb3/3-2/3-2:1.0/input/input8
[ 5.037936] generic-usb 0003:05E3:1205.0001: input,hidraw0: USB HID v1.10 Mouse [USB Mouse ] on usb-0000:00:02.0-2/input0
[ 5.708253] ieee1394: Host added: ID:BUS[0-00:1023] GUID[00023f7cba403d32]
[ 9.769407] ata1: nv_mode_filter: 0x739f&0x739f->0x739f, BIOS=0x7000 (0xc000c700) ACPI=0x701f (60:600:0x13)
[ 9.775326] ata1.00: configured for UDMA/33
[ 9.775408] ata1.00: TEST_UNIT_READY failed (err_mask=0x2)
[ 9.775417] ata1.00: limiting speed to UDMA/33:PIO3
[ 14.920401] ata1: nv_mode_filter: 0x738f&0x739f->0x738f, BIOS=0x7000 (0xc000c700) ACPI=0x701f (60:600:0x13)
[ 14.926332] ata1.00: configured for UDMA/33
[ 14.926412] ata1.00: TEST_UNIT_READY failed (err_mask=0x2)
[ 14.926418] ata1.00: disabled
[ 14.926452] ata1: soft resetting link
[ 15.077100] ata1: EH complete
[ 15.077155] ata2: port disabled. ignoring.
Tejun Heo
On 01/18/2010 12:28 AM, Ozan Çağlayan wrote:
> [ 9.769407] ata1: nv_mode_filter: 0x739f&0x739f->0x739f, BIOS=0x7000 (0xc000c700) ACPI=0x701f (60:600:0x13)
> [ 9.775326] ata1.00: configured for UDMA/33
> [ 9.775408] ata1.00: TEST_UNIT_READY failed (err_mask=0x2)
Hmmm... err_mask=0x2 is HSM error. Strange. Does the attached patch
Ozan Çağlayan
Hi,
He reported back that after a few reboots its now working correctly. Actually the behaviour is a little bit
random as he succesfully installed the OS from a CD without losing its DVD drive.
I'll keep a patched kernel and send to him for testing if the bug reappears.
Thanks,
Tejun Heo
On 01/17/2010 06:34 AM, Cengiz Günay wrote:
> 2009/12/24 Tejun Heo <t...@kernel.org>:
>> I don't think the controller has anything to do with the issue but
>> just in case can you please try it with a different controller?
>
> I tried the iHOS BD-ROM with a VIA VT6412 SATA controller today and it worked:
Hmm.... it worked? Does kernel parameter sata_nv.adma_enabled=0 make
any difference? Can you please attach boot log with the kernel
parameter specified?
Thanks.
--
tejun
Robert Hancock
> Hello, Cengiz.
>
> On 01/17/2010 06:34 AM, Cengiz G�nay wrote:
>> 2009/12/24 Tejun Heo <t...@kernel.org>:
>>> I don't think the controller has anything to do with the issue but
>>> just in case can you please try it with a different controller?
>>
>> I tried the iHOS BD-ROM with a VIA VT6412 SATA controller today and it worked:
>
> Hmm.... it worked? �Does kernel parameter sata_nv.adma_enabled=0 make
> any difference? �Can you please attach boot log with the kernel
> parameter specified?
Think you meant maybe sata_nv.swncq=0 instead - this is an MCP51
controller so it doesn't support ADMA. I don't imagine SWNCQ would
make any difference with an ATAPI device, but wouldn't hurt to try.
Cengiz Günay
On Tue, Jan 19, 2010 at 9:59 PM, Robert Hancock <hanco...@gmail.com> wrote:
>>> 2009/12/24 Tejun Heo <t...@kernel.org>:
>> Hmm.... it worked? Does kernel parameter sata_nv.adma_enabled=0 make
>> any difference? Can you please attach boot log with the kernel
>> parameter specified?
>
> Think you meant maybe sata_nv.swncq=0 instead - this is an MCP51
> controller so it doesn't support ADMA. I don't imagine SWNCQ would
> make any difference with an ATAPI device, but wouldn't hurt to try.
Thanks for following this up. I tried both of your suggested kernel
parameters (attached). Neither solved my problem, but also it looks
like I couldn't turn off the SWNCQ mode. Even though I set it to zero,
sata_nv still shows that it uses it. Although the order of my devices
changed, so I assume it did something.
I hope this helps shed some light! I will also try the kernel patch --
not sure if that is suited for the problem I'm having?
-Cengiz
--
Cengiz Gunay
--
Postdoctoral Fellow
Prinz Lab, Dept. of Biology, Emory University
1510 Clifton Rd., Room 2172, Atlanta, GA 30322, U.S.A.
cgu...@emory.edu ceng...@users.sf.net ceng...@yahoo.com
Lab: +1-404-727-9381 Home/Cell: +1-678-559-8694
http://userwww.service.emory.edu/~cgunay
ICQ# 21104923, cengique@{jabber.org,Skype}
--
Tejun Heo
On 01/22/2010 11:11 PM, Cengiz G�nay wrote:
> On Tue, Jan 19, 2010 at 9:59 PM, Robert Hancock <hanco...@gmail.com> wrote:
>>>> 2009/12/24 Tejun Heo <t...@kernel.org>:
>>> Hmm.... it worked? Does kernel parameter sata_nv.adma_enabled=0 make
>>> any difference? Can you please attach boot log with the kernel
>>> parameter specified?
>>
>> Think you meant maybe sata_nv.swncq=0 instead - this is an MCP51
>> controller so it doesn't support ADMA. I don't imagine SWNCQ would
>> make any difference with an ATAPI device, but wouldn't hurt to try.
>
> Thanks for following this up. I tried both of your suggested kernel
> parameters (attached). Neither solved my problem, but also it looks
> like I couldn't turn off the SWNCQ mode. Even though I set it to zero,
> sata_nv still shows that it uses it. Although the order of my devices
> changed, so I assume it did something.
The parameter isn't being passed to the module loaded by initrd. You
probably need to edit modules.conf and then regenerate initrd. :-(
> I hope this helps shed some light! I will also try the kernel patch --
> not sure if that is suited for the problem I'm having?
Yeah, I was about to suggest trying the patch. It could be that the
timeout used by the new TUR code is too aggressive.
Thanks.
--
tejun
Tejun Heo
> 2010/2/1 Tejun Heo <t...@kernel.org>:
>
>> Can you please attach full dmesg w/ the patch applied w/o any kernel
>> parameter? I'm curious where the hda warnings are coming from. Is
>> generic IDE driver loaded?
>
> The dmesg snippet I attached last time was w/o any kernel parameters.
> This time I'm attaching the full dmesg output. hda is my other DVD-RW
> drive, I'm not sure what the warnings mean. ide_core is loaded, but
> not the ide-generic or ide-pci-generic modules, although they are
> available. Would you like me to force them to load?
No, I was concerned because there were a few cases where two drivers
were attached to the same controller but I don't think that's possible
here.
Does the attached patch make any difference?
Thanks.
--
tejun
Tejun Heo
>> Does the attached patch make any difference?
>
> attached a full dmesg output with the patch. Note that I have both the
> patches disable-clear-ua and drain-from-atapi-pio-bytes applied at the
> same time.
Hmmm... So, DRQ gets cleared? That's strange. When then the 18 extra
bytes happen? Can you please try this one?
--
tejun
Tejun Heo
On 02/22/2010 06:28 AM, Cengiz Günay wrote:
> On Sat, Feb 20, 2010 at 8:01 PM, Tejun Heo <t...@kernel.org> wrote:
>> Hmmm... So, DRQ gets cleared? That's strange. When then the 18 extra
>> bytes happen? Can you please try this one?
>
> It worked!
>
> $ lsscsi
> ...
> [4:0:0:0] cd/dvd ATAPI iHOS104 WL08 /dev/sr0
> ...
>
> 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?
--
tejun
Tejun Heo
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
Robert Hancock
> 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 <t...@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?
>
> 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..
Tejun Heo
> 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 <t...@kernel.org> wrote:
>> really be happening. Can you please try this one?
>
> 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
Tejun Heo
Alright, I don't have access to mcp51 but tested with mcp55 and could
reproduce similar problem. It seems nIEN on mcp55 is stuck once set
and iHOS104 doesn't set I on D2H FIS if nIEN is set on command H2D
FIS, which the SATA standard specifically mandates not to do. So, the
combination of buggy mcp55 ctl handling + buggy iHOS104 nIEN handling
leads to nobody raising interrupt.
The problem is that the problem I'm seeing is not completely identical
to the one you're seeing. The difference could be coming from
different firmware version on the drives or different controllers.
Anyways, can you please give a shot at the attached patch?
Thanks.
--
tejun