System fails to connect to iHOS-104 DVD drive with nvidia MCP61 chipset.

Bug #1063474 reported by \|Bruce L
14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Confirmed
Medium
Unassigned

Bug Description

The computer fails to connect to the LG iHOS-104 DVD drive.
The drive is working, as it will boot the Windows installer.

I have seen similar bugs posted on the internet for the past 5 years. Here's a thread that shows the problem fixed for the MCP55 chipset.

http://www.gossamer-threads.com/lists/linux/kernel/1234502?do=post_view_threaded#1234502

WORKAROUND: Use the DVD drive with a USB-SATA adapter.

Upstream discussion: http://marc.info/?l=linux-ide&m=137736028900971&w=2

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: linux-image-3.5.0-17-generic 3.5.0-17.27
ProcVersionSignature: Ubuntu 3.5.0-17.27-generic 3.5.5
Uname: Linux 3.5.0-17-generic x86_64
ApportVersion: 2.6.1-0ubuntu1
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: watchtv 7366 F.... pulseaudio
 /dev/snd/controlC0: watchtv 4814 F.... alsamixer
                      watchtv 7366 F.... pulseaudio
CRDA: Error: [Errno 2] No such file or directory: 'iw'
Date: Sun Oct 7 19:34:10 2012
HibernationDevice: RESUME=UUID=914386c4-84a9-4eb4-8382-cb6f877f7ef6
IwConfig:
 eth0 no wireless extensions.

 lo no wireless extensions.
Lsusb:
 Bus 002 Device 006: ID 046d:c047 Logitech, Inc. Laser Mouse
 Bus 002 Device 005: ID 0e8f:0021 GreenAsia Inc. Multimedia Keyboard Controller
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
MachineType: Gigabyte Technology Co., Ltd. M68M-S2P
ProcFB: 0 nouveaufb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.5.0-17-generic root=UUID=81823799-2b15-4236-887b-e3497f3f6a46 ro quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-3.5.0-17-generic N/A
 linux-backports-modules-3.5.0-17-generic N/A
 linux-firmware 1.94
RfKill:

SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
WifiSyslog:

dmi.bios.date: 07/15/2010
dmi.bios.vendor: Award Software International, Inc.
dmi.bios.version: FCb
dmi.board.name: M68M-S2P
dmi.board.vendor: Gigabyte Technology Co., Ltd.
dmi.board.version: x.x
dmi.chassis.type: 3
dmi.chassis.vendor: Gigabyte Technology Co., Ltd.
dmi.modalias: dmi:bvnAwardSoftwareInternational,Inc.:bvrFCb:bd07/15/2010:svnGigabyteTechnologyCo.,Ltd.:pnM68M-S2P:pvr:rvnGigabyteTechnologyCo.,Ltd.:rnM68M-S2P:rvrx.x:cvnGigabyteTechnologyCo.,Ltd.:ct3:cvr:
dmi.product.name: M68M-S2P
dmi.sys.vendor: Gigabyte Technology Co., Ltd.
---
ApportVersion: 2.12-0ubuntu3
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: watchtv 1305 F.... pulseaudio
CRDA: Error: command ['iw', 'reg', 'get'] failed with exit code 1: nl80211 not found.
CurrentDmesg:
 [ 55.165828] pool[1480]: segfault at 40 ip 00007f3d05544f87 sp 00007f3d03653c50 error 4 in tumbler-gst-thumbnailer.so[7f3d05542000+4000]
 [ 707.285402] python[6778]: segfault at 0 ip 00007eff23bde2f7 sp 00007fffeba941f8 error 4 in libgtk-3.so.0.800.2[7eff23ade000+4c5000]
DistroRelease: Ubuntu 13.10
HibernationDevice: RESUME=UUID=914386c4-84a9-4eb4-8382-cb6f877f7ef6
IwConfig:
 eth0 no wireless extensions.

 lo no wireless extensions.
Lsusb:
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 002 Device 003: ID 0e8f:0021 GreenAsia Inc. Multimedia Keyboard Controller
 Bus 002 Device 002: ID 045e:0719 Microsoft Corp. Xbox 360 Wireless Adapter
 Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
MachineType: Gigabyte Technology Co., Ltd. M68M-S2P
MarkForUpload: True
Package: linux (not installed)
ProcFB: 0 nouveaufb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.10.0-6-generic root=UUID=e276cadb-f115-40c5-abe4-2471badc3113 ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 3.10.0-6.17-generic 3.10.3
RelatedPackageVersions:
 linux-restricted-modules-3.10.0-6-generic N/A
 linux-backports-modules-3.10.0-6-generic N/A
 linux-firmware 1.113
RfKill:

Tags: saucy
Uname: Linux 3.10.0-6-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
dmi.bios.date: 08/25/2010
dmi.bios.vendor: Award Software International, Inc.
dmi.bios.version: FC
dmi.board.name: M68M-S2P
dmi.board.vendor: Gigabyte Technology Co., Ltd.
dmi.board.version: x.x
dmi.chassis.type: 3
dmi.chassis.vendor: Gigabyte Technology Co., Ltd.
dmi.modalias: dmi:bvnAwardSoftwareInternational,Inc.:bvrFC:bd08/25/2010:svnGigabyteTechnologyCo.,Ltd.:pnM68M-S2P:pvr:rvnGigabyteTechnologyCo.,Ltd.:rnM68M-S2P:rvrx.x:cvnGigabyteTechnologyCo.,Ltd.:ct3:cvr:
dmi.product.name: M68M-S2P
dmi.sys.vendor: Gigabyte Technology Co., Ltd.

Revision history for this message
\|Bruce L (fq-bruce-x0) wrote :
Brad Figg (brad-figg)
Changed in linux (Ubuntu):
status: New → Confirmed
Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.6 kernel[0] (Not a kernel in the daily directory) and install both the linux-image and linux-image-extra .deb packages.

Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. Please only remove that one tag and leave the other tags. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text.

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.6-quantal/

tags: added: needs-upstream-testing
Changed in linux (Ubuntu):
status: Confirmed → Incomplete
importance: Undecided → Medium
Revision history for this message
\|Bruce L (fq-bruce-x0) wrote :

Downloade and installed:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.6-quantal/linux-image-3.6.0-030600-generic_3.6.0-030600.201209302035_amd64.deb
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.6-quantal/linux-image-extra-3.6.0-030600-generic_3.6.0-030600.201209302035_amd64.deb

as per your request.

machine hung on boot after USB keyboard detection. The boot sequence did not make it to the sata initialization, so I am unable to confirm or deny that it is fixed in the mainline.

tags: added: kernel-unable-to-test-upstream
removed: needs-upstream-testing
Revision history for this message
\|Bruce L (fq-bruce-x0) wrote :

I've been diligently trying to get the system to boot with the mainline kernels as I notice updates in the repository, but the result is the same, the kernel hangs on boot.

I did some more digging, and it looks like it's hanging around the point that ata stuff initializes. (I've attached a screenshot showing where it locks up.)

It also appears that the kernel is still responding, as the screen shows the keyboard being unplugged and plugged back in, and it looks like the monitor went to sleep after some time.

Revision history for this message
\|Bruce L (fq-bruce-x0) wrote :

I detached the CD drive from the SATA cable as well. The mainline kernel still got stuck at the same point.

Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

Changed in linux (Ubuntu):
status: Incomplete → Expired
penalvch (penalvch)
tags: added: bios-outdated-fc needs-upstream-testing regression-potential
Changed in linux (Ubuntu):
status: Expired → Incomplete
Revision history for this message
\|Bruce L (fq-bruce-x0) wrote :

I believe that I'm already at the latest BIOS revision. So I'm experiencing the same problem as I've detailed above. Mainly, that the DVD fails to be connected to. Relevant output is shown below.

watchtv@teevee:~$ dmesg |grep ata5
[ 1.173566] ata5: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0 bmdma 0xc400 irq 23
[ 1.640041] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 1.648168] ata5.00: ATAPI: ATAPI iHOS104, WL0F, max UDMA/100
[ 1.664142] ata5.00: configured for UDMA/100
[ 6.664377] ata5.00: qc timeout (cmd 0xa0)
[ 6.664385] ata5.00: TEST_UNIT_READY failed (err_mask=0x5)
[ 7.132071] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 7.156152] ata5.00: configured for UDMA/100
[ 12.156032] ata5.00: qc timeout (cmd 0xa0)
[ 12.156038] ata5.00: TEST_UNIT_READY failed (err_mask=0x5)
[ 12.156043] ata5: limiting SATA link speed to 1.5 Gbps
[ 12.156045] ata5.00: limiting speed to UDMA/100:PIO3
[ 12.624088] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 12.652217] ata5.00: configured for UDMA/100
[ 17.652031] ata5.00: qc timeout (cmd 0xa0)
[ 17.652038] ata5.00: TEST_UNIT_READY failed (err_mask=0x5)
[ 17.652040] ata5.00: disabled
[ 17.652054] ata5: hard resetting link
[ 17.652056] ata5: nv: skipping hardreset on occupied port
[ 18.120056] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 18.120072] ata5: EH complete
watchtv@teevee:~$

I've posted the output you've requested below.

watchtv@teevee:~$ sudo dmidecode -s bios-version && sudo dmidecode -s bios-release-date
[sudo] password for watchtv:
FCb
07/15/2010
watchtv@teevee:~$

Revision history for this message
\|Bruce L (fq-bruce-x0) wrote :

I've reflashed the motherboard as per your request. Here's the output of the dmidecode command:

watchtv@teevee:~$ sudo dmidecode -s bios-version && sudo dmidecode -s bios-release-date
FC
08/25/2010

The TEST_UNIT_READY problem still persists, the drive is now at ata3

watchtv@teevee:~$ dmesg|grep ata3
[ 1.115641] ata3: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0 bmdma 0xc400 irq 20
[ 1.580043] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 1.588139] ata3.00: ATAPI: ATAPI iHOS104, WL0F, max UDMA/100
[ 1.604120] ata3.00: configured for UDMA/100
[ 6.604080] ata3.00: qc timeout (cmd 0xa0)
[ 6.604088] ata3.00: TEST_UNIT_READY failed (err_mask=0x4)
[ 7.072049] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 7.096120] ata3.00: configured for UDMA/100
[ 12.096036] ata3.00: qc timeout (cmd 0xa0)
[ 12.096043] ata3.00: TEST_UNIT_READY failed (err_mask=0x4)
[ 12.096047] ata3: limiting SATA link speed to 1.5 Gbps
[ 12.096050] ata3.00: limiting speed to UDMA/100:PIO3
[ 12.564048] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 12.588188] ata3.00: configured for UDMA/100
[ 17.588029] ata3.00: qc timeout (cmd 0xa0)
[ 17.588036] ata3.00: TEST_UNIT_READY failed (err_mask=0x4)
[ 17.588038] ata3.00: disabled
[ 17.588052] ata3: hard resetting link
[ 17.588054] ata3: nv: skipping hardreset on occupied port
[ 18.056050] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 18.056064] ata3: EH complete

Thanks
Bruce

penalvch (penalvch)
tags: added: latest-bios-fc
removed: bios-outdated-fc
Revision history for this message
\|Bruce L (fq-bruce-x0) wrote :

Christopher,

I suspect that the problem still exists as I am unable to boot the CD. It tries to load a file from the CD and after failing a good number of times drops to the busybox shell.

I am currently unable to run the command requested.

I do not currently have a large enough USB stick to accommodate the CD image. I will try to buy one sometime this week and perform the test.

I typically install from PXE, are there PXE images available for 13.10?

Thanks
Bruce

Revision history for this message
\|Bruce L (fq-bruce-x0) wrote :

As per your request:

watchtv@teevee:~$ sudo lsscsi -d -L -v
[0:0:0:0] disk ATA WDC WD20EARS-00M 51.0 /dev/sda [8:0]
  device_blocked=0
  iocounterbits=32
  iodone_cnt=0x52b9
  ioerr_cnt=0x2
  iorequest_cnt=0x52ba
  queue_depth=1
  queue_type=none
  scsi_level=6
  state=running
  timeout=30
  type=0
  dir: /sys/bus/scsi/devices/0:0:0:0 [/sys/devices/pci0000:00/0000:00:08.0/ata1/host0/target0:0:0/0:0:0:0]

Revision history for this message
\|Bruce L (fq-bruce-x0) wrote :

That's everything.

Revision history for this message
\|Bruce L (fq-bruce-x0) wrote : AlsaInfo.txt

apport information

tags: added: apport-collected saucy
description: updated
Revision history for this message
\|Bruce L (fq-bruce-x0) wrote : BootDmesg.txt

apport information

Revision history for this message
\|Bruce L (fq-bruce-x0) wrote : Lspci.txt

apport information

Revision history for this message
\|Bruce L (fq-bruce-x0) wrote : ProcCpuinfo.txt

apport information

Revision history for this message
\|Bruce L (fq-bruce-x0) wrote : ProcEnviron.txt

apport information

Revision history for this message
\|Bruce L (fq-bruce-x0) wrote : ProcInterrupts.txt

apport information

Revision history for this message
\|Bruce L (fq-bruce-x0) wrote : ProcModules.txt

apport information

Revision history for this message
\|Bruce L (fq-bruce-x0) wrote : PulseList.txt

apport information

Revision history for this message
\|Bruce L (fq-bruce-x0) wrote : UdevDb.txt

apport information

Revision history for this message
\|Bruce L (fq-bruce-x0) wrote : UdevLog.txt

apport information

Revision history for this message
\|Bruce L (fq-bruce-x0) wrote : WifiSyslog.txt

apport information

Revision history for this message
\|Bruce L (fq-bruce-x0) wrote :

I've upgraded the system to 13.10. The apport-collect -p linux output is above. I will try getting the mainline running shortly.

Revision history for this message
\|Bruce L (fq-bruce-x0) wrote :

Christopher,

I have confirmed the problem exists in the mainline kernel and updated the tags as per your request.

tags: removed: kernel-unable-to-test-upstream needs-upstream-testing
tags: added: kernel-bug-exists-upstream kernel-bug-exists-upstream-3.11.0-031100rc4-generic
penalvch (penalvch)
tags: added: kernel-bug-exists-upstream-v3.11-rc4
removed: kernel-bug-exists-upstream-3.11.0-031100rc4-generic
Revision history for this message
\|Bruce L (fq-bruce-x0) wrote :

I've never had this unit working properly under ubuntu or any other linux distribution.

I think the earliest version that I've run on this hardware is 11.10. Not entirely sure of the exact number though.

Revision history for this message
\|Bruce L (fq-bruce-x0) wrote :

Tested with Lucid, same problem exists.

penalvch (penalvch)
tags: added: lucid
removed: regression-potential
tags: added: needs-upstream-testing
removed: kernel-bug-exists-upstream
Revision history for this message
\|Bruce L (fq-bruce-x0) wrote :

Problem persists in latest mainline kernel.

penalvch (penalvch)
tags: added: kernel-bug-exists-upstream-v3.11-rc5
removed: kernel-bug-exists-upstream-v3.11-rc4 needs-upstream-testing
Revision history for this message
penalvch (penalvch) wrote :

\|Bruce L, the issue you are reporting is an upstream one. Could you please report this problem through the appropriate channel by following the instructions _verbatim_ at https://wiki.ubuntu.com/Bugs/Upstream/kernel#KernelTeam.2BAC8-KernelTeamBugPolicies.Overview_on_Reporting_Bugs_Upstream ?

Thank you for your understanding.

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
\|Bruce L (fq-bruce-x0) wrote :
Download full text (5.6 KiB)

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
>...

Read more...

Revision history for this message
\|Bruce L (fq-bruce-x0) wrote :
Download full text (3.2 KiB)

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 conside...

Read more...

penalvch (penalvch)
Changed in linux (Ubuntu):
status: Confirmed → Invalid
Revision history for this message
\|Bruce L (fq-bruce-x0) wrote :
Download full text (3.7 KiB)

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 res...

Read more...

penalvch (penalvch)
Changed in linux (Ubuntu):
status: Invalid → Confirmed
description: updated
Revision history for this message
penalvch (penalvch) wrote :

\|Bruce L, would it be case that the DVD drive is fine, but the specific SATA connection cables/port to the M68M-S2P board or board itself has a hardware failure given you tested it in Windows when SATA connected and it still didn't work?

Changed in linux (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
\|Bruce L (fq-bruce-x0) wrote :
Download full text (4.6 KiB)

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
>>>...

Read more...

Revision history for this message
penalvch (penalvch) wrote :

\|Bruce L, could you please provide a URL for your upstream discussion?

Revision history for this message
\|Bruce L (fq-bruce-x0) wrote : Re: [Bug 1063474] Re: System fails to connect to iHOS-104 DVD drive with nvidia MCP61 chipset.

On 8/24/2013 6:13 AM, Christopher M. Penalver wrote:
> \|Bruce L, could you please provide a URL for your upstream discussion?
>
I have not been supplied with a URL.

Revision history for this message
\|Bruce L (fq-bruce-x0) wrote :
Download full text (5.5 KiB)

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 i...

Read more...

Revision history for this message
\|Bruce L (fq-bruce-x0) wrote :
Download full text (6.0 KiB)

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/ho...

Read more...

Revision history for this message
penalvch (penalvch) wrote :

\|Bruce L, what maintainer mailing list did you post to specifically?

Revision history for this message
tj (htejun) 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

Revision history for this message
\|Bruce L (fq-bruce-x0) wrote :

This bug was posted to <email address hidden>

penalvch (penalvch)
description: updated
Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
\|Bruce L (fq-bruce-x0) 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.

Thanks
Bruce

Revision history for this message
\|Bruce L (fq-bruce-x0) wrote :
Download full text (4.5 KiB)

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@te...

Read more...

Revision history for this message
penalvch (penalvch) wrote :

\|Bruce L, could you please provide a direct URL to the firmware you updated to?

Revision history for this message
\|Bruce L (fq-bruce-x0) wrote :

I use the Lite-on "SmartPack" utility to update the firmware. It can be found here:

http://www.liteonit.eu/eu/DOWNLOADS/utilities/SmartPackSetup1.22.0.exe.zip

Revision history for this message
Joseph Salisbury (jsalisbury) wrote : Please test latest development kernel (3.11.0-7.14)

Given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We are approaching release and would like to confirm if this bug is still present. Please test again with the latest development kernel and indicate in the bug if this issue still exists or not.

You can update to the latest development kernel by simply running the following commands in a terminal window:

    sudo apt-get update
    sudo apt-get dist-upgrade

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

Thank you for your help, we really do appreciate it.

Changed in linux (Ubuntu):
status: Confirmed → Incomplete
tags: added: kernel-request-3.11.0-7.14
Revision history for this message
\|Bruce L (fq-bruce-x0) wrote :

I can confirm the bug still exists under 3.11.0-7.14

uanwatchtv@teevee:~$ uname -a
Linux teevee 3.11.0-7-generic #14-Ubuntu SMP Mon Sep 16 18:37:27 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
watchtv@teevee:~$ dmesg|grep ata5
[ 1.082883] ata5: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0 bmdma 0xc400 irq 23
[ 1.552031] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 1.560117] ata5.00: ATAPI: ATAPI iHOS104, WL0G, max UDMA/100
[ 1.576138] ata5.00: configured for UDMA/100
[ 6.576040] ata5.00: qc timeout (cmd 0xa0)
[ 6.576047] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[ 7.044052] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 7.068123] ata5.00: configured for UDMA/100
[ 29.856044] ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[ 29.856065] ata5.00: cmd a0/01:00:00:60:00/00:00:00:00:00/a0 tag 0 dma 96 in
[ 29.856067] ata5.00: status: { DRDY }
[ 29.856075] ata5: hard resetting link
[ 29.856077] ata5: nv: skipping hardreset on occupied port
[ 30.324069] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 30.348329] ata5.00: configured for UDMA/100
[ 35.348031] ata5.00: qc timeout (cmd 0xa0)
[ 35.348038] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[ 35.348044] ata5: hard resetting link
[ 35.348046] ata5: nv: skipping hardreset on occupied port
[ 35.816055] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 35.840125] ata5.00: configured for UDMA/100
[ 40.840027] ata5.00: qc timeout (cmd 0xa0)
[ 40.840034] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[ 40.840038] ata5: limiting SATA link speed to 1.5 Gbps
[ 40.840040] ata5.00: limiting speed to UDMA/100:PIO3
[ 40.840045] ata5: hard resetting link
[ 40.840047] ata5: nv: skipping hardreset on occupied port
[ 41.308037] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 41.332118] ata5.00: configured for UDMA/100
watchtv@teevee:~$

penalvch (penalvch)
Changed in linux (Ubuntu):
status: Incomplete → Confirmed
tags: added: bot-stop-nagging
removed: kernel-request-3.11.0-7.14
Revision history for this message
\|Bruce L (fq-bruce-x0) wrote :
Download full text (4.8 KiB)

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 ...

Read more...

Revision history for this message
penalvch (penalvch) wrote :

\|Bruce L, one thing you could do to keep the momentum is to test the latest mainline kernel via http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.12-rc6-saucy/ and advise if it's still reproducible.

tags: added: needs-upstream-testing
Revision history for this message
\|Bruce L (fq-bruce-x0) wrote :
Download full text (8.8 KiB)

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
...

Read more...

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.