Bug 7255

Summary: sata-via doesn't detect anymore disks attached to VIA vt6421 (CONFIG_PCI_MULTITHREAD_PROBE)
Product: IO/Storage Reporter: Thierry Vignaud (thierry.vignaud)
Component: Serial ATAAssignee: Tejun Heo (htejun)
Severity: high CC: bunk, greg, htejun, jacliburn
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: 2.6.19-rc5 Tree: Mainline
Regression: ---
Attachments: sata_via badly chokes with PCI multithread probing one

Description Thierry Vignaud 2006-10-03 07:46:54 UTC
Most recent kernel where this bug did not occur: 2.6.18 (broken in 2.6.18-git8 
and previously in libata's git since 2.6.18-rc3-mmX)
Distribution: Mandriva Linux (irrelevant)
Hardware Environment: ia32, VT6421 SATA addon controller plugged on a non sata 
VIA motherboard
Software Environment: <not relevant>
Problem Description:
sata_via doesn't detect anymore any disks on VIA VT6421 controllers (pci ids: 
vendor=1106 device=3249)
It looks like it detects the ports but not the disk attached to one of them 
since new error management was introduced. We once succeeded in fixed it but 
further development break again support for vt6421.

Steps to reproduce: try to boot a newer kernel with a VIA vt6421.
With latest driver, the lines about the sata ports are no more displayed (no 
detection) and thus the disks aren't detected and the bootstrapping stops 


00:00.0 Host bridge: VIA Technologies, Inc. VT8378 [KM400/A] Chipset Host 
00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge
00:09.0 RAID bus controller: VIA Technologies, Inc. VT6421 IDE RAID Controller 
(rev 50)
00:0a.0 USB Controller: NEC Corporation USB (rev 41)
00:0a.1 USB Controller: NEC Corporation USB (rev 41)
00:0a.2 USB Controller: NEC Corporation USB 2.0 (rev 02)
00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 
Controller (rev 80)
00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 
Controller (rev 80)
00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 
Controller (rev 80)
00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge
00:11.1 IDE interface: VIA Technologies, Inc. 
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 
AC97 Audio Controller (rev 50)
00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74)
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R200 QL [Radeon 
8500 LE]

00:09.0 RAID bus controller: VIA Technologies, Inc. VT6421 IDE RAID Controller 
(rev 50)
        Subsystem: VIA Technologies, Inc. VT6421 IDE RAID Controller
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 32
        Interrupt: pin A routed to IRQ 16
        Region 0: I/O ports at b000 [size=16]
        Region 1: I/O ports at b400 [size=16]
        Region 2: I/O ports at b800 [size=16]
        Region 3: I/O ports at bc00 [size=16]
        Region 4: I/O ports at c000 [size=32]
        Region 5: I/O ports at c400 [size=256]
        [virtual] Expansion ROM at 50000000 [disabled] [size=64K]
        Capabilities: <access denied>
Comment 1 Thierry Vignaud 2006-10-17 09:19:11 UTC
still valid as of 2.6.19-rc1 (and no later commits on that corner)
Comment 2 Thierry Vignaud 2006-11-07 08:50:05 UTC
Btw, there's no real changes in sata_via between working 2.6.18 and broken 
2.6.19-rcX besides formating changes, name changes, ...
So it looks like the error management changes in core libata are affecting 
sata_via (maybe exposing a previously hidden issue?).
Comment 3 Pavel Machek 2006-11-10 05:49:58 UTC
git bisect may be an option...

...also you said you managed to fix it at some point; explaining how would be nice.
Comment 4 Thierry Vignaud 2006-11-14 03:13:22 UTC
I got it to boot one while Tejun Heo was updating his EH bits but since latest 
libata it always fine.

Yesterday I altered sata_via so that it used vt6420_prereset for vt6421 too 
like I did earlier. It didn't worked.
I traced sata_via and found out it was looping (nearly freezing a
kernel thread in fact in vt6420_prereset).

I eventually saw the light this night and disabled
Then it eventually saw my discs and enabled me to boot that machine
with 2.6.19-rc5-mm1
Comment 5 Thierry Vignaud 2006-11-14 03:21:28 UTC
Created attachment 9502 [details]
sata_via badly chokes with PCI multithread probing one

CONFIG_PCI_MULTITHREAD_PROBE makes sata_via slowly looping in vt6420_prereset
when using vt6420_error_handler() instead of ata_bmdma_error_handler().
(I didn't bother checking where it actually chokes when using the default
I successfully booted 2.6.19-rc5-mm1 with multithread probing disabled
Comment 6 Tejun Heo 2006-11-15 03:34:18 UTC
So, are you saying that disabling PCI multithread probing fixed all the problem
w/o modifying sata_via?
Comment 7 Thierry Vignaud 2006-11-15 05:30:11 UTC
Comment 8 Tejun Heo 2006-11-15 06:07:33 UTC
okay, closing the bug then.
Comment 9 Greg Kroah-Hartman 2006-11-15 11:48:58 UTC
Yes, this is a known issue with many sata drives, that is the way they currently
work, sorry.