Hello,
I recently got the iHOS-104-08 Blu-ray reader from LiteOn after hearing
customer reviews and a company statement that it works in Linux, but it
just doesn't work on my hardware combination. I saw previous posts here
and elsewhere on sata_nv specific problems, so I hope you can help me, or
at least I can report this properly for future fixes.
I have an ASUS P5NSLI motherboard with a Core2Duo E6400 CPU and a Nvidia
MCP51 SATA controller (rev a1). On this, I have two other SATA disks (in
Nvidia RAID0 configuration) that I boot from both in Linux and Windows and
I have been using this computer for several years without problems. The
LiteOn BD-ROM is attached to the 3rd SATA port (RAID disabled in BIOS) and
I was able to read DVDs on Windows XP. In Linux, with the latest stable
kernel 2.6.32 (note I'm running a 32-bit linux on 64-bit machine for
historical reasons), this is what I get at boot time:
# dmesg | grep ata3
ata3: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0 bmdma 0xe800 irq 20
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata3.00: ATAPI: ATAPI iHOS104, WL08, max UDMA/100
ata3.00: configured for UDMA/100
ata3.00: qc timeout (cmd 0xa0)
ata3.00: TEST_UNIT_READY failed (err_mask=0x5)
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata3.00: configured for UDMA/100
ata3.00: qc timeout (cmd 0xa0)
ata3.00: TEST_UNIT_READY failed (err_mask=0x5)
ata3: limiting SATA link speed to 1.5 Gbps
ata3.00: limiting speed to UDMA/100:PIO3
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata3.00: configured for UDMA/100
ata3.00: qc timeout (cmd 0xa0)
ata3.00: TEST_UNIT_READY failed (err_mask=0x5)
ata3.00: disabled
ata3: hard resetting link
ata3: nv: skipping hardreset on occupied port
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata3: EH complete
In the end the device does not appear in my SCSI device list (see output
of lsscsi below) and I cannot access it. Curiously, I get 0 interrupts
from this SATA controller (see /proc/interrupts at bottom of email).
I tried playing with both sata_nv options, such as ADMA, MSI and SWNCQ. I
learned from posts here that MCP51 doesn't have support for ADMA, but
either way the messages I get did not change. I also failed to force DMA
and speed selection behavior using libata.dma and libata.force on the
kernel command-line. I wasn't able to influence sata_nv's decisions any
bit. "acpi=off noapic" and "acpi_use_time_override" also did not help. I
have a working HPET timer in the BIOS.
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?
I would appreciate any suggestions and would happily debug this a little
further. And, of course, happy holidays everybody. Details of my
configuration follow.
--
Cengiz Gunay
SYSTEM DETAILS:
---------------------------------
I have a Debian unstable/experimental system:
# uname -a
Linux salon 2.6.32 #1 SMP PREEMPT Mon Dec 21 10:40:35 EST 2009 i686
GNU/Linux
Dmesg snippet (full listing attached) showing sata_nv initialization and
irq assignment:
--
sata_nv 0000:00:0e.0: version 3.5
ACPI: PCI Interrupt Link [APSI] enabled at IRQ 21
sata_nv 0000:00:0e.0: PCI INT A -> Link[APSI] -> GSI 21 (level, low) ->
IRQ 21
sata_nv 0000:00:0e.0: Using SWNCQ mode
sata_nv 0000:00:0e.0: setting latency timer to 64
scsi1 : sata_nv
PM: Adding info for scsi:host1
PM: Adding info for No Bus:host1
scsi2 : sata_nv
PM: Adding info for scsi:host2
PM: Adding info for No Bus:host2
ata1: SATA max UDMA/133 cmd 0x9f0 ctl 0xbf0 bmdma 0xd400 irq 21
ata2: SATA max UDMA/133 cmd 0x970 ctl 0xb70 bmdma 0xd408 irq 21
ACPI: PCI Interrupt Link [APSJ] enabled at IRQ 20
sata_nv 0000:00:0f.0: PCI INT A -> Link[APSJ] -> GSI 20 (level, low) ->
IRQ 20
sata_nv 0000:00:0f.0: Using SWNCQ mode
sata_nv 0000:00:0f.0: setting latency timer to 64
scsi3 : sata_nv
PM: Adding info for scsi:host3
PM: Adding info for No Bus:host3
scsi4 : sata_nv
PM: Adding info for scsi:host4
PM: Adding info for No Bus:host4
ata3: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0 bmdma 0xe800 irq 20
ata4: SATA max UDMA/133 cmd 0x960 ctl 0xb60 bmdma 0xe808 irq 20
--
# lsscsi
[0:0:0:0] disk Generic USB SD Reader 1.00 /dev/sdc
[0:0:0:1] disk Generic USB CF Reader 1.01 /dev/sdd
[0:0:0:2] disk Generic USB SM Reader 1.02 /dev/sde
[0:0:0:3] disk Generic USB MS Reader 1.03 /dev/sdf
[1:0:0:0] disk ATA SAMSUNG SP2504C VT10 /dev/sda
[2:0:0:0] disk ATA ST3250620AS 3.AA /dev/sdb
[5:0:0:0] disk USB DISK 2.0 0403 /dev/sdg
I get 0 interrupts from IRQ 20 assigned to 2nd SATA channel (ata3 and
ata4).
# cat /proc/interrupts
CPU0 CPU1
0: 144 0 IO-APIC-edge timer
1: 2 0 IO-APIC-edge i8042
7: 1 0 IO-APIC-edge
9: 0 0 IO-APIC-fasteoi acpi
12: 4 0 IO-APIC-edge i8042
15: 6483 0 IO-APIC-edge ide0
16: 147431 0 IO-APIC-fasteoi ohci1394, nvidia
17: 95671 0 IO-APIC-fasteoi eth1
20: 6 0 IO-APIC-fasteoi sata_nv
21: 53915 0 IO-APIC-fasteoi sata_nv
22: 67354 0 IO-APIC-fasteoi ehci_hcd:usb2
23: 633 0 IO-APIC-fasteoi ohci_hcd:usb1, HDA Intel
NMI: 0 0 Non-maskable interrupts
LOC: 2572087 2602175 Local timer interrupts
SPU: 0 0 Spurious interrupts
PMI: 0 0 Performance monitoring interrupts
PND: 0 0 Performance pending work
RES: 32606 35770 Rescheduling interrupts
CAL: 349 609 Function call interrupts
TLB: 2548 3449 TLB shootdowns
TRM: 0 0 Thermal event interrupts
THR: 0 0 Threshold APIC interrupts
MCE: 0 0 Machine check exceptions
MCP: 8 8 Machine check polls
ERR: 1
MIS: 0
# lspci (full "lspci -vv" attached)
00:00.0 Host bridge: nVidia Corporation Device 0071 (rev a3)
00:00.1 RAM memory: nVidia Corporation Device 007f (rev a1)
00:00.2 RAM memory: nVidia Corporation Device 0075 (rev a1)
00:00.3 RAM memory: nVidia Corporation Device 006f (rev a1)
00:00.4 RAM memory: nVidia Corporation Device 00b4 (rev a1)
00:01.0 RAM memory: nVidia Corporation Device 0076 (rev a1)
00:01.1 RAM memory: nVidia Corporation Device 0078 (rev a1)
00:01.2 RAM memory: nVidia Corporation Device 0079 (rev a1)
00:01.3 RAM memory: nVidia Corporation Device 007a (rev a1)
00:01.4 RAM memory: nVidia Corporation Device 007b (rev a1)
00:01.5 RAM memory: nVidia Corporation Device 007c (rev a1)
00:01.6 RAM memory: nVidia Corporation Device 007d (rev a1)
00:02.0 PCI bridge: nVidia Corporation Device 007e (rev a2)
00:04.0 PCI bridge: nVidia Corporation Device 007e (rev a2)
00:05.0 PCI bridge: nVidia Corporation Device 007e (rev a2)
00:06.0 PCI bridge: nVidia Corporation Device 007e (rev a2)
00:07.0 PCI bridge: nVidia Corporation Device 007e (rev a2)
00:09.0 RAM memory: nVidia Corporation MCP51 Host Bridge (rev a2)
00:0a.0 ISA bridge: nVidia Corporation MCP51 LPC Bridge (rev a2)
00:0a.1 SMBus: nVidia Corporation MCP51 SMBus (rev a2)
00:0a.2 RAM memory: nVidia Corporation MCP51 Memory Controller 0 (rev a2)
00:0b.0 USB Controller: nVidia Corporation MCP51 USB Controller (rev a2)
00:0b.1 USB Controller: nVidia Corporation MCP51 USB Controller (rev a2)
00:0d.0 IDE interface: nVidia Corporation MCP51 IDE (rev a1)
00:0e.0 RAID bus controller: nVidia Corporation MCP51 Serial ATA
Controller (rev a1)
00:0f.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev
a1)
00:10.0 PCI bridge: nVidia Corporation MCP51 PCI Bridge (rev a2)
00:10.1 Audio device: nVidia Corporation MCP51 High Definition Audio (rev
a2)
01:00.0 VGA compatible controller: nVidia Corporation G71 [GeForce 7900
GT/GTO] (rev a1)
06:06.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306 Fire II IEEE
1394 OHCI Link Layer Controller (rev 46)
06:07.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169
Gigabit Ethernet (rev 10)
# lspci -vv -s 00:0f.0 (full "lspci -vv" attached)
00:0f.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev
a1) (prog-if 85 [Master SecO PriO])
Subsystem: ASUSTeK Computer Inc. A8N-VM CSM Mainboard
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0 (750ns min, 250ns max)
Interrupt: pin A routed to IRQ 20
Region 0: I/O ports at 09e0 [size=8]
Region 1: I/O ports at 0be0 [size=4]
Region 2: I/O ports at 0960 [size=8]
Region 3: I/O ports at 0b60 [size=4]
Region 4: I/O ports at e800 [size=16]
Region 5: Memory at d5005000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [b0] MSI: Enable- Count=1/4 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [cc] HyperTransport: MSI Mapping Enable- Fixed+
Kernel driver in use: sata_nv
Kernel modules: sata_nv
# lspci -vv -s 00:0e.0
00:0e.0 RAID bus controller: nVidia Corporation MCP51 Serial ATA
Controller (rev a1) (prog-if 85)
Subsystem: ASUSTeK Computer Inc. A8N-VM CSM Mainboard
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0 (750ns min, 250ns max)
Interrupt: pin A routed to IRQ 21
Region 0: I/O ports at 09f0 [size=8]
Region 1: I/O ports at 0bf0 [size=4]
Region 2: I/O ports at 0970 [size=8]
Region 3: I/O ports at 0b70 [size=4]
Region 4: I/O ports at d400 [size=16]
Region 5: Memory at d5004000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [b0] MSI: Enable- Count=1/4 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [cc] HyperTransport: MSI Mapping Enable- Fixed+
Kernel driver in use: sata_nv
Kernel modules: sata_nv
Hello,
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
On 12/24/2009 04:02 PM, Cengiz Günay wrote:
>
> On Wed, Dec 23, 2009 at 2:38 AM, Tejun Heo <[email protected]
> <mailto:[email protected]>> wrote:
>
> Can you please try kernel parameter irqpoll? Also, does having a
> readable media in the drive during boot make any difference?
>
>
> Sorry, neither made 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?
Thanks.
--
tejun
2009/12/24 Tejun Heo <[email protected]>:
> 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
> 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!
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.
Cengiz Günay wrote:
> 2009/12/24 Tejun Heo <[email protected]>:
>> 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.
Hello,
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
make any difference?
Thanks.
--
tejun
Tejun Heo wrote:
> Hello,
>
> 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
> make any difference?
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,
Hello, Cengiz.
On 01/17/2010 06:34 AM, Cengiz Günay wrote:
> 2009/12/24 Tejun Heo <[email protected]>:
>> 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
2010/1/19 Tejun Heo <[email protected]>:
> Hello, Cengiz.
>
> On 01/17/2010 06:34 AM, Cengiz G?nay wrote:
>> 2009/12/24 Tejun Heo <[email protected]>:
>>> 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.
> > 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.
I tried booting 2.6.32 with both of these options (tried separately)
with no change in behavior. If it helps, sometimes I get an error mask
of 0x4 and sometimes 0x5, though I do not know what either represents.
Also, my controller is MCP55, but I don't know how different that is
from the MCP51 that Cengiz has.
Attached are boot logs from running each option suggested here.
Thanks again.
- Greg
Hello, Tejun & Robert,
On Tue, Jan 19, 2010 at 9:59 PM, Robert Hancock <[email protected]> wrote:
>>> 2009/12/24 Tejun Heo <[email protected]>:
>> 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.
[email protected] [email protected] [email protected]
Lab: +1-404-727-9381 Home/Cell: +1-678-559-8694
http://userwww.service.emory.edu/~cgunay
ICQ# 21104923, cengique@{jabber.org,Skype}
--
Hello,
On 01/22/2010 11:11 PM, Cengiz G?nay wrote:
> On Tue, Jan 19, 2010 at 9:59 PM, Robert Hancock <[email protected]> wrote:
>>>> 2009/12/24 Tejun Heo <[email protected]>:
>>> 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
Hello,
2010/1/22 Tejun Heo <[email protected]>:
> The parameter isn't being passed to the module loaded by initrd. You
> probably need to edit modules.conf and then regenerate initrd. :-(
Ok, you're right. I forgot I had to do that. So now I did it for
ADMA=0, SWNCQ=0 and MSI=1, separately. None worked, and all dmesg
outputs attached.
> Yeah, I was about to suggest trying the patch. It could be that the
> timeout used by the new TUR code is too aggressive.
Unfortunately that didn't work, either (attached). It kept on changing
DMA modes down to PIO0 and completly failed in the end. Should I try
different sata_nv parameters with this patch if needed?
Thanks,
--
Cengiz
2010/2/1 Tejun Heo <[email protected]>:
> 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?
-Cengiz
On 02/18/2010 01:14 AM, Cengiz Günay wrote:
> 2010/2/1 Tejun Heo <[email protected]>:
>
>> 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
On Wed, Feb 17, 2010 at 8:50 PM, Tejun Heo <[email protected]> wrote:
> 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.
Ok.
> Does the attached patch make any difference?
Not that I can tell. I still get an infinite loop of ata4 errors. I
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.
Thanks,
-Cengiz
On 02/21/2010 04:11 AM, Cengiz Günay wrote:
>> Does the attached patch make any difference?
>
> Not that I can tell. I still get an infinite loop of ata4 errors. I
> 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
On Sat, Feb 20, 2010 at 8:01 PM, Tejun Heo <[email protected]> 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.
Full dmesg attached.
Thanks!
Cengiz
Hello,
On 02/22/2010 06:28 AM, Cengiz Günay wrote:
> On Sat, Feb 20, 2010 at 8:01 PM, Tejun Heo <[email protected]> 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
Hi Tejun,
On Mon, Feb 22, 2010 at 9:38 PM, Tejun Heo <[email protected]> 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
> Hello,
>
> 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
I tried your latest patch against?2.6.32 with my iHOS104 and MCP55 and
it works perfectly. I can now use the drive normally and I do not see
any failure/reset messages in the log. Thanks!
- Greg