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 there. lspci: 00:00.0 Host bridge: VIA Technologies, Inc. VT8378 [KM400/A] Chipset Host Bridge 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>
still valid as of 2.6.19-rc1 (and no later commits on that corner)
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?).
git bisect may be an option... ...also you said you managed to fix it at some point; explaining how would be nice.
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 CONFIG_PCI_MULTITHREAD_PROBE. Then it eventually saw my discs and enabled me to boot that machine with 2.6.19-rc5-mm1
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 ata_bmdma_error_handler(). I successfully booted 2.6.19-rc5-mm1 with multithread probing disabled
So, are you saying that disabling PCI multithread probing fixed all the problem w/o modifying sata_via?
Indeed.
okay, closing the bug then.
Yes, this is a known issue with many sata drives, that is the way they currently work, sorry.