* System fails to connect to iHOS-104 DVD drive with nvidia MCP61 chipset.
@ 2013-08-13 22:36 Bruce Link
2013-08-14 6:17 ` Robert Hancock
0 siblings, 1 reply; 19+ messages in thread
From: Bruce Link @ 2013-08-13 22:36 UTC (permalink / raw)
To: linux-ide; +Cc: 1063474
On bootup, when trying to attach to a Lite-on iHOS-104 DVD drive, the
kernel attempts to establish a connection to the CD drive at a variety
of speeds. Ultimately it fails with a "TEST_UNIT_READY failed
(err_mask=0x4)" message
****************************************************************
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1063474
****************************************************************
The relevant DMESG output is listed below:
watchtv@teevee:~$ dmesg|grep ata5
[ 1.088342] ata5: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0 bmdma 0xc400
irq 23
[ 1.556031] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 1.564134] ata5.00: ATAPI: ATAPI iHOS104, WL0F, max UDMA/100
[ 1.580115] ata5.00: configured for UDMA/100
[ 6.580029] ata5.00: qc timeout (cmd 0xa0)
[ 6.580036] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[ 7.048044] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 7.072129] ata5.00: configured for UDMA/100
[ 29.856040] ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
frozen
[ 29.856063] ata5.00: cmd a0/01:00:00:60:00/00:00:00:00:00/a0 tag 0
dma 96 in
[ 29.856065] ata5.00: status: { DRDY }
[ 29.856071] ata5: hard resetting link
[ 29.856073] ata5: nv: skipping hardreset on occupied port
[ 30.324070] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 30.348152] ata5.00: configured for UDMA/100
[ 35.348125] ata5.00: qc timeout (cmd 0xa0)
[ 35.348132] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[ 35.348139] ata5: hard resetting link
[ 35.348141] ata5: nv: skipping hardreset on occupied port
[ 35.816115] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 35.840125] ata5.00: configured for UDMA/100
[ 36.835824] ata5: EH complete
[ 67.840151] ata5: limiting SATA link speed to 1.5 Gbps
[ 67.840159] ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
frozen
[ 67.840178] ata5.00: cmd a0/01:00:00:80:00/00:00:00:00:00/a0 tag 0
dma 16512 in
[ 67.840181] ata5.00: status: { DRDY }
[ 67.840187] ata5: hard resetting link
[ 67.840188] ata5: nv: skipping hardreset on occupied port
[ 68.308056] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 68.332176] ata5.00: configured for UDMA/100
[ 68.343497] ata5: EH complete
[ 75.808054] ata5.00: limiting speed to UDMA/66:PIO4
[ 75.808061] ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
frozen
[ 75.808081] ata5.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0
dma 16416 in
[ 75.808084] ata5.00: status: { DRDY }
[ 75.808089] ata5: hard resetting link
[ 75.808091] ata5: nv: skipping hardreset on occupied port
[ 76.276050] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 76.300125] ata5.00: configured for UDMA/66
[ 76.307490] ata5: EH complete
[ 136.868049] ata5.00: limiting speed to UDMA/33:PIO4
[ 136.868058] ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
frozen
[ 136.868078] ata5.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0
dma 16416 in
[ 136.868081] ata5.00: status: { DRDY }
[ 136.868087] ata5: hard resetting link
[ 136.868089] ata5: nv: skipping hardreset on occupied port
[ 137.332073] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 137.356170] ata5.00: configured for UDMA/33
[ 137.866272] ata5: EH complete
watchtv@teevee:~$
****************************************************************
Keywords: device drivers, hardware
****************************************************************
watchtv@teevee:~$ cat /proc/version
Linux version 3.11.0-031100rc5-generic (apw@gomeisa) (gcc version 4.6.3
(Ubuntu/Linaro 4.6.3-1ubuntu5) ) #201308112135 SMP Mon Aug 12 01:35:49
UTC 2013
watchtv@teevee:~$
****************************************************************
watchtv@teevee:~$ lsb_release -rd
Description: Ubuntu Saucy Salamander (development branch)
Release: 13.10
watchtv@teevee:~$
****************************************************************
watchtv@teevee:/usr/src/linux-headers-3.11.0-031100rc5/scripts$ ./ver_linux
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
Linux teevee 3.11.0-031100rc5-generic #201308112135 SMP Mon Aug 12
01:35:49 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Gnu C 4.8
Gnu make 3.81
binutils 2.23.52.20130727
util-linux 2.20.1
mount support
module-init-tools 9
e2fsprogs 1.42.8
pcmciautils 018
PPP 2.4.5
Linux C Library 2.17
Dynamic linker (ldd) 2.17
Procps 3.3.3
Net-tools 1.60
Kbd 1.15.5
Sh-utils 8.20
wireless-tools 30
Modules Loaded bnep rfcomm bluetooth snd_hda_codec_hdmi nvidia
hid_generic usbhid hid joydev xpad snd_hda_codec_realtek ff_memless
snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_page_alloc
snd_seq_midi kvm snd_seq_midi_event ppdev snd_rawmidi snd_seq
snd_seq_device snd_timer edac_core snd k8temp serio_raw edac_mce_amd
soundcore ohci_pci i2c_nforce2 parport_pc mac_hid lp parport sata_nv
pata_acpi forcedeth pata_amd
****************************************************************
watchtv@teevee:/usr/src/linux-headers-3.11.0-031100rc5/scripts$ cat
/proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 107
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 5200+
stepping : 2
microcode : 0x83
cpu MHz : 2700.000
cache size : 512 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext
fxsr_opt rdtscp lm 3dnowext 3dnow rep_good nopl extd_apicid pni cx16
lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch lbrv
bogomips : 5424.74
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc 100mhzsteps
processor : 1
vendor_id : AuthenticAMD
cpu family : 15
model : 107
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 5200+
stepping : 2
microcode : 0x83
cpu MHz : 2700.000
cache size : 512 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext
fxsr_opt rdtscp lm 3dnowext 3dnow rep_good nopl extd_apicid pni cx16
lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch lbrv
bogomips : 5424.74
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc 100mhzsteps
watchtv@teevee:/usr/src/linux-headers-3.11.0-031100rc5/scripts$
****************************************************************
watchtv@teevee:/usr/src/linux-headers-3.11.0-031100rc5/scripts$ cat
/proc/modules
bnep 23966 2 - Live 0x0000000000000000
rfcomm 74589 6 - Live 0x0000000000000000
bluetooth 391564 10 bnep,rfcomm, Live 0x0000000000000000
snd_hda_codec_hdmi 41688 4 - Live 0x0000000000000000
nvidia 11309674 40 - Live 0x0000000000000000 (POF)
hid_generic 12548 0 - Live 0x0000000000000000
usbhid 53329 0 - Live 0x0000000000000000
hid 105557 2 hid_generic,usbhid, Live 0x0000000000000000
joydev 17613 0 - Live 0x0000000000000000
xpad 18546 0 - Live 0x0000000000000000
snd_hda_codec_realtek 56259 1 - Live 0x0000000000000000
ff_memless 13704 1 xpad, Live 0x0000000000000000
snd_hda_intel 53038 7 - Live 0x0000000000000000
snd_hda_codec 194727 3
snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_intel, Live
0x0000000000000000
snd_hwdep 13613 1 snd_hda_codec, Live 0x0000000000000000
snd_pcm 107140 4 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec, Live
0x0000000000000000
snd_page_alloc 18798 2 snd_hda_intel,snd_pcm, Live 0x0000000000000000
snd_seq_midi 13324 0 - Live 0x0000000000000000
kvm 447883 0 - Live 0x0000000000000000
snd_seq_midi_event 14899 1 snd_seq_midi, Live 0x0000000000000000
ppdev 17711 0 - Live 0x0000000000000000
snd_rawmidi 30416 1 snd_seq_midi, Live 0x0000000000000000
snd_seq 66061 2 snd_seq_midi,snd_seq_midi_event, Live 0x0000000000000000
snd_seq_device 14497 3 snd_seq_midi,snd_rawmidi,snd_seq, Live
0x0000000000000000
snd_timer 29989 2 snd_pcm,snd_seq, Live 0x0000000000000000
edac_core 62914 0 - Live 0x0000000000000000
snd 69657 24
snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_seq_midi,snd_rawmidi,snd_seq,snd_seq_device,snd_timer,
Live 0x0000000000000000
k8temp 13064 0 - Live 0x0000000000000000
serio_raw 13413 0 - Live 0x0000000000000000
edac_mce_amd 22792 0 - Live 0x0000000000000000
soundcore 12680 1 snd, Live 0x0000000000000000
ohci_pci 13561 0 - Live 0x0000000000000000
i2c_nforce2 13304 0 - Live 0x0000000000000000
parport_pc 32866 1 - Live 0x0000000000000000
mac_hid 13253 0 - Live 0x0000000000000000
lp 17799 0 - Live 0x0000000000000000
parport 42466 3 ppdev,parport_pc,lp, Live 0x0000000000000000
sata_nv 32267 3 - Live 0x0000000000000000
pata_acpi 13038 0 - Live 0x0000000000000000
forcedeth 72212 0 - Live 0x0000000000000000
pata_amd 18225 0 - Live 0x0000000000000000
watchtv@teevee:/usr/src/linux-headers-3.11.0-031100rc5/scripts$
****************************************************************
watchtv@teevee:/usr/src/linux-headers-3.11.0-031100rc5/scripts$ cat
/proc/ioports
0000-0cf7 : PCI Bus 0000:00
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-0060 : keyboard
0064-0064 : keyboard
0070-0073 : rtc0
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : 0000:00:06.0
0170-0177 : pata_amd
01f0-01f7 : 0000:00:06.0
01f0-01f7 : pata_amd
0290-0294 : pnp 00:01
0295-0296 : pnp 00:01
0376-0376 : 0000:00:06.0
0376-0376 : pata_amd
0378-037a : parport0
03c0-03df : vga+
03f6-03f6 : 0000:00:06.0
03f6-03f6 : pata_amd
03f8-03ff : serial
04d0-04d1 : pnp 00:01
0800-087f : pnp 00:01
0960-0967 : 0000:00:08.1
0960-0967 : sata_nv
0970-0977 : 0000:00:08.0
0970-0977 : sata_nv
09e0-09e7 : 0000:00:08.1
09e0-09e7 : sata_nv
09f0-09f7 : 0000:00:08.0
09f0-09f7 : sata_nv
0b60-0b63 : 0000:00:08.1
0b60-0b63 : sata_nv
0b70-0b73 : 0000:00:08.0
0b70-0b73 : sata_nv
0be0-0be3 : 0000:00:08.1
0be0-0be3 : sata_nv
0bf0-0bf3 : 0000:00:08.0
0bf0-0bf3 : sata_nv
0cf8-0cff : PCI conf1
0d00-ffff : PCI Bus 0000:00
1000-1003 : ACPI PM1a_EVT_BLK
1004-1005 : ACPI PM1a_CNT_BLK
1008-100b : ACPI PM_TMR
1010-1015 : ACPI CPU throttle
101c-101c : ACPI PM2_CNT_BLK
1020-1027 : ACPI GPE0_BLK
1080-10ff : pnp 00:00
1400-147f : pnp 00:00
1480-14ff : pnp 00:00
14a0-14af : ACPI GPE1_BLK
1800-187f : pnp 00:00
1880-18ff : pnp 00:00
1c00-1c3f : 0000:00:01.1
1c00-1c3f : nForce2_smbus
1c40-1c7f : 0000:00:01.1
1c40-1c7f : nForce2_smbus
a000-afff : PCI Bus 0000:02
ac00-ac7f : 0000:02:00.0
b000-bfff : PCI Bus 0000:01
c400-c40f : 0000:00:08.1
c400-c40f : sata_nv
d800-d80f : 0000:00:08.0
d800-d80f : sata_nv
ec00-ec07 : 0000:00:07.0
ec00-ec07 : forcedeth
f000-f00f : 0000:00:06.0
f000-f00f : pata_amd
fc00-fc3f : 0000:00:01.1
watchtv@teevee:/usr/src/linux-headers-3.11.0-031100rc5/scripts$
****************************************************************
watchtv@teevee:~$ cat /proc/iomem
00000000-00000fff : reserved
00001000-0009f7ff : System RAM
0009f800-0009ffff : reserved
000a0000-000bffff : PCI Bus 0000:00
000c0000-000dffff : PCI Bus 0000:00
000c0000-000c7fff : Video ROM
000d0000-000d17ff : Adapter ROM
000d1800-000d3fff : pnp 00:0a
000f0000-000fffff : reserved
000f0000-000fffff : System ROM
00100000-bfedffff : System RAM
01000000-01738813 : Kernel code
01738814-01d0e73f : Kernel data
01e70000-01fe2fff : Kernel bss
b4000000-b7ffffff : GART
bfee0000-bfee2fff : ACPI Non-volatile Storage
bfee3000-bfeeffff : ACPI Tables
bfef0000-bfefffff : reserved
bfef0000-bfefffff : pnp 00:0a
bff00000-bfffffff : RAM buffer
c0000000-dfffffff : PCI Bus 0000:00
c0000000-dfffffff : PCI Bus 0000:02
c0000000-cfffffff : 0000:02:00.0
d0000000-d007ffff : 0000:02:00.0
de000000-dfffffff : 0000:02:00.0
e0000000-febfffff : reserved
e4000000-febfffff : PCI Bus 0000:00
fb000000-fcffffff : PCI Bus 0000:02
fb000000-fbffffff : 0000:02:00.0
fb000000-fbffffff : nvidia
fcffc000-fcffffff : 0000:02:00.1
fcffc000-fcffffff : ICH HD audio
fde00000-fdefffff : PCI Bus 0000:01
fdf00000-fdffffff : PCI Bus 0000:01
fe024000-fe027fff : 0000:00:05.0
fe024000-fe027fff : ICH HD audio
fe02b000-fe02bfff : 0000:00:08.1
fe02b000-fe02bfff : sata_nv
fe02c000-fe02cfff : 0000:00:08.0
fe02c000-fe02cfff : sata_nv
fe02d000-fe02dfff : 0000:00:07.0
fe02d000-fe02dfff : forcedeth
fe02e000-fe02e0ff : 0000:00:02.1
fe02e000-fe02e0ff : ehci_hcd
fe02f000-fe02ffff : 0000:00:02.0
fe02f000-fe02ffff : ohci_hcd
fec00000-ffffffff : reserved
fec00000-fec003ff : IOAPIC 0
fee00000-fee00fff : Local APIC
fee00000-fee00fff : pnp 00:0a
fefe0000-fefe01ff : pnp 00:00
fefe1000-fefe10ff : pnp 00:00
feff0000-feff03ff : HPET 0
ffff0000-ffffffff : pnp 00:0a
100000000-13fffffff : System RAM
watchtv@teevee:~$
****************************************************************
watchtv@teevee:~$ sudo lspci -vvv
00:00.0 RAM memory: NVIDIA Corporation MCP61 Host Bridge (rev a1)
Subsystem: Gigabyte Technology Co., Ltd Device 5001
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
Capabilities: [44] HyperTransport: Slave or Primary Interface
Command: BaseUnitID=0 UnitCnt=17 MastHost- DefDir- DUL-
Link Control 0: CFlE- CST- CFE- <LkFail- Init+ EOC- TXO-
<CRCErr=0 IsocEn- LSEn- ExtCTL- 64b-
Link Config 0: MLWI=16bit DwFcIn- MLWO=16bit DwFcOut- LWI=16bit
DwFcInEn- LWO=16bit DwFcOutEn-
Link Control 1: CFlE- CST- CFE- <LkFail+ Init- EOC+ TXO+
<CRCErr=0 IsocEn- LSEn- ExtCTL- 64b-
Link Config 1: MLWI=8bit DwFcIn- MLWO=8bit DwFcOut- LWI=8bit
DwFcInEn- LWO=8bit DwFcOutEn-
Revision ID: 1.03
Link Frequency 0: 1.0GHz
Link Error 0: <Prot- <Ovfl- <EOC- CTLTm-
Link Frequency Capability 0: 200MHz+ 300MHz+ 400MHz+ 500MHz+
600MHz+ 800MHz+ 1.0GHz+ 1.2GHz- 1.4GHz- 1.6GHz- Vend-
Feature Capability: IsocFC+ LDTSTOP+ CRCTM- ECTLT- 64bA- UIDRD-
Link Frequency 1: 200MHz
Link Error 1: <Prot- <Ovfl- <EOC- CTLTm-
Link Frequency Capability 1: 200MHz- 300MHz- 400MHz- 500MHz-
600MHz- 800MHz- 1.0GHz- 1.2GHz- 1.4GHz- 1.6GHz- Vend-
Error Handling: PFlE+ OFlE+ PFE- OFE- EOCFE- RFE- CRCFE-
SERRFE- CF- RE- PNFE- ONFE- EOCNFE- RNFE- CRCNFE- SERRNFE-
Prefetchable memory behind bridge Upper: 00-00
Bus Number: 00
Capabilities: [dc] HyperTransport: MSI Mapping Enable+ Fixed-
Mapping Address Base: 00000000fee00000
00:01.0 ISA bridge: NVIDIA Corporation MCP61 LPC Bridge (rev a2)
Subsystem: Gigabyte Technology Co., Ltd Device 0c11
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
00:01.1 SMBus: NVIDIA Corporation MCP61 SMBus (rev a2)
Subsystem: Gigabyte Technology Co., Ltd Device 0c11
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-
Interrupt: pin A routed to IRQ 5
Region 0: I/O ports at fc00 [size=64]
Region 4: I/O ports at 1c00 [size=64]
Region 5: I/O ports at 1c40 [size=64]
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-
Kernel driver in use: nForce2_smbus
00:01.2 RAM memory: NVIDIA Corporation MCP61 Memory Controller (rev a2)
Subsystem: Gigabyte Technology Co., Ltd Device 0c11
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-
00:02.0 USB controller: NVIDIA Corporation MCP61 USB 1.1 Controller (rev
a3) (prog-if 10 [OHCI])
Subsystem: Gigabyte Technology Co., Ltd Device 5004
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 23
Region 0: Memory at fe02f000 (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-
Kernel driver in use: ohci-pci
00:02.1 USB controller: NVIDIA Corporation MCP61 USB 2.0 Controller (rev
a3) (prog-if 20 [EHCI])
Subsystem: Gigabyte Technology Co., Ltd Device 5004
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 B routed to IRQ 22
Region 0: Memory at fe02e000 (32-bit, non-prefetchable) [size=256]
Capabilities: [44] Debug port: BAR=1 offset=0098
Capabilities: [80] 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+
Kernel driver in use: ehci-pci
00:04.0 PCI bridge: NVIDIA Corporation MCP61 PCI bridge (rev a1)
(prog-if 01 [Subtractive decode])
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
Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
I/O behind bridge: 0000b000-0000bfff
Memory behind bridge: fdf00000-fdffffff
Prefetchable memory behind bridge: fde00000-fdefffff
Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr+ DiscTmrStat- DiscTmrSERREn-
Capabilities: [b8] Subsystem: Gigabyte Technology Co., Ltd Device 026f
Capabilities: [8c] HyperTransport: MSI Mapping Enable- Fixed-
Mapping Address Base: 00000000fee00000
00:05.0 Audio device: NVIDIA Corporation MCP61 High Definition Audio
(rev a2)
Subsystem: Gigabyte Technology Co., Ltd Device a002
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 (500ns min, 1250ns max)
Interrupt: pin B routed to IRQ 22
Region 0: Memory at fe024000 (32-bit, non-prefetchable) [size=16K]
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: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
Address: 0000000000000000 Data: 0000
Masking: 00000000 Pending: 00000000
Capabilities: [6c] HyperTransport: MSI Mapping Enable- Fixed+
Kernel driver in use: snd_hda_intel
00:06.0 IDE interface: NVIDIA Corporation MCP61 IDE (rev a2) (prog-if 8a
[Master SecP PriP])
Subsystem: Gigabyte Technology Co., Ltd Device 5002
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)
Region 0: [virtual] Memory at 000001f0 (32-bit, non-prefetchable)
[size=8]
Region 1: [virtual] Memory at 000003f0 (type 3, non-prefetchable)
[size=1]
Region 2: [virtual] Memory at 00000170 (32-bit, non-prefetchable)
[size=8]
Region 3: [virtual] Memory at 00000370 (type 3, non-prefetchable)
[size=1]
Region 4: I/O ports at f000 [size=16]
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-
Kernel driver in use: pata_amd
00:07.0 Bridge: NVIDIA Corporation MCP61 Ethernet (rev a2)
Subsystem: Gigabyte Technology Co., Ltd Device e000
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 (250ns min, 5000ns max)
Interrupt: pin A routed to IRQ 41
Region 0: Memory at fe02d000 (32-bit, non-prefetchable) [size=4K]
Region 1: I/O ports at ec00 [size=8]
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: [50] MSI: Enable+ Count=1/8 Maskable+ 64bit+
Address: 00000000fee0100c Data: 41a1
Masking: 000000fe Pending: 00000000
Capabilities: [6c] HyperTransport: MSI Mapping Enable- Fixed+
Kernel driver in use: forcedeth
00:08.0 IDE interface: NVIDIA Corporation MCP61 SATA Controller (rev a2)
(prog-if 85 [Master SecO PriO])
Subsystem: Gigabyte Technology Co., Ltd Device b002
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 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 d800 [size=16]
Region 5: Memory at fe02c000 (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
00:08.1 IDE interface: NVIDIA Corporation MCP61 SATA Controller (rev a2)
(prog-if 85 [Master SecO PriO])
Subsystem: Gigabyte Technology Co., Ltd Device b002
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 B routed to IRQ 23
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 c400 [size=16]
Region 5: Memory at fe02b000 (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
00:09.0 PCI bridge: NVIDIA Corporation MCP61 PCI Express bridge (rev a2)
(prog-if 00 [Normal decode])
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, Cache Line Size: 4 bytes
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: 0000a000-0000afff
Memory behind bridge: fb000000-fcffffff
Prefetchable memory behind bridge: 00000000c0000000-00000000dfffffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Subsystem: NVIDIA Corporation Device 0000
Capabilities: [48] 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: [50] MSI: Enable+ Count=1/2 Maskable- 64bit+
Address: 00000000fee0300c Data: 4161
Capabilities: [60] HyperTransport: MSI Mapping Enable- Fixed-
Mapping Address Base: 00000000fee00000
Capabilities: [80] Express (v1) Root Port (Slot+), MSI 00
DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s
<64ns, L1 <1us
ExtTag- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ UncorrErr+ FatalErr- UnsuppReq- AuxPwr-
TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1,
Latency L0 <512ns, L1 <4us
ClockPM- Surprise- LLActRep+ BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+
DLActive+ BWMgmt- ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug-
Surprise-
Slot #1, PowerLimit 75.000W; Interlock- NoCompl-
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt-
HPIrq- LinkChg-
Control: AttnInd Off, PwrInd On, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+
Interlock-
Changed: MRL- PresDet+ LinkState+
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna-
CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
Capabilities: [100 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=WRR32
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
Status: NegoPending- InProgress-
Kernel driver in use: pcieport
00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] K8
[Athlon64/Opteron] HyperTransport Technology Configuration
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-
Capabilities: [80] HyperTransport: Host or Secondary Interface
Command: WarmRst+ DblEnd- DevNum=0 ChainSide- HostHide+ Slave-
<EOCErr- DUL-
Link Control: CFlE- CST- CFE- <LkFail- Init+ EOC- TXO-
<CRCErr=0 IsocEn- LSEn- ExtCTL- 64b-
Link Config: MLWI=16bit DwFcIn- MLWO=16bit DwFcOut- LWI=16bit
DwFcInEn- LWO=16bit DwFcOutEn-
Revision ID: 1.02
Link Frequency: 1.0GHz
Link Error: <Prot- <Ovfl- <EOC- CTLTm-
Link Frequency Capability: 200MHz+ 300MHz- 400MHz+ 500MHz-
600MHz+ 800MHz+ 1.0GHz+ 1.2GHz- 1.4GHz- 1.6GHz- Vend-
Feature Capability: IsocFC- LDTSTOP+ CRCTM- ECTLT- 64bA- UIDRD-
ExtRS- UCnfE-
00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] K8
[Athlon64/Opteron] Address Map
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-
00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] K8
[Athlon64/Opteron] DRAM Controller
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-
00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] K8
[Athlon64/Opteron] Miscellaneous Control
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-
Capabilities: [f0] Secure device <?>
Kernel driver in use: k8temp
02:00.0 VGA compatible controller: NVIDIA Corporation GT218 [GeForce
210] (rev a2) (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. EN210 SILENT
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
Interrupt: pin A routed to IRQ 16
Region 0: Memory at fb000000 (32-bit, non-prefetchable) [size=16M]
Region 1: Memory at c0000000 (64-bit, prefetchable) [size=256M]
Region 3: Memory at de000000 (64-bit, prefetchable) [size=32M]
Region 5: I/O ports at ac00 [size=128]
[virtual] Expansion ROM at d0000000 [disabled] [size=512K]
Capabilities: [60] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [78] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s
unlimited, L1 <64us
ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
Unsupported-
RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr-
TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1,
Latency L0 <512ns, L1 <4us
ClockPM+ Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 128 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+
DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Not Supported, TimeoutDis+
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance-
SpeedDis-, Selectable De-emphasis: -6dB
Transmit Margin: Normal Operating Range,
EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB,
EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-,
LinkEqualizationRequest-
Capabilities: [b4] Vendor Specific Information: Len=14 <?>
Capabilities: [100 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
Status: NegoPending- InProgress-
Capabilities: [128 v1] Power Budgeting <?>
Capabilities: [600 v1] Vendor Specific Information: ID=0001 Rev=1
Len=024 <?>
Kernel driver in use: nvidia
02:00.1 Audio device: NVIDIA Corporation High Definition Audio
Controller (rev a1)
Subsystem: ASUSTeK Computer Inc. Device 8334
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, Cache Line Size: 4 bytes
Interrupt: pin B routed to IRQ 16
Region 0: Memory at fcffc000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [60] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [78] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us,
L1 <64us
ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
Unsupported-
RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr-
TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1,
Latency L0 <512ns, L1 <1us
ClockPM+ Surprise- LLActRep- BwNot-
LnkCtl: ASPM L0s L1 Enabled; RCB 128 bytes Disabled-
Retrain- CommClk+
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+
DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Not Supported, TimeoutDis+
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance-
SpeedDis-, Selectable De-emphasis: -6dB
Transmit Margin: Normal Operating Range,
EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB,
EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-,
LinkEqualizationRequest-
Kernel driver in use: snd_hda_intel
****************************************************************
watchtv@teevee:~$ cat /proc/scsi/scsi
Attached devices:
Host: scsi2 Channel: 00 Id: 00 Lun: 00
Vendor: ATA Model: WDC WD20EARS-00M Rev: 51.0
Type: Direct-Access ANSI SCSI revision: 05
Host: scsi4 Channel: 00 Id: 00 Lun: 00
Vendor: ATAPI Model: iHOS104 Rev: WL0F
Type: CD-ROM ANSI SCSI revision: 05
watchtv@teevee:~$
****************************************************************
watchtv@teevee:~$ ls /proc
1 11 1235 154 24 34 3774 3825 39 3996 48 624
811 9174 dma kmsg pagetypeinfo timer_list
10 11088 1258 155 25 3442 3782 3828 3906 40 487 625
82 923 driver kpagecount partitions timer_stats
1054 11288 129 156 26 3447 3786 383 3908 4010 49 63
828 acpi execdomains kpageflags sched_debug tty
10641 11310 13 16 27 35 3788 3834 3919 4021 490 643
83 asound fb latency_stats schedstat uptime
10653 11376 130 17 2799 36 3790 3837 3937 41 492 7
838 buddyinfo filesystems loadavg scsi version
10657 11380 135 18 283 3660 38 3847 3939 424 5 744 841
bus fs locks self vmallocinfo
10663 11397 136 19 29 37 3800 3848 3949 426 50 772
860 cgroups interrupts mdstat slabinfo vmstat
10718 11398 138 2 293 3701 3808 3851 3955 428 575 773
875 cmdline iomem meminfo softirqs zoneinfo
10752 11418 14 20 3 3703 3810 3853 3969 429 587 782
890 consoles ioports misc stat
10834 11421 140 21 30 3752 3813 3856 3974 44 606 792
899 cpuinfo irq modules swaps
10835 1166 1443 218 31 3755 3814 3859 3976 45 609 793
9 crypto kallsyms mounts sys
1084 1199 15 22 32 3756 3821 3870 3982 46 61 796
914 devices kcore mtrr sysrq-trigger
10981 12 153 23 33 3771 3822 3878 3987 47 617 8
916 diskstats key-users net sysvipc
watchtv@teevee:~$
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: System fails to connect to iHOS-104 DVD drive with nvidia MCP61 chipset.
2013-08-13 22:36 System fails to connect to iHOS-104 DVD drive with nvidia MCP61 chipset Bruce Link
@ 2013-08-14 6:17 ` Robert Hancock
2013-08-14 22:17 ` Bruce Link
0 siblings, 1 reply; 19+ messages in thread
From: Robert Hancock @ 2013-08-14 6:17 UTC (permalink / raw)
To: Bruce Link; +Cc: linux-ide, 1063474
On 08/13/2013 04:36 PM, Bruce Link wrote:
> On bootup, when trying to attach to a Lite-on iHOS-104 DVD drive, the
> kernel attempts to establish a connection to the CD drive at a variety
> of speeds. Ultimately it fails with a "TEST_UNIT_READY failed
> (err_mask=0x4)" message
>
> ****************************************************************
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1063474
>
> ****************************************************************
> The relevant DMESG output is listed below:
> watchtv@teevee:~$ dmesg|grep ata5
> [ 1.088342] ata5: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0 bmdma 0xc400
> irq 23
> [ 1.556031] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> [ 1.564134] ata5.00: ATAPI: ATAPI iHOS104, WL0F, max UDMA/100
> [ 1.580115] ata5.00: configured for UDMA/100
> [ 6.580029] ata5.00: qc timeout (cmd 0xa0)
> [ 6.580036] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
> [ 7.048044] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> [ 7.072129] ata5.00: configured for UDMA/100
> [ 29.856040] ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
> frozen
> [ 29.856063] ata5.00: cmd a0/01:00:00:60:00/00:00:00:00:00/a0 tag 0
> dma 96 in
> [ 29.856065] ata5.00: status: { DRDY }
> [ 29.856071] ata5: hard resetting link
> [ 29.856073] ata5: nv: skipping hardreset on occupied port
> [ 30.324070] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> [ 30.348152] ata5.00: configured for UDMA/100
> [ 35.348125] ata5.00: qc timeout (cmd 0xa0)
> [ 35.348132] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
> [ 35.348139] ata5: hard resetting link
> [ 35.348141] ata5: nv: skipping hardreset on occupied port
> [ 35.816115] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> [ 35.840125] ata5.00: configured for UDMA/100
> [ 36.835824] ata5: EH complete
> [ 67.840151] ata5: limiting SATA link speed to 1.5 Gbps
> [ 67.840159] ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
> frozen
> [ 67.840178] ata5.00: cmd a0/01:00:00:80:00/00:00:00:00:00/a0 tag 0
> dma 16512 in
> [ 67.840181] ata5.00: status: { DRDY }
> [ 67.840187] ata5: hard resetting link
> [ 67.840188] ata5: nv: skipping hardreset on occupied port
> [ 68.308056] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> [ 68.332176] ata5.00: configured for UDMA/100
> [ 68.343497] ata5: EH complete
> [ 75.808054] ata5.00: limiting speed to UDMA/66:PIO4
> [ 75.808061] ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
> frozen
> [ 75.808081] ata5.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0
> dma 16416 in
> [ 75.808084] ata5.00: status: { DRDY }
> [ 75.808089] ata5: hard resetting link
> [ 75.808091] ata5: nv: skipping hardreset on occupied port
> [ 76.276050] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> [ 76.300125] ata5.00: configured for UDMA/66
> [ 76.307490] ata5: EH complete
> [ 136.868049] ata5.00: limiting speed to UDMA/33:PIO4
> [ 136.868058] ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
> frozen
> [ 136.868078] ata5.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0
> dma 16416 in
> [ 136.868081] ata5.00: status: { DRDY }
> [ 136.868087] ata5: hard resetting link
> [ 136.868089] ata5: nv: skipping hardreset on occupied port
> [ 137.332073] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> [ 137.356170] ata5.00: configured for UDMA/33
> [ 137.866272] ata5: EH complete
These NVIDIA SATA controllers are a pain as they all seem to have a
different set of bugs related to hardreset, etc. What happens if you
boot up without the drive connected and then plug in the cable after the
system boots up?
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: System fails to connect to iHOS-104 DVD drive with nvidia MCP61 chipset.
2013-08-14 6:17 ` Robert Hancock
@ 2013-08-14 22:17 ` Bruce Link
2013-08-15 5:36 ` Robert Hancock
0 siblings, 1 reply; 19+ messages in thread
From: Bruce Link @ 2013-08-14 22:17 UTC (permalink / raw)
To: Robert Hancock; +Cc: linux-ide, 1063474
On 8/14/2013 1:17 AM, Robert Hancock wrote:
> On 08/13/2013 04:36 PM, Bruce Link wrote:
>> On bootup, when trying to attach to a Lite-on iHOS-104 DVD drive, the
>> kernel attempts to establish a connection to the CD drive at a variety
>> of speeds. Ultimately it fails with a "TEST_UNIT_READY failed
>> (err_mask=0x4)" message
>>
>> ****************************************************************
>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1063474
>>
>> ****************************************************************
>> The relevant DMESG output is listed below:
>> watchtv@teevee:~$ dmesg|grep ata5
>> [ 1.088342] ata5: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0 bmdma 0xc400
>> irq 23
>> [ 1.556031] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>> [ 1.564134] ata5.00: ATAPI: ATAPI iHOS104, WL0F, max UDMA/100
>> [ 1.580115] ata5.00: configured for UDMA/100
>> [ 6.580029] ata5.00: qc timeout (cmd 0xa0)
>> [ 6.580036] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
>> [ 7.048044] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>> [ 7.072129] ata5.00: configured for UDMA/100
>> [ 29.856040] ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
>> frozen
>> [ 29.856063] ata5.00: cmd a0/01:00:00:60:00/00:00:00:00:00/a0 tag 0
>> dma 96 in
>> [ 29.856065] ata5.00: status: { DRDY }
>> [ 29.856071] ata5: hard resetting link
>> [ 29.856073] ata5: nv: skipping hardreset on occupied port
>> [ 30.324070] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>> [ 30.348152] ata5.00: configured for UDMA/100
>> [ 35.348125] ata5.00: qc timeout (cmd 0xa0)
>> [ 35.348132] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
>> [ 35.348139] ata5: hard resetting link
>> [ 35.348141] ata5: nv: skipping hardreset on occupied port
>> [ 35.816115] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>> [ 35.840125] ata5.00: configured for UDMA/100
>> [ 36.835824] ata5: EH complete
>> [ 67.840151] ata5: limiting SATA link speed to 1.5 Gbps
>> [ 67.840159] ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
>> frozen
>> [ 67.840178] ata5.00: cmd a0/01:00:00:80:00/00:00:00:00:00/a0 tag 0
>> dma 16512 in
>> [ 67.840181] ata5.00: status: { DRDY }
>> [ 67.840187] ata5: hard resetting link
>> [ 67.840188] ata5: nv: skipping hardreset on occupied port
>> [ 68.308056] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>> [ 68.332176] ata5.00: configured for UDMA/100
>> [ 68.343497] ata5: EH complete
>> [ 75.808054] ata5.00: limiting speed to UDMA/66:PIO4
>> [ 75.808061] ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
>> frozen
>> [ 75.808081] ata5.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0
>> dma 16416 in
>> [ 75.808084] ata5.00: status: { DRDY }
>> [ 75.808089] ata5: hard resetting link
>> [ 75.808091] ata5: nv: skipping hardreset on occupied port
>> [ 76.276050] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>> [ 76.300125] ata5.00: configured for UDMA/66
>> [ 76.307490] ata5: EH complete
>> [ 136.868049] ata5.00: limiting speed to UDMA/33:PIO4
>> [ 136.868058] ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
>> frozen
>> [ 136.868078] ata5.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0
>> dma 16416 in
>> [ 136.868081] ata5.00: status: { DRDY }
>> [ 136.868087] ata5: hard resetting link
>> [ 136.868089] ata5: nv: skipping hardreset on occupied port
>> [ 137.332073] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>> [ 137.356170] ata5.00: configured for UDMA/33
>> [ 137.866272] ata5: EH complete
>
> These NVIDIA SATA controllers are a pain as they all seem to have a
> different set of bugs related to hardreset, etc. What happens if you
> boot up without the drive connected and then plug in the cable after
> the system boots up?
Roughly the same error is returned. See below for the dmesg output.
root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0#
echo "- - -" > /sys/class/scsi_host/host4/scan
root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0#
dmesg|grep ata5
[ 1.030224] ata5: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0 bmdma 0xc400
irq 20
[ 1.354216] ata5: SATA link down (SStatus 0 SControl 300)
[ 944.773288] ata5: exception Emask 0x10 SAct 0x0 SErr 0x50000 action 0xf
[ 944.773304] ata5: SError: { PHYRdyChg CommWake }
[ 944.773322] ata5: hard resetting link
[ 945.652070] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 945.660176] ata5.00: ATAPI: ATAPI iHOS104, WL0F, max UDMA/100
[ 945.676165] ata5.00: configured for UDMA/100
[ 950.676049] ata5.00: qc timeout (cmd 0xa0)
[ 950.676056] ata5.00: TEST_UNIT_READY failed (err_mask=0x5)
[ 950.676064] ata5: hard resetting link
[ 950.676066] ata5: nv: skipping hardreset on occupied port
[ 951.144073] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 951.168168] ata5.00: configured for UDMA/100
[ 956.168049] ata5.00: qc timeout (cmd 0xa0)
[ 956.168057] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[ 956.168061] ata5: limiting SATA link speed to 1.5 Gbps
[ 956.168064] ata5.00: limiting speed to UDMA/100:PIO3
[ 956.168070] ata5: hard resetting link
[ 956.168072] ata5: nv: skipping hardreset on occupied port
[ 956.636056] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 956.660169] ata5.00: configured for UDMA/100
[ 961.660036] ata5.00: qc timeout (cmd 0xa0)
[ 961.660044] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[ 961.660046] ata5.00: disabled
[ 961.660061] ata5: hard resetting link
[ 962.544045] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[ 962.544061] ata5: EH complete
root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0#
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: System fails to connect to iHOS-104 DVD drive with nvidia MCP61 chipset.
2013-08-14 22:17 ` Bruce Link
@ 2013-08-15 5:36 ` Robert Hancock
2013-08-16 2:47 ` Bruce Link
0 siblings, 1 reply; 19+ messages in thread
From: Robert Hancock @ 2013-08-15 5:36 UTC (permalink / raw)
To: Bruce Link; +Cc: linux-ide, 1063474
On Wed, Aug 14, 2013 at 4:17 PM, Bruce Link <Bruce@1045.ca> wrote:
>> These NVIDIA SATA controllers are a pain as they all seem to have a
>> different set of bugs related to hardreset, etc. What happens if you boot up
>> without the drive connected and then plug in the cable after the system
>> boots up?
>
> Roughly the same error is returned. See below for the dmesg output.
>
> root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0#
> echo "- - -" > /sys/class/scsi_host/host4/scan
> root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0#
> dmesg|grep ata5
> [ 1.030224] ata5: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0 bmdma 0xc400 irq
> 20
> [ 1.354216] ata5: SATA link down (SStatus 0 SControl 300)
> [ 944.773288] ata5: exception Emask 0x10 SAct 0x0 SErr 0x50000 action 0xf
> [ 944.773304] ata5: SError: { PHYRdyChg CommWake }
> [ 944.773322] ata5: hard resetting link
> [ 945.652070] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> [ 945.660176] ata5.00: ATAPI: ATAPI iHOS104, WL0F, max UDMA/100
> [ 945.676165] ata5.00: configured for UDMA/100
> [ 950.676049] ata5.00: qc timeout (cmd 0xa0)
> [ 950.676056] ata5.00: TEST_UNIT_READY failed (err_mask=0x5)
> [ 950.676064] ata5: hard resetting link
> [ 950.676066] ata5: nv: skipping hardreset on occupied port
> [ 951.144073] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> [ 951.168168] ata5.00: configured for UDMA/100
> [ 956.168049] ata5.00: qc timeout (cmd 0xa0)
> [ 956.168057] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
> [ 956.168061] ata5: limiting SATA link speed to 1.5 Gbps
> [ 956.168064] ata5.00: limiting speed to UDMA/100:PIO3
> [ 956.168070] ata5: hard resetting link
> [ 956.168072] ata5: nv: skipping hardreset on occupied port
> [ 956.636056] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> [ 956.660169] ata5.00: configured for UDMA/100
> [ 961.660036] ata5.00: qc timeout (cmd 0xa0)
> [ 961.660044] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
> [ 961.660046] ata5.00: disabled
> [ 961.660061] ata5: hard resetting link
> [ 962.544045] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
> [ 962.544061] ata5: EH complete
> root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0#
>
Hmm, it did a hard reset on the hotplug with seemingly the same
effect. Can we narrow down the problem any more: does this drive work
on this machine under any Linux version, or in Windows? Can you try it
in another Linux machine with a different controller to see if it
works there?
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: System fails to connect to iHOS-104 DVD drive with nvidia MCP61 chipset.
2013-08-15 5:36 ` Robert Hancock
@ 2013-08-16 2:47 ` Bruce Link
2013-08-17 17:32 ` Bruce Link
0 siblings, 1 reply; 19+ messages in thread
From: Bruce Link @ 2013-08-16 2:47 UTC (permalink / raw)
To: Robert Hancock; +Cc: linux-ide, 1063474
On 8/15/2013 12:36 AM, Robert Hancock wrote:
> On Wed, Aug 14, 2013 at 4:17 PM, Bruce Link <Bruce@1045.ca> wrote:
>>> These NVIDIA SATA controllers are a pain as they all seem to have a
>>> different set of bugs related to hardreset, etc. What happens if you boot up
>>> without the drive connected and then plug in the cable after the system
>>> boots up?
>> Roughly the same error is returned. See below for the dmesg output.
>>
>> root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0#
>> echo "- - -" > /sys/class/scsi_host/host4/scan
>> root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0#
>> dmesg|grep ata5
>> [ 1.030224] ata5: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0 bmdma 0xc400 irq
>> 20
>> [ 1.354216] ata5: SATA link down (SStatus 0 SControl 300)
>> [ 944.773288] ata5: exception Emask 0x10 SAct 0x0 SErr 0x50000 action 0xf
>> [ 944.773304] ata5: SError: { PHYRdyChg CommWake }
>> [ 944.773322] ata5: hard resetting link
>> [ 945.652070] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>> [ 945.660176] ata5.00: ATAPI: ATAPI iHOS104, WL0F, max UDMA/100
>> [ 945.676165] ata5.00: configured for UDMA/100
>> [ 950.676049] ata5.00: qc timeout (cmd 0xa0)
>> [ 950.676056] ata5.00: TEST_UNIT_READY failed (err_mask=0x5)
>> [ 950.676064] ata5: hard resetting link
>> [ 950.676066] ata5: nv: skipping hardreset on occupied port
>> [ 951.144073] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>> [ 951.168168] ata5.00: configured for UDMA/100
>> [ 956.168049] ata5.00: qc timeout (cmd 0xa0)
>> [ 956.168057] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
>> [ 956.168061] ata5: limiting SATA link speed to 1.5 Gbps
>> [ 956.168064] ata5.00: limiting speed to UDMA/100:PIO3
>> [ 956.168070] ata5: hard resetting link
>> [ 956.168072] ata5: nv: skipping hardreset on occupied port
>> [ 956.636056] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>> [ 956.660169] ata5.00: configured for UDMA/100
>> [ 961.660036] ata5.00: qc timeout (cmd 0xa0)
>> [ 961.660044] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
>> [ 961.660046] ata5.00: disabled
>> [ 961.660061] ata5: hard resetting link
>> [ 962.544045] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
>> [ 962.544061] ata5: EH complete
>> root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0#
>>
> Hmm, it did a hard reset on the hotplug with seemingly the same
> effect. Can we narrow down the problem any more: does this drive work
> on this machine under any Linux version, or in Windows? Can you try it
> in another Linux machine with a different controller to see if it
> works there?
Well, this is embarrassing.
I've always assumed the problem was with the with the motherboard, as
the DVD will always successfully boot a windows installer, so I assumed
everything with the drive was OK. On further inspection, it appears that
the drive falls down when being accessed from the WinPE environment,
much the same as in linux. I've tested this on another PC and the result
looks to be the same. I'm going to do some more testing, and will send
another email if I find out otherwise. But I think we can consider this
closed.
Sorry to be a bother.
Bruce
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: System fails to connect to iHOS-104 DVD drive with nvidia MCP61 chipset.
2013-08-16 2:47 ` Bruce Link
@ 2013-08-17 17:32 ` Bruce Link
2013-08-18 7:05 ` Robert Hancock
0 siblings, 1 reply; 19+ messages in thread
From: Bruce Link @ 2013-08-17 17:32 UTC (permalink / raw)
To: Robert Hancock; +Cc: linux-ide, 1063474
On 8/15/2013 9:47 PM, Bruce Link wrote:
> On 8/15/2013 12:36 AM, Robert Hancock wrote:
>> On Wed, Aug 14, 2013 at 4:17 PM, Bruce Link <Bruce@1045.ca> wrote:
>>>> These NVIDIA SATA controllers are a pain as they all seem to have a
>>>> different set of bugs related to hardreset, etc. What happens if
>>>> you boot up
>>>> without the drive connected and then plug in the cable after the
>>>> system
>>>> boots up?
>>> Roughly the same error is returned. See below for the dmesg output.
>>>
>>> root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0#
>>>
>>> echo "- - -" > /sys/class/scsi_host/host4/scan
>>> root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0#
>>>
>>> dmesg|grep ata5
>>> [ 1.030224] ata5: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0 bmdma
>>> 0xc400 irq
>>> 20
>>> [ 1.354216] ata5: SATA link down (SStatus 0 SControl 300)
>>> [ 944.773288] ata5: exception Emask 0x10 SAct 0x0 SErr 0x50000
>>> action 0xf
>>> [ 944.773304] ata5: SError: { PHYRdyChg CommWake }
>>> [ 944.773322] ata5: hard resetting link
>>> [ 945.652070] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>>> [ 945.660176] ata5.00: ATAPI: ATAPI iHOS104, WL0F, max UDMA/100
>>> [ 945.676165] ata5.00: configured for UDMA/100
>>> [ 950.676049] ata5.00: qc timeout (cmd 0xa0)
>>> [ 950.676056] ata5.00: TEST_UNIT_READY failed (err_mask=0x5)
>>> [ 950.676064] ata5: hard resetting link
>>> [ 950.676066] ata5: nv: skipping hardreset on occupied port
>>> [ 951.144073] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>>> [ 951.168168] ata5.00: configured for UDMA/100
>>> [ 956.168049] ata5.00: qc timeout (cmd 0xa0)
>>> [ 956.168057] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
>>> [ 956.168061] ata5: limiting SATA link speed to 1.5 Gbps
>>> [ 956.168064] ata5.00: limiting speed to UDMA/100:PIO3
>>> [ 956.168070] ata5: hard resetting link
>>> [ 956.168072] ata5: nv: skipping hardreset on occupied port
>>> [ 956.636056] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>>> [ 956.660169] ata5.00: configured for UDMA/100
>>> [ 961.660036] ata5.00: qc timeout (cmd 0xa0)
>>> [ 961.660044] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
>>> [ 961.660046] ata5.00: disabled
>>> [ 961.660061] ata5: hard resetting link
>>> [ 962.544045] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
>>> [ 962.544061] ata5: EH complete
>>> root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0#
>>>
>>>
>> Hmm, it did a hard reset on the hotplug with seemingly the same
>> effect. Can we narrow down the problem any more: does this drive work
>> on this machine under any Linux version, or in Windows? Can you try it
>> in another Linux machine with a different controller to see if it
>> works there?
> Well, this is embarrassing.
>
> I've always assumed the problem was with the with the motherboard, as
> the DVD will always successfully boot a windows installer, so I
> assumed everything with the drive was OK. On further inspection, it
> appears that the drive falls down when being accessed from the WinPE
> environment, much the same as in linux. I've tested this on another PC
> and the result looks to be the same. I'm going to do some more
> testing, and will send another email if I find out otherwise. But I
> think we can consider this closed.
>
> Sorry to be a bother.
> Bruce
I hooked up the DVD drive to a USB-SATA adapter to a PC and the DVD
drive works great (under both windows and linux). I was able to copy a
large number of files with no performance issues.
The PC that I did the second test on turns out to have a nVidia MCP51
chipset (It's a gateway GT4016 with a KTBC51G-LF motherboard). I should
have checked this beforehand.
So this problem looks to persist across different nVidia chipsets.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: System fails to connect to iHOS-104 DVD drive with nvidia MCP61 chipset.
2013-08-17 17:32 ` Bruce Link
@ 2013-08-18 7:05 ` Robert Hancock
2013-08-24 0:34 ` Bruce Link
0 siblings, 1 reply; 19+ messages in thread
From: Robert Hancock @ 2013-08-18 7:05 UTC (permalink / raw)
To: Bruce Link; +Cc: linux-ide, 1063474
On Sat, Aug 17, 2013 at 11:32 AM, Bruce Link <Bruce@1045.ca> wrote:
> On 8/15/2013 9:47 PM, Bruce Link wrote:
>>
>> On 8/15/2013 12:36 AM, Robert Hancock wrote:
>>>
>>> On Wed, Aug 14, 2013 at 4:17 PM, Bruce Link <Bruce@1045.ca> wrote:
>>>>>
>>>>> These NVIDIA SATA controllers are a pain as they all seem to have a
>>>>> different set of bugs related to hardreset, etc. What happens if you
>>>>> boot up
>>>>> without the drive connected and then plug in the cable after the system
>>>>> boots up?
>>>>
>>>> Roughly the same error is returned. See below for the dmesg output.
>>>>
>>>>
>>>> root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0#
>>>> echo "- - -" > /sys/class/scsi_host/host4/scan
>>>>
>>>> root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0#
>>>> dmesg|grep ata5
>>>> [ 1.030224] ata5: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0 bmdma 0xc400
>>>> irq
>>>> 20
>>>> [ 1.354216] ata5: SATA link down (SStatus 0 SControl 300)
>>>> [ 944.773288] ata5: exception Emask 0x10 SAct 0x0 SErr 0x50000 action
>>>> 0xf
>>>> [ 944.773304] ata5: SError: { PHYRdyChg CommWake }
>>>> [ 944.773322] ata5: hard resetting link
>>>> [ 945.652070] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>>>> [ 945.660176] ata5.00: ATAPI: ATAPI iHOS104, WL0F, max UDMA/100
>>>> [ 945.676165] ata5.00: configured for UDMA/100
>>>> [ 950.676049] ata5.00: qc timeout (cmd 0xa0)
>>>> [ 950.676056] ata5.00: TEST_UNIT_READY failed (err_mask=0x5)
>>>> [ 950.676064] ata5: hard resetting link
>>>> [ 950.676066] ata5: nv: skipping hardreset on occupied port
>>>> [ 951.144073] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>>>> [ 951.168168] ata5.00: configured for UDMA/100
>>>> [ 956.168049] ata5.00: qc timeout (cmd 0xa0)
>>>> [ 956.168057] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
>>>> [ 956.168061] ata5: limiting SATA link speed to 1.5 Gbps
>>>> [ 956.168064] ata5.00: limiting speed to UDMA/100:PIO3
>>>> [ 956.168070] ata5: hard resetting link
>>>> [ 956.168072] ata5: nv: skipping hardreset on occupied port
>>>> [ 956.636056] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>>>> [ 956.660169] ata5.00: configured for UDMA/100
>>>> [ 961.660036] ata5.00: qc timeout (cmd 0xa0)
>>>> [ 961.660044] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
>>>> [ 961.660046] ata5.00: disabled
>>>> [ 961.660061] ata5: hard resetting link
>>>> [ 962.544045] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
>>>> [ 962.544061] ata5: EH complete
>>>>
>>>> root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0#
>>>>
>>> Hmm, it did a hard reset on the hotplug with seemingly the same
>>> effect. Can we narrow down the problem any more: does this drive work
>>> on this machine under any Linux version, or in Windows? Can you try it
>>> in another Linux machine with a different controller to see if it
>>> works there?
>>
>> Well, this is embarrassing.
>>
>> I've always assumed the problem was with the with the motherboard, as the
>> DVD will always successfully boot a windows installer, so I assumed
>> everything with the drive was OK. On further inspection, it appears that the
>> drive falls down when being accessed from the WinPE environment, much the
>> same as in linux. I've tested this on another PC and the result looks to be
>> the same. I'm going to do some more testing, and will send another email if
>> I find out otherwise. But I think we can consider this closed.
>>
>> Sorry to be a bother.
>> Bruce
>
> I hooked up the DVD drive to a USB-SATA adapter to a PC and the DVD drive
> works great (under both windows and linux). I was able to copy a large
> number of files with no performance issues.
> The PC that I did the second test on turns out to have a nVidia MCP51
> chipset (It's a gateway GT4016 with a KTBC51G-LF motherboard). I should have
> checked this beforehand.
>
> So this problem looks to persist across different nVidia chipsets.
Given that it fails in Windows as well on those machines, it sounds
like there's some kind of compatibility issue between this drive and
the NV chipsets. I don't know why their SATA chipsets (at least the
pre-AHCI ones) have some many issues, but they do seem to.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: System fails to connect to iHOS-104 DVD drive with nvidia MCP61 chipset.
2013-08-18 7:05 ` Robert Hancock
@ 2013-08-24 0:34 ` Bruce Link
[not found] ` <CADLC3L0wXmVDgHPOFEkeiXD9sDUBg3tZePcJ-gRfoRN5-fXE1w@mail.gmail.com>
0 siblings, 1 reply; 19+ messages in thread
From: Bruce Link @ 2013-08-24 0:34 UTC (permalink / raw)
To: Robert Hancock; +Cc: linux-ide, 1063474
On 8/18/2013 2:05 AM, Robert Hancock wrote:
> On Sat, Aug 17, 2013 at 11:32 AM, Bruce Link <Bruce@1045.ca> wrote:
>> On 8/15/2013 9:47 PM, Bruce Link wrote:
>>> On 8/15/2013 12:36 AM, Robert Hancock wrote:
>>>> On Wed, Aug 14, 2013 at 4:17 PM, Bruce Link <Bruce@1045.ca> wrote:
>>>>>> These NVIDIA SATA controllers are a pain as they all seem to have a
>>>>>> different set of bugs related to hardreset, etc. What happens if you
>>>>>> boot up
>>>>>> without the drive connected and then plug in the cable after the system
>>>>>> boots up?
>>>>> Roughly the same error is returned. See below for the dmesg output.
>>>>>
>>>>>
>>>>> root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0#
>>>>> echo "- - -" > /sys/class/scsi_host/host4/scan
>>>>>
>>>>> root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0#
>>>>> dmesg|grep ata5
>>>>> [ 1.030224] ata5: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0 bmdma 0xc400
>>>>> irq
>>>>> 20
>>>>> [ 1.354216] ata5: SATA link down (SStatus 0 SControl 300)
>>>>> [ 944.773288] ata5: exception Emask 0x10 SAct 0x0 SErr 0x50000 action
>>>>> 0xf
>>>>> [ 944.773304] ata5: SError: { PHYRdyChg CommWake }
>>>>> [ 944.773322] ata5: hard resetting link
>>>>> [ 945.652070] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>>>>> [ 945.660176] ata5.00: ATAPI: ATAPI iHOS104, WL0F, max UDMA/100
>>>>> [ 945.676165] ata5.00: configured for UDMA/100
>>>>> [ 950.676049] ata5.00: qc timeout (cmd 0xa0)
>>>>> [ 950.676056] ata5.00: TEST_UNIT_READY failed (err_mask=0x5)
>>>>> [ 950.676064] ata5: hard resetting link
>>>>> [ 950.676066] ata5: nv: skipping hardreset on occupied port
>>>>> [ 951.144073] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>>>>> [ 951.168168] ata5.00: configured for UDMA/100
>>>>> [ 956.168049] ata5.00: qc timeout (cmd 0xa0)
>>>>> [ 956.168057] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
>>>>> [ 956.168061] ata5: limiting SATA link speed to 1.5 Gbps
>>>>> [ 956.168064] ata5.00: limiting speed to UDMA/100:PIO3
>>>>> [ 956.168070] ata5: hard resetting link
>>>>> [ 956.168072] ata5: nv: skipping hardreset on occupied port
>>>>> [ 956.636056] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>>>>> [ 956.660169] ata5.00: configured for UDMA/100
>>>>> [ 961.660036] ata5.00: qc timeout (cmd 0xa0)
>>>>> [ 961.660044] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
>>>>> [ 961.660046] ata5.00: disabled
>>>>> [ 961.660061] ata5: hard resetting link
>>>>> [ 962.544045] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
>>>>> [ 962.544061] ata5: EH complete
>>>>>
>>>>> root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0#
>>>>>
>>>> Hmm, it did a hard reset on the hotplug with seemingly the same
>>>> effect. Can we narrow down the problem any more: does this drive work
>>>> on this machine under any Linux version, or in Windows? Can you try it
>>>> in another Linux machine with a different controller to see if it
>>>> works there?
>>> Well, this is embarrassing.
>>>
>>> I've always assumed the problem was with the with the motherboard, as the
>>> DVD will always successfully boot a windows installer, so I assumed
>>> everything with the drive was OK. On further inspection, it appears that the
>>> drive falls down when being accessed from the WinPE environment, much the
>>> same as in linux. I've tested this on another PC and the result looks to be
>>> the same. I'm going to do some more testing, and will send another email if
>>> I find out otherwise. But I think we can consider this closed.
>>>
>>> Sorry to be a bother.
>>> Bruce
>> I hooked up the DVD drive to a USB-SATA adapter to a PC and the DVD drive
>> works great (under both windows and linux). I was able to copy a large
>> number of files with no performance issues.
>> The PC that I did the second test on turns out to have a nVidia MCP51
>> chipset (It's a gateway GT4016 with a KTBC51G-LF motherboard). I should have
>> checked this beforehand.
>>
>> So this problem looks to persist across different nVidia chipsets.
> Given that it fails in Windows as well on those machines, it sounds
> like there's some kind of compatibility issue between this drive and
> the NV chipsets. I don't know why their SATA chipsets (at least the
> pre-AHCI ones) have some many issues, but they do seem to.
I've located a spare HDD and loaded Windows 7 on it. In Windows 7 (not
WinPE), I am able to successfully use the BD-ROM drive on both computers
(MCP61 and MCP51 chipsets). So it appears there is a difference in the
drivers between the Windows 7 and WinPE driver. News to me.
I believe this rules out a general hardware incompatibility.
What further can I do?
Thanks
Bruce
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: System fails to connect to iHOS-104 DVD drive with nvidia MCP61 chipset.
[not found] ` <52180F76.3070803@1045.ca>
@ 2013-08-24 3:11 ` Robert Hancock
2013-08-24 15:54 ` Bruce Link
` (2 more replies)
0 siblings, 3 replies; 19+ messages in thread
From: Robert Hancock @ 2013-08-24 3:11 UTC (permalink / raw)
To: Bruce Link, linux-ide, 1063474
On Fri, Aug 23, 2013 at 6:34 PM, Bruce Link <Bruce@1045.ca> wrote:
>>
>> On 8/18/2013 2:05 AM, Robert Hancock wrote:
>>>
>>> On Sat, Aug 17, 2013 at 11:32 AM, Bruce Link <Bruce@1045.ca> wrote:
>>>>
>>>> On 8/15/2013 9:47 PM, Bruce Link wrote:
>>>>>
>>>>> On 8/15/2013 12:36 AM, Robert Hancock wrote:
>>>>>>
>>>>>> On Wed, Aug 14, 2013 at 4:17 PM, Bruce Link <Bruce@1045.ca> wrote:
>>>>>>>>
>>>>>>>> These NVIDIA SATA controllers are a pain as they all seem to have a
>>>>>>>> different set of bugs related to hardreset, etc. What happens if you
>>>>>>>> boot up
>>>>>>>> without the drive connected and then plug in the cable after the system
>>>>>>>> boots up?
>>>>>>>
>>>>>>> Roughly the same error is returned. See below for the dmesg output.
>>>>>>>
>>>>>>>
>>>>>>> root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0#
>>>>>>> echo "- - -" > /sys/class/scsi_host/host4/scan
>>>>>>>
>>>>>>> root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0#
>>>>>>> dmesg|grep ata5
>>>>>>> [ 1.030224] ata5: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0 bmdma 0xc400
>>>>>>> irq
>>>>>>> 20
>>>>>>> [ 1.354216] ata5: SATA link down (SStatus 0 SControl 300)
>>>>>>> [ 944.773288] ata5: exception Emask 0x10 SAct 0x0 SErr 0x50000 action
>>>>>>> 0xf
>>>>>>> [ 944.773304] ata5: SError: { PHYRdyChg CommWake }
>>>>>>> [ 944.773322] ata5: hard resetting link
>>>>>>> [ 945.652070] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>>>>>>> [ 945.660176] ata5.00: ATAPI: ATAPI iHOS104, WL0F, max UDMA/100
>>>>>>> [ 945.676165] ata5.00: configured for UDMA/100
>>>>>>> [ 950.676049] ata5.00: qc timeout (cmd 0xa0)
>>>>>>> [ 950.676056] ata5.00: TEST_UNIT_READY failed (err_mask=0x5)
>>>>>>> [ 950.676064] ata5: hard resetting link
>>>>>>> [ 950.676066] ata5: nv: skipping hardreset on occupied port
>>>>>>> [ 951.144073] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>>>>>>> [ 951.168168] ata5.00: configured for UDMA/100
>>>>>>> [ 956.168049] ata5.00: qc timeout (cmd 0xa0)
>>>>>>> [ 956.168057] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
>>>>>>> [ 956.168061] ata5: limiting SATA link speed to 1.5 Gbps
>>>>>>> [ 956.168064] ata5.00: limiting speed to UDMA/100:PIO3
>>>>>>> [ 956.168070] ata5: hard resetting link
>>>>>>> [ 956.168072] ata5: nv: skipping hardreset on occupied port
>>>>>>> [ 956.636056] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>>>>>>> [ 956.660169] ata5.00: configured for UDMA/100
>>>>>>> [ 961.660036] ata5.00: qc timeout (cmd 0xa0)
>>>>>>> [ 961.660044] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
>>>>>>> [ 961.660046] ata5.00: disabled
>>>>>>> [ 961.660061] ata5: hard resetting link
>>>>>>> [ 962.544045] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
>>>>>>> [ 962.544061] ata5: EH complete
>>>>>>>
>>>>>>> root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0#
>>>>>>>
>>>>>> Hmm, it did a hard reset on the hotplug with seemingly the same
>>>>>> effect. Can we narrow down the problem any more: does this drive work
>>>>>> on this machine under any Linux version, or in Windows? Can you try it
>>>>>> in another Linux machine with a different controller to see if it
>>>>>> works there?
>>>>>
>>>>> Well, this is embarrassing.
>>>>>
>>>>> I've always assumed the problem was with the with the motherboard, as the
>>>>> DVD will always successfully boot a windows installer, so I assumed
>>>>> everything with the drive was OK. On further inspection, it appears that the
>>>>> drive falls down when being accessed from the WinPE environment, much the
>>>>> same as in linux. I've tested this on another PC and the result looks to be
>>>>> the same. I'm going to do some more testing, and will send another email if
>>>>> I find out otherwise. But I think we can consider this closed.
>>>>>
>>>>> Sorry to be a bother.
>>>>> Bruce
>>>>
>>>> I hooked up the DVD drive to a USB-SATA adapter to a PC and the DVD drive
>>>> works great (under both windows and linux). I was able to copy a large
>>>> number of files with no performance issues.
>>>> The PC that I did the second test on turns out to have a nVidia MCP51
>>>> chipset (It's a gateway GT4016 with a KTBC51G-LF motherboard). I should have
>>>> checked this beforehand.
>>>>
>>>> So this problem looks to persist across different nVidia chipsets.
>>>
>>> Given that it fails in Windows as well on those machines, it sounds
>>> like there's some kind of compatibility issue between this drive and
>>> the NV chipsets. I don't know why their SATA chipsets (at least the
>>> pre-AHCI ones) have some many issues, but they do seem to.
>>
>> I've located a spare HDD and loaded Windows 7 on it. In Windows 7 (not WinPE), I am able to successfully use the BD-ROM drive on both computers (MCP61 and MCP51 chipsets). So it appears there is a difference in the drivers between the Windows 7 and WinPE driver. News to me.
>>
>> I believe this rules out a general hardware incompatibility.
>>
>> What further can I do?
(Forgot to CC the list previously)
It would likely help to confirm whether the driver that was working
was provided by NVIDIA (which may be the case even if the driver was
automatically installed by Windows setup) or was a default Microsoft
one. If it's using an NVIDIA driver then it's quite likely they're
somehow working around whatever problem we're running into.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: System fails to connect to iHOS-104 DVD drive with nvidia MCP61 chipset.
2013-08-24 3:11 ` Robert Hancock
@ 2013-08-24 15:54 ` Bruce Link
[not found] ` <5218D74A.5020305@1045.ca>
2013-09-18 0:35 ` Bruce Link
2 siblings, 0 replies; 19+ messages in thread
From: Bruce Link @ 2013-08-24 15:54 UTC (permalink / raw)
To: Robert Hancock; +Cc: linux-ide, 1063474
On 8/23/2013 10:11 PM, Robert Hancock wrote:
> On Fri, Aug 23, 2013 at 6:34 PM, Bruce Link <Bruce@1045.ca> wrote:
>>> On 8/18/2013 2:05 AM, Robert Hancock wrote:
>>>> On Sat, Aug 17, 2013 at 11:32 AM, Bruce Link <Bruce@1045.ca> wrote:
>>>>> On 8/15/2013 9:47 PM, Bruce Link wrote:
>>>>>> On 8/15/2013 12:36 AM, Robert Hancock wrote:
>>>>>>> On Wed, Aug 14, 2013 at 4:17 PM, Bruce Link <Bruce@1045.ca> wrote:
>>>>>>>>> These NVIDIA SATA controllers are a pain as they all seem to have a
>>>>>>>>> different set of bugs related to hardreset, etc. What happens if you
>>>>>>>>> boot up
>>>>>>>>> without the drive connected and then plug in the cable after the system
>>>>>>>>> boots up?
>>>>>>>> Roughly the same error is returned. See below for the dmesg output.
>>>>>>>>
>>>>>>>>
>>>>>>>> root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0#
>>>>>>>> echo "- - -" > /sys/class/scsi_host/host4/scan
>>>>>>>>
>>>>>>>> root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0#
>>>>>>>> dmesg|grep ata5
>>>>>>>> [ 1.030224] ata5: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0 bmdma 0xc400
>>>>>>>> irq
>>>>>>>> 20
>>>>>>>> [ 1.354216] ata5: SATA link down (SStatus 0 SControl 300)
>>>>>>>> [ 944.773288] ata5: exception Emask 0x10 SAct 0x0 SErr 0x50000 action
>>>>>>>> 0xf
>>>>>>>> [ 944.773304] ata5: SError: { PHYRdyChg CommWake }
>>>>>>>> [ 944.773322] ata5: hard resetting link
>>>>>>>> [ 945.652070] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>>>>>>>> [ 945.660176] ata5.00: ATAPI: ATAPI iHOS104, WL0F, max UDMA/100
>>>>>>>> [ 945.676165] ata5.00: configured for UDMA/100
>>>>>>>> [ 950.676049] ata5.00: qc timeout (cmd 0xa0)
>>>>>>>> [ 950.676056] ata5.00: TEST_UNIT_READY failed (err_mask=0x5)
>>>>>>>> [ 950.676064] ata5: hard resetting link
>>>>>>>> [ 950.676066] ata5: nv: skipping hardreset on occupied port
>>>>>>>> [ 951.144073] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>>>>>>>> [ 951.168168] ata5.00: configured for UDMA/100
>>>>>>>> [ 956.168049] ata5.00: qc timeout (cmd 0xa0)
>>>>>>>> [ 956.168057] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
>>>>>>>> [ 956.168061] ata5: limiting SATA link speed to 1.5 Gbps
>>>>>>>> [ 956.168064] ata5.00: limiting speed to UDMA/100:PIO3
>>>>>>>> [ 956.168070] ata5: hard resetting link
>>>>>>>> [ 956.168072] ata5: nv: skipping hardreset on occupied port
>>>>>>>> [ 956.636056] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>>>>>>>> [ 956.660169] ata5.00: configured for UDMA/100
>>>>>>>> [ 961.660036] ata5.00: qc timeout (cmd 0xa0)
>>>>>>>> [ 961.660044] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
>>>>>>>> [ 961.660046] ata5.00: disabled
>>>>>>>> [ 961.660061] ata5: hard resetting link
>>>>>>>> [ 962.544045] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
>>>>>>>> [ 962.544061] ata5: EH complete
>>>>>>>>
>>>>>>>> root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0#
>>>>>>>>
>>>>>>> Hmm, it did a hard reset on the hotplug with seemingly the same
>>>>>>> effect. Can we narrow down the problem any more: does this drive work
>>>>>>> on this machine under any Linux version, or in Windows? Can you try it
>>>>>>> in another Linux machine with a different controller to see if it
>>>>>>> works there?
>>>>>> Well, this is embarrassing.
>>>>>>
>>>>>> I've always assumed the problem was with the with the motherboard, as the
>>>>>> DVD will always successfully boot a windows installer, so I assumed
>>>>>> everything with the drive was OK. On further inspection, it appears that the
>>>>>> drive falls down when being accessed from the WinPE environment, much the
>>>>>> same as in linux. I've tested this on another PC and the result looks to be
>>>>>> the same. I'm going to do some more testing, and will send another email if
>>>>>> I find out otherwise. But I think we can consider this closed.
>>>>>>
>>>>>> Sorry to be a bother.
>>>>>> Bruce
>>>>> I hooked up the DVD drive to a USB-SATA adapter to a PC and the DVD drive
>>>>> works great (under both windows and linux). I was able to copy a large
>>>>> number of files with no performance issues.
>>>>> The PC that I did the second test on turns out to have a nVidia MCP51
>>>>> chipset (It's a gateway GT4016 with a KTBC51G-LF motherboard). I should have
>>>>> checked this beforehand.
>>>>>
>>>>> So this problem looks to persist across different nVidia chipsets.
>>>> Given that it fails in Windows as well on those machines, it sounds
>>>> like there's some kind of compatibility issue between this drive and
>>>> the NV chipsets. I don't know why their SATA chipsets (at least the
>>>> pre-AHCI ones) have some many issues, but they do seem to.
>>> I've located a spare HDD and loaded Windows 7 on it. In Windows 7 (not WinPE), I am able to successfully use the BD-ROM drive on both computers (MCP61 and MCP51 chipsets). So it appears there is a difference in the drivers between the Windows 7 and WinPE driver. News to me.
>>>
>>> I believe this rules out a general hardware incompatibility.
>>>
>>> What further can I do?
> (Forgot to CC the list previously)
>
> It would likely help to confirm whether the driver that was working
> was provided by NVIDIA (which may be the case even if the driver was
> automatically installed by Windows setup) or was a default Microsoft
> one. If it's using an NVIDIA driver then it's quite likely they're
> somehow working around whatever problem we're running into.
The driver information as supplied by windows is:
filename: nvstor.sys
Provider: NVIDIA Corporation
File Version: 10.6.0.18 (NT.091202-1659)
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: System fails to connect to iHOS-104 DVD drive with nvidia MCP61 chipset.
[not found] ` <5218D74A.5020305@1045.ca>
@ 2013-09-06 23:17 ` Bruce Link
2013-09-07 1:53 ` Robert Hancock
0 siblings, 1 reply; 19+ messages in thread
From: Bruce Link @ 2013-09-06 23:17 UTC (permalink / raw)
To: Robert Hancock; +Cc: linux-ide, 1063474
On 8/24/2013 10:54 AM, Bruce Link wrote:
> On 8/23/2013 10:11 PM, Robert Hancock wrote:
>> On Fri, Aug 23, 2013 at 6:34 PM, Bruce Link <Bruce@1045.ca> wrote:
>>>> On 8/18/2013 2:05 AM, Robert Hancock wrote:
>>>>> On Sat, Aug 17, 2013 at 11:32 AM, Bruce Link <Bruce@1045.ca> wrote:
>>>>>> On 8/15/2013 9:47 PM, Bruce Link wrote:
>>>>>>> On 8/15/2013 12:36 AM, Robert Hancock wrote:
>>>>>>>> On Wed, Aug 14, 2013 at 4:17 PM, Bruce Link <Bruce@1045.ca> wrote:
>>>>>>>>>> These NVIDIA SATA controllers are a pain as they all seem to
>>>>>>>>>> have a
>>>>>>>>>> different set of bugs related to hardreset, etc. What happens
>>>>>>>>>> if you
>>>>>>>>>> boot up
>>>>>>>>>> without the drive connected and then plug in the cable after
>>>>>>>>>> the system
>>>>>>>>>> boots up?
>>>>>>>>> Roughly the same error is returned. See below for the dmesg
>>>>>>>>> output.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0#
>>>>>>>>>
>>>>>>>>> echo "- - -" > /sys/class/scsi_host/host4/scan
>>>>>>>>>
>>>>>>>>> root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0#
>>>>>>>>>
>>>>>>>>> dmesg|grep ata5
>>>>>>>>> [ 1.030224] ata5: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0
>>>>>>>>> bmdma 0xc400
>>>>>>>>> irq
>>>>>>>>> 20
>>>>>>>>> [ 1.354216] ata5: SATA link down (SStatus 0 SControl 300)
>>>>>>>>> [ 944.773288] ata5: exception Emask 0x10 SAct 0x0 SErr
>>>>>>>>> 0x50000 action
>>>>>>>>> 0xf
>>>>>>>>> [ 944.773304] ata5: SError: { PHYRdyChg CommWake }
>>>>>>>>> [ 944.773322] ata5: hard resetting link
>>>>>>>>> [ 945.652070] ata5: SATA link up 1.5 Gbps (SStatus 113
>>>>>>>>> SControl 300)
>>>>>>>>> [ 945.660176] ata5.00: ATAPI: ATAPI iHOS104, WL0F, max
>>>>>>>>> UDMA/100
>>>>>>>>> [ 945.676165] ata5.00: configured for UDMA/100
>>>>>>>>> [ 950.676049] ata5.00: qc timeout (cmd 0xa0)
>>>>>>>>> [ 950.676056] ata5.00: TEST_UNIT_READY failed (err_mask=0x5)
>>>>>>>>> [ 950.676064] ata5: hard resetting link
>>>>>>>>> [ 950.676066] ata5: nv: skipping hardreset on occupied port
>>>>>>>>> [ 951.144073] ata5: SATA link up 1.5 Gbps (SStatus 113
>>>>>>>>> SControl 300)
>>>>>>>>> [ 951.168168] ata5.00: configured for UDMA/100
>>>>>>>>> [ 956.168049] ata5.00: qc timeout (cmd 0xa0)
>>>>>>>>> [ 956.168057] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
>>>>>>>>> [ 956.168061] ata5: limiting SATA link speed to 1.5 Gbps
>>>>>>>>> [ 956.168064] ata5.00: limiting speed to UDMA/100:PIO3
>>>>>>>>> [ 956.168070] ata5: hard resetting link
>>>>>>>>> [ 956.168072] ata5: nv: skipping hardreset on occupied port
>>>>>>>>> [ 956.636056] ata5: SATA link up 1.5 Gbps (SStatus 113
>>>>>>>>> SControl 300)
>>>>>>>>> [ 956.660169] ata5.00: configured for UDMA/100
>>>>>>>>> [ 961.660036] ata5.00: qc timeout (cmd 0xa0)
>>>>>>>>> [ 961.660044] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
>>>>>>>>> [ 961.660046] ata5.00: disabled
>>>>>>>>> [ 961.660061] ata5: hard resetting link
>>>>>>>>> [ 962.544045] ata5: SATA link up 1.5 Gbps (SStatus 113
>>>>>>>>> SControl 310)
>>>>>>>>> [ 962.544061] ata5: EH complete
>>>>>>>>>
>>>>>>>>> root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0#
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Hmm, it did a hard reset on the hotplug with seemingly the same
>>>>>>>> effect. Can we narrow down the problem any more: does this
>>>>>>>> drive work
>>>>>>>> on this machine under any Linux version, or in Windows? Can you
>>>>>>>> try it
>>>>>>>> in another Linux machine with a different controller to see if it
>>>>>>>> works there?
>>>>>>> Well, this is embarrassing.
>>>>>>>
>>>>>>> I've always assumed the problem was with the with the
>>>>>>> motherboard, as the
>>>>>>> DVD will always successfully boot a windows installer, so I assumed
>>>>>>> everything with the drive was OK. On further inspection, it
>>>>>>> appears that the
>>>>>>> drive falls down when being accessed from the WinPE environment,
>>>>>>> much the
>>>>>>> same as in linux. I've tested this on another PC and the result
>>>>>>> looks to be
>>>>>>> the same. I'm going to do some more testing, and will send
>>>>>>> another email if
>>>>>>> I find out otherwise. But I think we can consider this closed.
>>>>>>>
>>>>>>> Sorry to be a bother.
>>>>>>> Bruce
>>>>>> I hooked up the DVD drive to a USB-SATA adapter to a PC and the
>>>>>> DVD drive
>>>>>> works great (under both windows and linux). I was able to copy a
>>>>>> large
>>>>>> number of files with no performance issues.
>>>>>> The PC that I did the second test on turns out to have a nVidia
>>>>>> MCP51
>>>>>> chipset (It's a gateway GT4016 with a KTBC51G-LF motherboard). I
>>>>>> should have
>>>>>> checked this beforehand.
>>>>>>
>>>>>> So this problem looks to persist across different nVidia chipsets.
>>>>> Given that it fails in Windows as well on those machines, it sounds
>>>>> like there's some kind of compatibility issue between this drive and
>>>>> the NV chipsets. I don't know why their SATA chipsets (at least the
>>>>> pre-AHCI ones) have some many issues, but they do seem to.
>>>> I've located a spare HDD and loaded Windows 7 on it. In Windows 7
>>>> (not WinPE), I am able to successfully use the BD-ROM drive on both
>>>> computers (MCP61 and MCP51 chipsets). So it appears there is a
>>>> difference in the drivers between the Windows 7 and WinPE driver.
>>>> News to me.
>>>>
>>>> I believe this rules out a general hardware incompatibility.
>>>>
>>>> What further can I do?
>> (Forgot to CC the list previously)
>>
>> It would likely help to confirm whether the driver that was working
>> was provided by NVIDIA (which may be the case even if the driver was
>> automatically installed by Windows setup) or was a default Microsoft
>> one. If it's using an NVIDIA driver then it's quite likely they're
>> somehow working around whatever problem we're running into.
> The driver information as supplied by windows is:
> filename: nvstor.sys
> Provider: NVIDIA Corporation
> File Version: 10.6.0.18 (NT.091202-1659)
Robert,
Is there any more information I can supply that would be helpful?
Thanks
Bruce
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: System fails to connect to iHOS-104 DVD drive with nvidia MCP61 chipset.
2013-09-06 23:17 ` Bruce Link
@ 2013-09-07 1:53 ` Robert Hancock
2013-09-08 12:25 ` Tejun Heo
0 siblings, 1 reply; 19+ messages in thread
From: Robert Hancock @ 2013-09-07 1:53 UTC (permalink / raw)
To: Bruce Link; +Cc: linux-ide, 1063474, Tejun Heo
On Fri, Sep 6, 2013 at 5:17 PM, Bruce Link <Bruce@1045.ca> wrote:
> On 8/24/2013 10:54 AM, Bruce Link wrote:
>>
>> On 8/23/2013 10:11 PM, Robert Hancock wrote:
>>>
>>> On Fri, Aug 23, 2013 at 6:34 PM, Bruce Link <Bruce@1045.ca> wrote:
>>>>>
>>>>> On 8/18/2013 2:05 AM, Robert Hancock wrote:
>>>>>>
>>>>>> On Sat, Aug 17, 2013 at 11:32 AM, Bruce Link <Bruce@1045.ca> wrote:
>>>>>>>
>>>>>>> On 8/15/2013 9:47 PM, Bruce Link wrote:
>>>>>>>>
>>>>>>>> On 8/15/2013 12:36 AM, Robert Hancock wrote:
>>>>>>>>>
>>>>>>>>> On Wed, Aug 14, 2013 at 4:17 PM, Bruce Link <Bruce@1045.ca> wrote:
>>>>>>>>>>>
>>>>>>>>>>> These NVIDIA SATA controllers are a pain as they all seem to have
>>>>>>>>>>> a
>>>>>>>>>>> different set of bugs related to hardreset, etc. What happens if
>>>>>>>>>>> you
>>>>>>>>>>> boot up
>>>>>>>>>>> without the drive connected and then plug in the cable after the
>>>>>>>>>>> system
>>>>>>>>>>> boots up?
>>>>>>>>>>
>>>>>>>>>> Roughly the same error is returned. See below for the dmesg
>>>>>>>>>> output.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0#
>>>>>>>>>> echo "- - -" > /sys/class/scsi_host/host4/scan
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0#
>>>>>>>>>> dmesg|grep ata5
>>>>>>>>>> [ 1.030224] ata5: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0 bmdma
>>>>>>>>>> 0xc400
>>>>>>>>>> irq
>>>>>>>>>> 20
>>>>>>>>>> [ 1.354216] ata5: SATA link down (SStatus 0 SControl 300)
>>>>>>>>>> [ 944.773288] ata5: exception Emask 0x10 SAct 0x0 SErr 0x50000
>>>>>>>>>> action
>>>>>>>>>> 0xf
>>>>>>>>>> [ 944.773304] ata5: SError: { PHYRdyChg CommWake }
>>>>>>>>>> [ 944.773322] ata5: hard resetting link
>>>>>>>>>> [ 945.652070] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl
>>>>>>>>>> 300)
>>>>>>>>>> [ 945.660176] ata5.00: ATAPI: ATAPI iHOS104, WL0F, max UDMA/100
>>>>>>>>>> [ 945.676165] ata5.00: configured for UDMA/100
>>>>>>>>>> [ 950.676049] ata5.00: qc timeout (cmd 0xa0)
>>>>>>>>>> [ 950.676056] ata5.00: TEST_UNIT_READY failed (err_mask=0x5)
>>>>>>>>>> [ 950.676064] ata5: hard resetting link
>>>>>>>>>> [ 950.676066] ata5: nv: skipping hardreset on occupied port
>>>>>>>>>> [ 951.144073] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl
>>>>>>>>>> 300)
>>>>>>>>>> [ 951.168168] ata5.00: configured for UDMA/100
>>>>>>>>>> [ 956.168049] ata5.00: qc timeout (cmd 0xa0)
>>>>>>>>>> [ 956.168057] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
>>>>>>>>>> [ 956.168061] ata5: limiting SATA link speed to 1.5 Gbps
>>>>>>>>>> [ 956.168064] ata5.00: limiting speed to UDMA/100:PIO3
>>>>>>>>>> [ 956.168070] ata5: hard resetting link
>>>>>>>>>> [ 956.168072] ata5: nv: skipping hardreset on occupied port
>>>>>>>>>> [ 956.636056] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl
>>>>>>>>>> 300)
>>>>>>>>>> [ 956.660169] ata5.00: configured for UDMA/100
>>>>>>>>>> [ 961.660036] ata5.00: qc timeout (cmd 0xa0)
>>>>>>>>>> [ 961.660044] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
>>>>>>>>>> [ 961.660046] ata5.00: disabled
>>>>>>>>>> [ 961.660061] ata5: hard resetting link
>>>>>>>>>> [ 962.544045] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl
>>>>>>>>>> 310)
>>>>>>>>>> [ 962.544061] ata5: EH complete
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0#
>>>>>>>>>>
>>>>>>>>> Hmm, it did a hard reset on the hotplug with seemingly the same
>>>>>>>>> effect. Can we narrow down the problem any more: does this drive
>>>>>>>>> work
>>>>>>>>> on this machine under any Linux version, or in Windows? Can you try
>>>>>>>>> it
>>>>>>>>> in another Linux machine with a different controller to see if it
>>>>>>>>> works there?
>>>>>>>>
>>>>>>>> Well, this is embarrassing.
>>>>>>>>
>>>>>>>> I've always assumed the problem was with the with the motherboard,
>>>>>>>> as the
>>>>>>>> DVD will always successfully boot a windows installer, so I assumed
>>>>>>>> everything with the drive was OK. On further inspection, it appears
>>>>>>>> that the
>>>>>>>> drive falls down when being accessed from the WinPE environment,
>>>>>>>> much the
>>>>>>>> same as in linux. I've tested this on another PC and the result
>>>>>>>> looks to be
>>>>>>>> the same. I'm going to do some more testing, and will send another
>>>>>>>> email if
>>>>>>>> I find out otherwise. But I think we can consider this closed.
>>>>>>>>
>>>>>>>> Sorry to be a bother.
>>>>>>>> Bruce
>>>>>>>
>>>>>>> I hooked up the DVD drive to a USB-SATA adapter to a PC and the DVD
>>>>>>> drive
>>>>>>> works great (under both windows and linux). I was able to copy a
>>>>>>> large
>>>>>>> number of files with no performance issues.
>>>>>>> The PC that I did the second test on turns out to have a nVidia MCP51
>>>>>>> chipset (It's a gateway GT4016 with a KTBC51G-LF motherboard). I
>>>>>>> should have
>>>>>>> checked this beforehand.
>>>>>>>
>>>>>>> So this problem looks to persist across different nVidia chipsets.
>>>>>>
>>>>>> Given that it fails in Windows as well on those machines, it sounds
>>>>>> like there's some kind of compatibility issue between this drive and
>>>>>> the NV chipsets. I don't know why their SATA chipsets (at least the
>>>>>> pre-AHCI ones) have some many issues, but they do seem to.
>>>>>
>>>>> I've located a spare HDD and loaded Windows 7 on it. In Windows 7 (not
>>>>> WinPE), I am able to successfully use the BD-ROM drive on both computers
>>>>> (MCP61 and MCP51 chipsets). So it appears there is a difference in the
>>>>> drivers between the Windows 7 and WinPE driver. News to me.
>>>>>
>>>>> I believe this rules out a general hardware incompatibility.
>>>>>
>>>>> What further can I do?
>>>
>>> (Forgot to CC the list previously)
>>>
>>> It would likely help to confirm whether the driver that was working
>>> was provided by NVIDIA (which may be the case even if the driver was
>>> automatically installed by Windows setup) or was a default Microsoft
>>> one. If it's using an NVIDIA driver then it's quite likely they're
>>> somehow working around whatever problem we're running into.
>>
>> The driver information as supplied by windows is:
>> filename: nvstor.sys
>> Provider: NVIDIA Corporation
>> File Version: 10.6.0.18 (NT.091202-1659)
>
> Robert,
>
> Is there any more information I can supply that would be helpful?
I'm not quite sure what the next step would be. It's quite possible
that the NVIDIA driver in Windows is doing some magic to work around
the problem that we don't know about, but it's hard to say what that
might be. The fact that the default drivers used in the WinPE boot
don't seem to work would tend to point toward some kind of hardware
incompatibility issue.
Tejun, think you poked with some of this stuff before - any ideas?
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: System fails to connect to iHOS-104 DVD drive with nvidia MCP61 chipset.
2013-09-07 1:53 ` Robert Hancock
@ 2013-09-08 12:25 ` Tejun Heo
0 siblings, 0 replies; 19+ messages in thread
From: Tejun Heo @ 2013-09-08 12:25 UTC (permalink / raw)
To: Robert Hancock; +Cc: Bruce Link, linux-ide, 1063474
Hello,
On Fri, Sep 06, 2013 at 07:53:49PM -0600, Robert Hancock wrote:
> > Is there any more information I can supply that would be helpful?
>
> I'm not quite sure what the next step would be. It's quite possible
> that the NVIDIA driver in Windows is doing some magic to work around
> the problem that we don't know about, but it's hard to say what that
> might be. The fact that the default drivers used in the WinPE boot
> don't seem to work would tend to point toward some kind of hardware
> incompatibility issue.
>
> Tejun, think you poked with some of this stuff before - any ideas?
It has been years since I looked at MCP quirks, of which there are too
many. It's likely another quirk on the controller side that nvidia
worked around somehow without telling anyone. Given the history and
that nvidia is out of chipset market, I think it's highly unlikely to
learn what the issue and workaround are without reverse engineering
it. So, um, no idea.
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: System fails to connect to iHOS-104 DVD drive with nvidia MCP61 chipset.
2013-08-24 3:11 ` Robert Hancock
2013-08-24 15:54 ` Bruce Link
[not found] ` <5218D74A.5020305@1045.ca>
@ 2013-09-18 0:35 ` Bruce Link
2013-09-18 1:40 ` Robert Hancock
2 siblings, 1 reply; 19+ messages in thread
From: Bruce Link @ 2013-09-18 0:35 UTC (permalink / raw)
To: Robert Hancock; +Cc: linux-ide, 1063474
> Hello,
>
> On Fri, Sep 06, 2013 at 07:53:49PM -0600, Robert Hancock wrote:
> > > Is there any more information I can supply that would be helpful?
> >
> > I'm not quite sure what the next step would be. It's quite possible
> > that the NVIDIA driver in Windows is doing some magic to work around
> > the problem that we don't know about, but it's hard to say what that
> > might be. The fact that the default drivers used in the WinPE boot
> > don't seem to work would tend to point toward some kind of hardware
> > incompatibility issue.
> >
> > Tejun, think you poked with some of this stuff before - any ideas?
>
> It has been years since I looked at MCP quirks, of which there are too
> many. It's likely another quirk on the controller side that nvidia
> worked around somehow without telling anyone. Given the history and
> that nvidia is out of chipset market, I think it's highly unlikely to
> learn what the issue and workaround are without reverse engineering
> it. So, um, no idea.
>
> Thanks.
>
> --
> tejun
> --
Robert,
I've inquired about this problem with Allen Martin at Nvidia, he had the
following reply:
/--------SNIP---------------/
Hi Bruce, I did work on the Windows SATA driver for those chipsets, so
I’m familiar with it. I’m not aware of any of any timing workarounds for
any devices in the driver, but it’s certainly true that there are
devices that have timing sensitivity, especially around the IDENTIFY
command and it may inadvertently work with one driver and not another.
From the bug reports it looks like it’s always timing out on a
TEST_UNIT_READY command? I assume this is probably the first command
sent down after IDENTIFY to check for presense of a CD in the drive? If
so it’s likely the drive is locked up and any command at that point will
fail. If you want to test out the theory about it being a timing issue,
I would stick some udelay()s in the identify code path, both before and
after starting the transfer to see if it makes any difference. Also do
you know if the driver does a PHY reset when it resets the link? If not,
you can try doing that by writing a 0 to SControl and then restoring it
with the original value.
Hope this helps,
-Allen
/--------SNIP---------------/
Does this provide any actionable information? I've tried searching for
the proper location to impliment these delays in the sata_nv.c and
libata-eh.c files but admittedly, am in over my head.
Thanks
Bruce
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: System fails to connect to iHOS-104 DVD drive with nvidia MCP61 chipset.
2013-09-18 0:35 ` Bruce Link
@ 2013-09-18 1:40 ` Robert Hancock
2013-09-18 22:27 ` Bruce Link
0 siblings, 1 reply; 19+ messages in thread
From: Robert Hancock @ 2013-09-18 1:40 UTC (permalink / raw)
To: Bruce Link; +Cc: linux-ide, 1063474
On Tue, Sep 17, 2013 at 6:35 PM, Bruce Link <Bruce@1045.ca> wrote:
>> Hello,
>>
>> On Fri, Sep 06, 2013 at 07:53:49PM -0600, Robert Hancock wrote:
>> > > Is there any more information I can supply that would be helpful?
>> >
>> > I'm not quite sure what the next step would be. It's quite possible
>> > that the NVIDIA driver in Windows is doing some magic to work around
>> > the problem that we don't know about, but it's hard to say what that
>> > might be. The fact that the default drivers used in the WinPE boot
>> > don't seem to work would tend to point toward some kind of hardware
>> > incompatibility issue.
>> >
>> > Tejun, think you poked with some of this stuff before - any ideas?
>>
>> It has been years since I looked at MCP quirks, of which there are too
>> many. It's likely another quirk on the controller side that nvidia
>> worked around somehow without telling anyone. Given the history and
>> that nvidia is out of chipset market, I think it's highly unlikely to
>> learn what the issue and workaround are without reverse engineering
>> it. So, um, no idea.
>>
>> Thanks.
>>
>> --
>> tejun
>> --
>
>
> Robert,
>
> I've inquired about this problem with Allen Martin at Nvidia, he had the
> following reply:
>
> /--------SNIP---------------/
> Hi Bruce, I did work on the Windows SATA driver for those chipsets, so I’m
> familiar with it. I’m not aware of any of any timing workarounds for any
> devices in the driver, but it’s certainly true that there are devices that
> have timing sensitivity, especially around the IDENTIFY command and it may
> inadvertently work with one driver and not another.
>
> From the bug reports it looks like it’s always timing out on a
> TEST_UNIT_READY command? I assume this is probably the first command sent
> down after IDENTIFY to check for presense of a CD in the drive? If so it’s
> likely the drive is locked up and any command at that point will fail. If
> you want to test out the theory about it being a timing issue, I would stick
> some udelay()s in the identify code path, both before and after starting the
> transfer to see if it makes any difference. Also do you know if the driver
> does a PHY reset when it resets the link? If not, you can try doing that by
> writing a 0 to SControl and then restoring it with the original value.
>
> Hope this helps,
>
> -Allen
> /--------SNIP---------------/
>
> Does this provide any actionable information? I've tried searching for the
> proper location to impliment these delays in the sata_nv.c and libata-eh.c
> files but admittedly, am in over my head.
Don't think there's any earth-shaking revelations but it might be a
few things to try. First, though, apparently there is a firmware
update for this drive of at least one revision up (WL0G) available
from Lite-ON that you could try updating to. (You'll likely need to
use Windows for that.) Given that it seems broken in at least two
different environments on this controller, it's possible they fixed
something related in the drive.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: System fails to connect to iHOS-104 DVD drive with nvidia MCP61 chipset.
2013-09-18 1:40 ` Robert Hancock
@ 2013-09-18 22:27 ` Bruce Link
2013-10-19 0:04 ` Bruce Link
[not found] ` <5261CC95.1050903@1045.ca>
0 siblings, 2 replies; 19+ messages in thread
From: Bruce Link @ 2013-09-18 22:27 UTC (permalink / raw)
To: Robert Hancock; +Cc: linux-ide, 1063474
On 9/17/2013 8:40 PM, Robert Hancock wrote:
> On Tue, Sep 17, 2013 at 6:35 PM, Bruce Link <Bruce@1045.ca> wrote:
>>> Hello,
>>>
>>> On Fri, Sep 06, 2013 at 07:53:49PM -0600, Robert Hancock wrote:
>>>>> Is there any more information I can supply that would be helpful?
>>>> I'm not quite sure what the next step would be. It's quite possible
>>>> that the NVIDIA driver in Windows is doing some magic to work around
>>>> the problem that we don't know about, but it's hard to say what that
>>>> might be. The fact that the default drivers used in the WinPE boot
>>>> don't seem to work would tend to point toward some kind of hardware
>>>> incompatibility issue.
>>>>
>>>> Tejun, think you poked with some of this stuff before - any ideas?
>>> It has been years since I looked at MCP quirks, of which there are too
>>> many. It's likely another quirk on the controller side that nvidia
>>> worked around somehow without telling anyone. Given the history and
>>> that nvidia is out of chipset market, I think it's highly unlikely to
>>> learn what the issue and workaround are without reverse engineering
>>> it. So, um, no idea.
>>>
>>> Thanks.
>>>
>>> --
>>> tejun
>>> --
>>
>> Robert,
>>
>> I've inquired about this problem with Allen Martin at Nvidia, he had the
>> following reply:
>>
>> /--------SNIP---------------/
>> Hi Bruce, I did work on the Windows SATA driver for those chipsets, so I’m
>> familiar with it. I’m not aware of any of any timing workarounds for any
>> devices in the driver, but it’s certainly true that there are devices that
>> have timing sensitivity, especially around the IDENTIFY command and it may
>> inadvertently work with one driver and not another.
>>
>> From the bug reports it looks like it’s always timing out on a
>> TEST_UNIT_READY command? I assume this is probably the first command sent
>> down after IDENTIFY to check for presense of a CD in the drive? If so it’s
>> likely the drive is locked up and any command at that point will fail. If
>> you want to test out the theory about it being a timing issue, I would stick
>> some udelay()s in the identify code path, both before and after starting the
>> transfer to see if it makes any difference. Also do you know if the driver
>> does a PHY reset when it resets the link? If not, you can try doing that by
>> writing a 0 to SControl and then restoring it with the original value.
>>
>> Hope this helps,
>>
>> -Allen
>> /--------SNIP---------------/
>>
>> Does this provide any actionable information? I've tried searching for the
>> proper location to impliment these delays in the sata_nv.c and libata-eh.c
>> files but admittedly, am in over my head.
> Don't think there's any earth-shaking revelations but it might be a
> few things to try. First, though, apparently there is a firmware
> update for this drive of at least one revision up (WL0G) available
> from Lite-ON that you could try updating to. (You'll likely need to
> use Windows for that.) Given that it seems broken in at least two
> different environments on this controller, it's possible they fixed
> something related in the drive.
Robert,
I can report that the new firmware for the drive does not solve the problem.
watchtv@teevee:~$ dmesg |grep ata5
[ 1.090360] ata5: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0 bmdma 0xc400
irq 20
[ 1.556044] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 1.564199] ata5.00: ATAPI: ATAPI iHOS104, WL0G, max UDMA/100
[ 1.580140] ata5.00: configured for UDMA/100
[ 6.580035] ata5.00: qc timeout (cmd 0xa0)
[ 6.580043] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[ 7.048042] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 7.072124] ata5.00: configured for UDMA/100
[ 12.072029] ata5.00: qc timeout (cmd 0xa0)
[ 12.072037] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[ 12.072041] ata5: limiting SATA link speed to 1.5 Gbps
[ 12.072043] ata5.00: limiting speed to UDMA/100:PIO3
[ 12.540058] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 12.564141] ata5.00: configured for UDMA/100
[ 17.564038] ata5.00: qc timeout (cmd 0xa0)
[ 17.564045] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[ 17.564048] ata5.00: disabled
[ 17.564063] ata5: hard resetting link
[ 17.564065] ata5: nv: skipping hardreset on occupied port
[ 18.032068] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 18.032082] ata5: EH complete
watchtv@teevee:~$
My apologies for not noticing the firmware update earlier. I do recall
checking at one time, though it may have been prior to Sept. 2011.
Bruce
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: System fails to connect to iHOS-104 DVD drive with nvidia MCP61 chipset.
2013-09-18 22:27 ` Bruce Link
@ 2013-10-19 0:04 ` Bruce Link
[not found] ` <5261CC95.1050903@1045.ca>
1 sibling, 0 replies; 19+ messages in thread
From: Bruce Link @ 2013-10-19 0:04 UTC (permalink / raw)
To: Robert Hancock; +Cc: linux-ide, 1063474
On 9/18/2013 5:27 PM, Bruce Link wrote:
> On 9/17/2013 8:40 PM, Robert Hancock wrote:
>> On Tue, Sep 17, 2013 at 6:35 PM, Bruce Link <Bruce@1045.ca> wrote:
>>>> Hello,
>>>>
>>>> On Fri, Sep 06, 2013 at 07:53:49PM -0600, Robert Hancock wrote:
>>>>>> Is there any more information I can supply that would be helpful?
>>>>> I'm not quite sure what the next step would be. It's quite possible
>>>>> that the NVIDIA driver in Windows is doing some magic to work around
>>>>> the problem that we don't know about, but it's hard to say what that
>>>>> might be. The fact that the default drivers used in the WinPE boot
>>>>> don't seem to work would tend to point toward some kind of hardware
>>>>> incompatibility issue.
>>>>>
>>>>> Tejun, think you poked with some of this stuff before - any ideas?
>>>> It has been years since I looked at MCP quirks, of which there are too
>>>> many. It's likely another quirk on the controller side that nvidia
>>>> worked around somehow without telling anyone. Given the history and
>>>> that nvidia is out of chipset market, I think it's highly unlikely to
>>>> learn what the issue and workaround are without reverse engineering
>>>> it. So, um, no idea.
>>>>
>>>> Thanks.
>>>>
>>>> --
>>>> tejun
>>>> --
>>>
>>> Robert,
>>>
>>> I've inquired about this problem with Allen Martin at Nvidia, he had
>>> the
>>> following reply:
>>>
>>> /--------SNIP---------------/
>>> Hi Bruce, I did work on the Windows SATA driver for those chipsets,
>>> so I’m
>>> familiar with it. I’m not aware of any of any timing workarounds for
>>> any
>>> devices in the driver, but it’s certainly true that there are
>>> devices that
>>> have timing sensitivity, especially around the IDENTIFY command and
>>> it may
>>> inadvertently work with one driver and not another.
>>>
>>> From the bug reports it looks like it’s always timing out on a
>>> TEST_UNIT_READY command? I assume this is probably the first command
>>> sent
>>> down after IDENTIFY to check for presense of a CD in the drive? If
>>> so it’s
>>> likely the drive is locked up and any command at that point will
>>> fail. If
>>> you want to test out the theory about it being a timing issue, I
>>> would stick
>>> some udelay()s in the identify code path, both before and after
>>> starting the
>>> transfer to see if it makes any difference. Also do you know if the
>>> driver
>>> does a PHY reset when it resets the link? If not, you can try doing
>>> that by
>>> writing a 0 to SControl and then restoring it with the original value.
>>>
>>> Hope this helps,
>>>
>>> -Allen
>>> /--------SNIP---------------/
>>>
>>> Does this provide any actionable information? I've tried searching
>>> for the
>>> proper location to impliment these delays in the sata_nv.c and
>>> libata-eh.c
>>> files but admittedly, am in over my head.
>> Don't think there's any earth-shaking revelations but it might be a
>> few things to try. First, though, apparently there is a firmware
>> update for this drive of at least one revision up (WL0G) available
>> from Lite-ON that you could try updating to. (You'll likely need to
>> use Windows for that.) Given that it seems broken in at least two
>> different environments on this controller, it's possible they fixed
>> something related in the drive.
> Robert,
>
> I can report that the new firmware for the drive does not solve the
> problem.
>
> watchtv@teevee:~$ dmesg |grep ata5
> [ 1.090360] ata5: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0 bmdma
> 0xc400 irq 20
> [ 1.556044] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> [ 1.564199] ata5.00: ATAPI: ATAPI iHOS104, WL0G, max UDMA/100
> [ 1.580140] ata5.00: configured for UDMA/100
> [ 6.580035] ata5.00: qc timeout (cmd 0xa0)
> [ 6.580043] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
> [ 7.048042] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> [ 7.072124] ata5.00: configured for UDMA/100
> [ 12.072029] ata5.00: qc timeout (cmd 0xa0)
> [ 12.072037] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
> [ 12.072041] ata5: limiting SATA link speed to 1.5 Gbps
> [ 12.072043] ata5.00: limiting speed to UDMA/100:PIO3
> [ 12.540058] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> [ 12.564141] ata5.00: configured for UDMA/100
> [ 17.564038] ata5.00: qc timeout (cmd 0xa0)
> [ 17.564045] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
> [ 17.564048] ata5.00: disabled
> [ 17.564063] ata5: hard resetting link
> [ 17.564065] ata5: nv: skipping hardreset on occupied port
> [ 18.032068] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> [ 18.032082] ata5: EH complete
> watchtv@teevee:~$
>
> My apologies for not noticing the firmware update earlier. I do recall
> checking at one time, though it may have been prior to Sept. 2011.
>
> Bruce
Robert,
Writing to you to bump this thread. Is there anything more I can do to
troubleshoot this issue?
Thanks
Bruce
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: System fails to connect to iHOS-104 DVD drive with nvidia MCP61 chipset.
[not found] ` <5261CC95.1050903@1045.ca>
@ 2013-10-22 1:17 ` Robert Hancock
2013-11-09 21:02 ` Bruce Link
0 siblings, 1 reply; 19+ messages in thread
From: Robert Hancock @ 2013-10-22 1:17 UTC (permalink / raw)
To: Bruce Link; +Cc: linux-ide, 1063474
On Fri, Oct 18, 2013 at 6:04 PM, Bruce Link <Bruce@1045.ca> wrote:
> On 9/18/2013 5:27 PM, Bruce Link wrote:
>>
>> On 9/17/2013 8:40 PM, Robert Hancock wrote:
>>>
>>> On Tue, Sep 17, 2013 at 6:35 PM, Bruce Link <Bruce@1045.ca> wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> On Fri, Sep 06, 2013 at 07:53:49PM -0600, Robert Hancock wrote:
>>>>>>>
>>>>>>> Is there any more information I can supply that would be helpful?
>>>>>>
>>>>>> I'm not quite sure what the next step would be. It's quite possible
>>>>>> that the NVIDIA driver in Windows is doing some magic to work around
>>>>>> the problem that we don't know about, but it's hard to say what that
>>>>>> might be. The fact that the default drivers used in the WinPE boot
>>>>>> don't seem to work would tend to point toward some kind of hardware
>>>>>> incompatibility issue.
>>>>>>
>>>>>> Tejun, think you poked with some of this stuff before - any ideas?
>>>>>
>>>>> It has been years since I looked at MCP quirks, of which there are too
>>>>> many. It's likely another quirk on the controller side that nvidia
>>>>> worked around somehow without telling anyone. Given the history and
>>>>> that nvidia is out of chipset market, I think it's highly unlikely to
>>>>> learn what the issue and workaround are without reverse engineering
>>>>> it. So, um, no idea.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> --
>>>>> tejun
>>>>> --
>>>>
>>>>
>>>> Robert,
>>>>
>>>> I've inquired about this problem with Allen Martin at Nvidia, he had the
>>>> following reply:
>>>>
>>>> /--------SNIP---------------/
>>>> Hi Bruce, I did work on the Windows SATA driver for those chipsets, so
>>>> I’m
>>>> familiar with it. I’m not aware of any of any timing workarounds for any
>>>> devices in the driver, but it’s certainly true that there are devices
>>>> that
>>>> have timing sensitivity, especially around the IDENTIFY command and it
>>>> may
>>>> inadvertently work with one driver and not another.
>>>>
>>>> From the bug reports it looks like it’s always timing out on a
>>>> TEST_UNIT_READY command? I assume this is probably the first command
>>>> sent
>>>> down after IDENTIFY to check for presense of a CD in the drive? If so
>>>> it’s
>>>> likely the drive is locked up and any command at that point will fail.
>>>> If
>>>> you want to test out the theory about it being a timing issue, I would
>>>> stick
>>>> some udelay()s in the identify code path, both before and after starting
>>>> the
>>>> transfer to see if it makes any difference. Also do you know if the
>>>> driver
>>>> does a PHY reset when it resets the link? If not, you can try doing that
>>>> by
>>>> writing a 0 to SControl and then restoring it with the original value.
>>>>
>>>> Hope this helps,
>>>>
>>>> -Allen
>>>> /--------SNIP---------------/
>>>>
>>>> Does this provide any actionable information? I've tried searching for
>>>> the
>>>> proper location to impliment these delays in the sata_nv.c and
>>>> libata-eh.c
>>>> files but admittedly, am in over my head.
>>>
>>> Don't think there's any earth-shaking revelations but it might be a
>>> few things to try. First, though, apparently there is a firmware
>>> update for this drive of at least one revision up (WL0G) available
>>> from Lite-ON that you could try updating to. (You'll likely need to
>>> use Windows for that.) Given that it seems broken in at least two
>>> different environments on this controller, it's possible they fixed
>>> something related in the drive.
>>
>> Robert,
>>
>> I can report that the new firmware for the drive does not solve the
>> problem.
>>
>> watchtv@teevee:~$ dmesg |grep ata5
>> [ 1.090360] ata5: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0 bmdma 0xc400
>> irq 20
>> [ 1.556044] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>> [ 1.564199] ata5.00: ATAPI: ATAPI iHOS104, WL0G, max UDMA/100
>> [ 1.580140] ata5.00: configured for UDMA/100
>> [ 6.580035] ata5.00: qc timeout (cmd 0xa0)
>> [ 6.580043] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
>> [ 7.048042] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>> [ 7.072124] ata5.00: configured for UDMA/100
>> [ 12.072029] ata5.00: qc timeout (cmd 0xa0)
>> [ 12.072037] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
>> [ 12.072041] ata5: limiting SATA link speed to 1.5 Gbps
>> [ 12.072043] ata5.00: limiting speed to UDMA/100:PIO3
>> [ 12.540058] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>> [ 12.564141] ata5.00: configured for UDMA/100
>> [ 17.564038] ata5.00: qc timeout (cmd 0xa0)
>> [ 17.564045] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
>> [ 17.564048] ata5.00: disabled
>> [ 17.564063] ata5: hard resetting link
>> [ 17.564065] ata5: nv: skipping hardreset on occupied port
>> [ 18.032068] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>> [ 18.032082] ata5: EH complete
>> watchtv@teevee:~$
>>
>> My apologies for not noticing the firmware update earlier. I do recall
>> checking at one time, though it may have been prior to Sept. 2011.
>>
>> Bruce
>
> Robert,
>
> Writing to you to bump this thread. Is there anything more I can do to
> troubleshoot this issue?
A couple of things you could try:
-Does the behavior change if you boot with vs. without a disc in the drive?
-You could try building a kernel with something like adding
mdelay(1000) at the start of the atapi_eh_clear_ua function in
drivers/ata/libata-eh.c.You should see an extra 1 second delay (so at
the very least it should take 6 seconds to timeout rather than 5). If
that changes anything then perhaps some kind of timing quirk would
help the problem.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: System fails to connect to iHOS-104 DVD drive with nvidia MCP61 chipset.
2013-10-22 1:17 ` Robert Hancock
@ 2013-11-09 21:02 ` Bruce Link
0 siblings, 0 replies; 19+ messages in thread
From: Bruce Link @ 2013-11-09 21:02 UTC (permalink / raw)
To: Robert Hancock; +Cc: linux-ide, 1063474
On 10/21/2013 8:17 PM, Robert Hancock wrote:
> On Fri, Oct 18, 2013 at 6:04 PM, Bruce Link <Bruce@1045.ca> wrote:
>> On 9/18/2013 5:27 PM, Bruce Link wrote:
>>> On 9/17/2013 8:40 PM, Robert Hancock wrote:
>>>> On Tue, Sep 17, 2013 at 6:35 PM, Bruce Link <Bruce@1045.ca> wrote:
>>>>>> Hello,
>>>>>>
>>>>>> On Fri, Sep 06, 2013 at 07:53:49PM -0600, Robert Hancock wrote:
>>>>>>>> Is there any more information I can supply that would be helpful?
>>>>>>> I'm not quite sure what the next step would be. It's quite possible
>>>>>>> that the NVIDIA driver in Windows is doing some magic to work around
>>>>>>> the problem that we don't know about, but it's hard to say what that
>>>>>>> might be. The fact that the default drivers used in the WinPE boot
>>>>>>> don't seem to work would tend to point toward some kind of hardware
>>>>>>> incompatibility issue.
>>>>>>>
>>>>>>> Tejun, think you poked with some of this stuff before - any ideas?
>>>>>> It has been years since I looked at MCP quirks, of which there are too
>>>>>> many. It's likely another quirk on the controller side that nvidia
>>>>>> worked around somehow without telling anyone. Given the history and
>>>>>> that nvidia is out of chipset market, I think it's highly unlikely to
>>>>>> learn what the issue and workaround are without reverse engineering
>>>>>> it. So, um, no idea.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> --
>>>>>> tejun
>>>>>> --
>>>>>
>>>>> Robert,
>>>>>
>>>>> I've inquired about this problem with Allen Martin at Nvidia, he had the
>>>>> following reply:
>>>>>
>>>>> /--------SNIP---------------/
>>>>> Hi Bruce, I did work on the Windows SATA driver for those chipsets, so
>>>>> I’m
>>>>> familiar with it. I’m not aware of any of any timing workarounds for any
>>>>> devices in the driver, but it’s certainly true that there are devices
>>>>> that
>>>>> have timing sensitivity, especially around the IDENTIFY command and it
>>>>> may
>>>>> inadvertently work with one driver and not another.
>>>>>
>>>>> From the bug reports it looks like it’s always timing out on a
>>>>> TEST_UNIT_READY command? I assume this is probably the first command
>>>>> sent
>>>>> down after IDENTIFY to check for presense of a CD in the drive? If so
>>>>> it’s
>>>>> likely the drive is locked up and any command at that point will fail.
>>>>> If
>>>>> you want to test out the theory about it being a timing issue, I would
>>>>> stick
>>>>> some udelay()s in the identify code path, both before and after starting
>>>>> the
>>>>> transfer to see if it makes any difference. Also do you know if the
>>>>> driver
>>>>> does a PHY reset when it resets the link? If not, you can try doing that
>>>>> by
>>>>> writing a 0 to SControl and then restoring it with the original value.
>>>>>
>>>>> Hope this helps,
>>>>>
>>>>> -Allen
>>>>> /--------SNIP---------------/
>>>>>
>>>>> Does this provide any actionable information? I've tried searching for
>>>>> the
>>>>> proper location to impliment these delays in the sata_nv.c and
>>>>> libata-eh.c
>>>>> files but admittedly, am in over my head.
>>>> Don't think there's any earth-shaking revelations but it might be a
>>>> few things to try. First, though, apparently there is a firmware
>>>> update for this drive of at least one revision up (WL0G) available
>>>> from Lite-ON that you could try updating to. (You'll likely need to
>>>> use Windows for that.) Given that it seems broken in at least two
>>>> different environments on this controller, it's possible they fixed
>>>> something related in the drive.
>>> Robert,
>>>
>>> I can report that the new firmware for the drive does not solve the
>>> problem.
>>>
>>> watchtv@teevee:~$ dmesg |grep ata5
>>> [ 1.090360] ata5: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0 bmdma 0xc400
>>> irq 20
>>> [ 1.556044] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>>> [ 1.564199] ata5.00: ATAPI: ATAPI iHOS104, WL0G, max UDMA/100
>>> [ 1.580140] ata5.00: configured for UDMA/100
>>> [ 6.580035] ata5.00: qc timeout (cmd 0xa0)
>>> [ 6.580043] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
>>> [ 7.048042] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>>> [ 7.072124] ata5.00: configured for UDMA/100
>>> [ 12.072029] ata5.00: qc timeout (cmd 0xa0)
>>> [ 12.072037] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
>>> [ 12.072041] ata5: limiting SATA link speed to 1.5 Gbps
>>> [ 12.072043] ata5.00: limiting speed to UDMA/100:PIO3
>>> [ 12.540058] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>>> [ 12.564141] ata5.00: configured for UDMA/100
>>> [ 17.564038] ata5.00: qc timeout (cmd 0xa0)
>>> [ 17.564045] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
>>> [ 17.564048] ata5.00: disabled
>>> [ 17.564063] ata5: hard resetting link
>>> [ 17.564065] ata5: nv: skipping hardreset on occupied port
>>> [ 18.032068] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>>> [ 18.032082] ata5: EH complete
>>> watchtv@teevee:~$
>>>
>>> My apologies for not noticing the firmware update earlier. I do recall
>>> checking at one time, though it may have been prior to Sept. 2011.
>>>
>>> Bruce
>> Robert,
>>
>> Writing to you to bump this thread. Is there anything more I can do to
>> troubleshoot this issue?
> A couple of things you could try:
>
> -Does the behavior change if you boot with vs. without a disc in the drive?
>
> -You could try building a kernel with something like adding
> mdelay(1000) at the start of the atapi_eh_clear_ua function in
> drivers/ata/libata-eh.c.You should see an extra 1 second delay (so at
> the very least it should take 6 seconds to timeout rather than 5). If
> that changes anything then perhaps some kind of timing quirk would
> help the problem.
Robert,
I've recompiled the kernel with the mdelay you suggested. Using that
kernel, I booted the machine both with and without a BD disk in the
drive. It didn't work in either case, but the errors were slightly
different. My results are below.
Is there anything else that could be tried?
With a BD disc in the drive:
watchtv@teevee:~$ dmesg | grep ata5
[ 1.068078] ata5: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0 bmdma 0xc400
irq 23
[ 1.536031] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 1.544131] ata5.00: ATAPI: ATAPI iHOS104, WL0G, max UDMA/100
[ 1.560112] ata5.00: configured for UDMA/100
[ 7.552029] ata5.00: qc timeout (cmd 0xa0)
[ 7.552036] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[ 8.020051] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 8.044122] ata5.00: configured for UDMA/100
[ 32.816043] ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
frozen
[ 32.816063] ata5.00: cmd a0/01:00:00:60:00/00:00:00:00:00/a0 tag 0
dma 96 in
[ 32.816066] ata5.00: status: { DRDY }
[ 32.816072] ata5: hard resetting link
[ 32.816074] ata5: nv: skipping hardreset on occupied port
[ 33.284042] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 33.308141] ata5.00: configured for UDMA/100
[ 39.296025] ata5.00: qc timeout (cmd 0xa0)
[ 39.296032] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[ 39.296038] ata5: hard resetting link
[ 39.296040] ata5: nv: skipping hardreset on occupied port
[ 39.764040] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 39.788137] ata5.00: configured for UDMA/100
[ 45.776035] ata5.00: qc timeout (cmd 0xa0)
[ 45.776042] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[ 45.776047] ata5: limiting SATA link speed to 1.5 Gbps
[ 45.776050] ata5.00: limiting speed to UDMA/100:PIO3
[ 45.776058] ata5: hard resetting link
[ 45.776060] ata5: nv: skipping hardreset on occupied port
[ 46.244050] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 46.268138] ata5.00: configured for UDMA/100
Without a BD disc in the drive:
watchtv@teevee:~$ dmesg | grep ata5
[ 1.070412] ata5: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0 bmdma 0xc400
irq 20
[ 1.536043] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 1.544204] ata5.00: ATAPI: ATAPI iHOS104, WL0G, max UDMA/100
[ 1.560149] ata5.00: configured for UDMA/100
[ 7.552027] ata5.00: qc timeout (cmd 0xa0)
[ 7.552033] ata5.00: TEST_UNIT_READY failed (err_mask=0x5)
[ 8.020034] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 8.044127] ata5.00: configured for UDMA/100
[ 14.037175] ata5.00: qc timeout (cmd 0xa0)
[ 14.037183] ata5.00: TEST_UNIT_READY failed (err_mask=0x5)
[ 14.037187] ata5: limiting SATA link speed to 1.5 Gbps
[ 14.037190] ata5.00: limiting speed to UDMA/100:PIO3
[ 14.504069] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 14.528288] ata5.00: configured for UDMA/100
[ 20.528052] ata5.00: qc timeout (cmd 0xa0)
[ 20.528060] ata5.00: TEST_UNIT_READY failed (err_mask=0x5)
[ 20.528062] ata5.00: disabled
[ 20.528077] ata5: hard resetting link
[ 20.528079] ata5: nv: skipping hardreset on occupied port
[ 20.996047] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 20.996062] ata5: EH complete
Thanks
Bruce
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2013-11-09 21:03 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-08-13 22:36 System fails to connect to iHOS-104 DVD drive with nvidia MCP61 chipset Bruce Link
2013-08-14 6:17 ` Robert Hancock
2013-08-14 22:17 ` Bruce Link
2013-08-15 5:36 ` Robert Hancock
2013-08-16 2:47 ` Bruce Link
2013-08-17 17:32 ` Bruce Link
2013-08-18 7:05 ` Robert Hancock
2013-08-24 0:34 ` Bruce Link
[not found] ` <CADLC3L0wXmVDgHPOFEkeiXD9sDUBg3tZePcJ-gRfoRN5-fXE1w@mail.gmail.com>
[not found] ` <52180F76.3070803@1045.ca>
2013-08-24 3:11 ` Robert Hancock
2013-08-24 15:54 ` Bruce Link
[not found] ` <5218D74A.5020305@1045.ca>
2013-09-06 23:17 ` Bruce Link
2013-09-07 1:53 ` Robert Hancock
2013-09-08 12:25 ` Tejun Heo
2013-09-18 0:35 ` Bruce Link
2013-09-18 1:40 ` Robert Hancock
2013-09-18 22:27 ` Bruce Link
2013-10-19 0:04 ` Bruce Link
[not found] ` <5261CC95.1050903@1045.ca>
2013-10-22 1:17 ` Robert Hancock
2013-11-09 21:02 ` Bruce Link
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.