Most recent kernel where this bug did not occur: none Distribution: Fedora Core 4 Hardware Environment: Asus A8V Deluxe Athlon 64 X2 4200 2gig RAM PC3200 OCZ Titanium Nvidia AGP MSI 6800 Maxtor 250G SATA Plextor 716SATA External USB 150G HD IDE DVD Reader [root@th0ma7 ~]# lspci 00:00.0 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge 00:00.1 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge 00:00.2 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge 00:00.3 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge 00:00.4 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge 00:00.7 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800/K8T890 South] 00:07.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80) 00:0a.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller (rev 13) 00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) 00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) 00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) 00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) 00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South] 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 01:00.0 VGA compatible controller: nVidia Corporation NV40 [GeForce 6800] (rev a1) Software Environment: x86_64 distribution gcc 4.0.1 X 6.8.2 KDE 3.4 Problem Description: The only thing I can get into the dmesg is this (don't know if it is relevant): CI: Via IRQ fixup for 0000:00:0f.1, from 255 to 9 VP_IDE: chipset revision 6 VP_IDE: not 100% native mode: will probe irqs later VP_IDE: VIA vt8237 (rev 00) IDE UDMA133 controller on pci0000:00:0f.1 ide0: BM-DMA at 0xfc00-0xfc07, BIOS settings: hda:pio, hdb:DMA ide1: BM-DMA at 0xfc08-0xfc0f, BIOS settings: hdc:pio, hdd:pio [root@th0ma7 ~]# cat /proc/scsi/scsi Attached devices: Host: scsi1 Channel: 00 Id: 00 Lun: 00 (MAIN SATA HD) Vendor: ATA Model: Maxtor 6B250S0 Rev: BANC Type: Direct-Access ANSI SCSI revision: 05 Host: scsi3 Channel: 00 Id: 00 Lun: 00 (SMART CARD READER) Vendor: Generic Model: STORAGE DEVICE Rev: 0125 Type: Direct-Access ANSI SCSI revision: 02 Host: scsi3 Channel: 00 Id: 00 Lun: 01 (SMART CARD READER) Vendor: Generic Model: STORAGE DEVICE Rev: 0125 Type: Direct-Access ANSI SCSI revision: 02 Host: scsi3 Channel: 00 Id: 00 Lun: 02 (SMART CARD READER) Vendor: Generic Model: STORAGE DEVICE Rev: 0125 Type: Direct-Access ANSI SCSI revision: 02 Host: scsi3 Channel: 00 Id: 00 Lun: 03 (SMART CARD READER) Vendor: Generic Model: STORAGE DEVICE Rev: 0125 Type: Direct-Access ANSI SCSI revision: 02 Host: scsi2 Channel: 00 Id: 00 Lun: 00 (USB HD) Vendor: HDS72251 Model: 6VLAT80 Rev: 0 0 Type: Direct-Access ANSI SCSI revision: 02 Steps to reproduce: Always
I saw in the kernel.org log that there has been a few updates with libata so I decided to give it a try yesterday with 2.6.14-git9. Got a lot more info out of the dmesg but still no success. The log output shows (if I understand it right...) that it has found an ATAPI device on channel 1 but never associate a /dev/sdXYZ to it. Also the /proc/scsi/scsi does not change from the original post. Here is the interesting part of the dmesg: libata version 1.12 loaded. sata_via 0000:00:0f.0: version 1.1 ACPI: PCI Interrupt 0000:00:0f.0[B] -> GSI 20 (level, low) -> IRQ 169 PCI: Via IRQ fixup for 0000:00:0f.0, from 10 to 9 sata_via 0000:00:0f.0: routed to hard irq line 9 ata1: SATA max UDMA/133 cmd 0xD000 ctl 0xC802 bmdma 0xB800 irq 169 ata2: SATA max UDMA/133 cmd 0xC400 ctl 0xC002 bmdma 0xB808 irq 169 ata1: dev 0 cfg 49:0f00 82:0000 83:0000 84:0000 85:0000 86:0000 87:0000 88:001f ata1: dev 0 ATAPI, max UDMA/66 ata1(0): applying bridge limits ata1: dev 0 configured for UDMA/66 scsi0 : sata_via ata2: dev 0 cfg 49:2f00 82:7c6b 83:7f09 84:4673 85:7c69 86:3e01 87:4663 88:407f ata2: dev 0 ATA-7, max UDMA/133, 490234752 sectors: LBA48 ata2: dev 0 configured for UDMA/133 scsi1 : sata_via Vendor: ATA Model: Maxtor 6B250S0 Rev: BANC Type: Direct-Access ANSI SCSI revision: 05 SCSI device sda: 490234752 512-byte hdwr sectors (251000 MB) SCSI device sda: drive cache: write back SCSI device sda: 490234752 512-byte hdwr sectors (251000 MB) SCSI device sda: drive cache: write back sda: sda1 sda2 < sda5 sda6 sda7 sda8 sda9 sda10 > sda3 sda4 sd 1:0:0:0: Attached scsi disk sda
dunno if it'll help but do you have scsi CDROM enabled in kernel config?
Yes I do have SCSI CDROM configured, as a module, and also enable vendor specific extension (for scsi CDROM)... That portion of the config is the same has a clean FC4 kernel. In fact I have only removed unused drivers (mostly nic's), laptop specific stuff and intel only options. I also adjusted the kernel specifically for my cpu type.
I saw a few updates to libata so I decided to give a try to 2.6.15-rc1-git2.... still no success.. - vin
I tought it would be good to add that I get the same problem with the original 2.6.14 kernel rpm from fedora project. My own kernel configuration files are based on the original fedora kernel configs. Should I also open a bug on the fedora project side? thnx - vin
This week-end I tried a kubuntu installation (wich uses 2.6.12). The installator simply hanged on the detection of my plextor... I finally deconnected it and restarted the installation... this time without too many problems... (although I finally came back to fedora due to other reasons..) I also still have a WindowXP 64 available.. my plextor work properly on it (snip :(). I tough it might be an hardware issue but no. Anyhow I'll use the DVD writer of my laptop on Linux before using my DVD burner on Windows XP.. I just tought this info could be usefull.
I just tried 2.6.15-rc6 ... I've compiled scsi cdrom and sata_via built-in just to give it a try... Here is the interesting part of the dmesg: sata_via 0000:00:0f.0: routed to hard irq line 9 ata1: SATA max UDMA/133 cmd 0xD000 ctl 0xC802 bmdma 0xB800 irq 169 ata2: SATA max UDMA/133 cmd 0xC400 ctl 0xC002 bmdma 0xB808 irq 169 ata1: dev 0 cfg 49:2f00 82:7c6b 83:7f09 84:4673 85:7c69 86:3e01 87:4663 88:407f ata1: dev 0 ATA-7, max UDMA/133, 490234752 sectors: LBA48 ata1: dev 0 configured for UDMA/133 scsi0 : sata_via ata2: dev 0 cfg 49:0f00 82:0000 83:0000 84:0000 85:0000 86:0000 87:0000 88:001f ata2: dev 0 ATAPI, max UDMA/66 ata2(0): applying bridge limits ata2: dev 0 configured for UDMA/66 scsi1 : sata_via Vendor: ATA Model: Maxtor 6B250S0 Rev: BANC Type: Direct-Access ANSI SCSI revision: 05 ata2(0): WARNING: ATAPI is disabled, device ignored. SCSI device sda: 490234752 512-byte hdwr sectors (251000 MB) SCSI device sda: drive cache: write back SCSI device sda: 490234752 512-byte hdwr sectors (251000 MB) SCSI device sda: drive cache: write back sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 sda8 sda9 > The WARNING ATAPI disabled tells a lot!... Now just need to figure out how to enable it .. .if there is a way.
Tried something else: I edited libata-core.c and set "int atapi_enabled = 1;" at line 81 and recompiled again.. This time with scsi-cdrom and stat_via has regular modules. I first got a kernel panic... then at the two next reboot I got this: libata version 1.20 loaded. sata_via 0000:00:0f.0: version 1.1 ACPI: PCI Interrupt 0000:00:0f.0[B] -> GSI 20 (level, low) -> IRQ 169 PCI: Via IRQ fixup for 0000:00:0f.0, from 10 to 9 sata_via 0000:00:0f.0: routed to hard irq line 9 ata1: SATA max UDMA/133 cmd 0xD000 ctl 0xC802 bmdma 0xB800 irq 169 ata2: SATA max UDMA/133 cmd 0xC400 ctl 0xC002 bmdma 0xB808 irq 169 ata1: dev 0 cfg 49:2f00 82:7c6b 83:7f09 84:4673 85:7c69 86:3e01 87:4663 88:407f ata1: dev 0 ATA-7, max UDMA/133, 490234752 sectors: LBA48 ata1: dev 0 configured for UDMA/133 scsi0 : sata_via ata2: dev 0 cfg 49:0f00 82:0000 83:0000 84:0000 85:0000 86:0000 87:0000 88:001f ata2: dev 0 ATAPI, max UDMA/66 ata2(0): applying bridge limits ata2: dev 0 configured for UDMA/66 scsi1 : sata_via Vendor: ATA Model: Maxtor 6B250S0 Rev: BANC Type: Direct-Access ANSI SCSI revision: 05 SCSI device sda: 490234752 512-byte hdwr sectors (251000 MB) SCSI device sda: drive cache: write back SCSI device sda: 490234752 512-byte hdwr sectors (251000 MB) SCSI device sda: drive cache: write back sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 sda8 sda9 > sd 0:0:0:0: Attached scsi disk sda ata2: command 0xa0 timeout, stat 0xd0 host_stat 0x1 ata2: translated ATA stat/err 0xd0/00 to SCSI SK/ASC/ASCQ 0xb/47/00 The Warning ATAPI disabled disapeared but still .. my drive ain't working. I tought ATAPI was enable by default since 2.6.11-rc4 (http://lwn.net/Articles/123324/) but I might be wrong.
Therer is also a bug opened up on fedora's bugzilla. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176072
Vincent, it should work. Compile everything builtin and boot with parameter "libata.atapi_enabled=1". Or load libata module with 'atapi_enabled=1' and don't forget sr module.
Created attachment 7160 [details] Kernel 2.6.15.1 at detect time of the SATA via controler 1 out of 4 boot I get this BLIST_INQUIRY_36 message. 3 out of 4 boot I simply get a 0xa0 timeout 1 out of 10 boot it detects correctly my DVDR then suddently crash before the end of the boot.
Created attachment 7161 [details] Kernel 2.6.15.1 Panic Part 1
Created attachment 7162 [details] Kernel 2.6.15.1 Panic Part 2
I have tried both... 1- Compiled ther kernel with sata_via has a module and added to my /etc/modprobe.conf "options sata_via atapi_enabled=1" but it refused to boot (bad option or something like that?!? need to check) 2- Compiled with scsi sata_via built-in with the option at boot time in grub "libata.atapi_enabled=1"... And got the now famous (for me) BLIST_INQUIRY_36 error msg + krenel panic! I've been experiencing the exact same thing with the latest FC4 testing kernels... - vin
Hello, Vincent. I happen to have the same DVD-writer (px716sa) and it works like a charm (at least reading part) on my sata_sil/sil24/ahci/ata_piix. At this point, it seems like a bug in sata_via regarding ATAPI PACKET commands. In libata.h, near the top there's a line which looks like '#undef ATA_DEBUG'. Change this line to '#define ATA_DEBUG' and try again. This will generate quite some amount of debug messages, it will be best if you can setup serial or net console and catch all the outputs. If you can't, the alternatives are... 1. after boot is complete, report the output of 'dmesg'. If dmesg output doesn't contain full boot process, increase Kernel Hacking -> Kernel log buffer size to 17, recompile and retry. 2. if, for some reason, #1 is impossible, take a picture of the screen near the timeout error message. Booting with vga=extended or 0x305 might help. Also, if you succeed to setup serial or net console, can you please reproduce the panic and report full kernel log? That panic shouldn't have happened. You've found a critical bug there. Yet another thing to try is, if you have a SATA port which is connected to something other than the VIA southbridge, try to connect 716sa to that port.
Hi, - I've set '#define ATA_DEBUG' into include/linux/libata.h - Kernel Hacking -> Kernel log buffer size was already set to 17 - Recompiled - Added vga=0x305 to grub kernel boot line - booted into single user mode (does not crash but still produce quite an output!) In fact the output was way too big for dmesg buffer size.... It looped hundreds of times on: ata_scsi_dump_cdb: CDB (1:0,0,0) 28 00 02 c1 00 8a 00 00 04 ata_sg_setup: 1 sg elements mapped ata_exec_command_pio: ata1: cmd 0x25 ata_host_intr: ata1: protocol 4 (dev_stat 0x50) ata_scsi_dump_cdb: CDB (1:0,0,0) 28 00 02 c1 00 7b 00 00 04 ata_sg_setup: 1 sg elements mapped ata_exec_command_pio: ata1: cmd 0x25 ata_host_intr: ata1: protocol 4 (dev_stat 0x50) ata_scsi_dump_cdb: CDB (1:0,0,0) 28 00 02 c1 00 7f 00 00 01 ata_sg_setup: 1 sg elements mapped ata_exec_command_pio: ata1: cmd 0x25 ata_host_intr: ata1: protocol 4 (dev_stat 0x50) ata_scsi_dump_cdb: CDB (1:0,0,0) 28 00 02 c1 00 8a 00 00 01 ata_sg_setup: 1 sg elements mapped ata_exec_command_pio: ata1: cmd 0x25 ata_host_intr: ata1: protocol 4 (dev_stat 0x50) ...And eventually took all the output buffer... Note that the CDB always change.... I'll upload the log file. Has soon has I activate a run-lvl change (init 3) it starts looping once again but without never stopping... and the output is really not readable. Question 1: How can I increase even more the Kernel log buffer size? Solution 1: I might go to radio shak get a null-modem 9pin serial cable and plug my PC to my laptop to completely capture the output. -vin
Just increasing the 17 to 20 (1M) or 22 (4M) should do. Serial console is always nice to have though.
Just made some testing with my laptop and my PC at job using a 3com switch management cable.... looks like it is a null-modem serial 9pin to 9pin cable. It worked like a charm... so I'll be able to gather the info using my laptop probably tonight or tomorrow when I'll get back (depending of how late I come home). - vin
Created attachment 7211 [details] Kernel output from serial port - ata2 0xa0 timeout - Boot OK - The plextor DVDR drive IS connected - SATA ATAPI is activated Got a time out on ata2 and computer booted properly.
Created attachment 7212 [details] Kernel output from serial port - BLIST_INQUIRY_36 - kernel panic - The plextor DVDR drive IS connected - SATA ATAPI is activated Got a BLIST_INQUIRY_36 out on ata2 and finally a kernel panic.
Created attachment 7213 [details] Kernel output from serial port - Plextor DVDR detected - kernel panic - The plextor DVDR drive IS connected - SATA ATAPI is activated Detected the DVDR out on ata2 and finally a kernel panic.
It took me around 15 reboot to finally get all 3 scenario... and a new one emerged: Only onced it detected the Plextor DVDR drive and booted fine (sadly in interractive mode)? Also, sadly I've lost the output when restarting my command... Just to let traces for eventual others?: In my grub file I added to the kernel boot line (since compiled with sata_via built-in): libata.atapi_enabled=1 vga=0x305 console=tty0 console=ttyS0,115200n8 And on my laptop I've used this command: stty 115200 -hup -parenb cs8 raw < /dev/ttyS0 && exec cat < /dev/ttyS0 > kernel-output.2.6.15.1.txt Hope this helps! - vin
Hello, Vincent. Thanks for all the reportings. They sure help. The BUG()'s you're seeing is due to lack of synchronization between ATAPI pio and libata EH which is currently being worked on libata-dev tree, so it should be solved soon. On the other hand, I'm not sure why the timeout occurs in the first place. As ATAPI IDENTIFY seems to always succeed. It's either... 1. Something is wrong with sata_via ATAPI command handling 2. PIO mode setting, which is performed after IDENTIFY but before SCSI INQUIRY, isn't quite correct. As INQUIRY seems to succeed sometimes, my money in on #2, but still not so sure as not many SATA controllers are affected by PIO setting and my PX716SA works fine with the same setting as yours. I'm gonna attach a patch which makes sata_via simply skip PIO configuration. Please try the patch and I think you can turn off ATA_DEBUG now. Thanks for all the trouble.
Created attachment 7218 [details] This patch makes libata skip ata_set_xfermode() for ATAPI devices.
I've applied the patch and I'm still getting a 0xa0 timeout... Here is the usual output: libata version 1.20 loaded. sata_via 0000:00:0f.0: version 1.1 ACPI: PCI Interrupt 0000:00:0f.0[B] -> GSI 20 (level, low) -> IRQ 169 PCI: Via IRQ fixup for 0000:00:0f.0, from 10 to 9 sata_via 0000:00:0f.0: routed to hard irq line 9 ata1: SATA max UDMA/133 cmd 0xD000 ctl 0xC802 bmdma 0xB800 irq 169 ata2: SATA max UDMA/133 cmd 0xC400 ctl 0xC002 bmdma 0xB808 irq 169 ata1: dev 0 cfg 49:2f00 82:7c6b 83:7f09 84:4673 85:7c69 86:3e01 87:4663 88:407f ata1: dev 0 ATA-7, max UDMA/133, 490234752 sectors: LBA48 ata1: dev 0 configured for UDMA/133 scsi0 : sata_via ata2: dev 0 cfg 49:0f00 82:0000 83:0000 84:0000 85:0000 86:0000 87:0000 88:001f ata2: dev 0 ATAPI, max UDMA/66 ata2(0): applying bridge limits ata2: skipping set_xfermode for ATAPI device ata2: dev 0 configured for UDMA/66 scsi1 : sata_via Vendor: ATA Model: Maxtor 6B250S0 Rev: BANC Type: Direct-Access ANSI SCSI revision: 05 ata2: command 0xa0 timeout, stat 0xd0 host_stat 0x1 ata2: translated ATA stat/err 0xd0/00 to SCSI SK/ASC/ASCQ 0xb/47/00 SCSI device sda: 490234752 512-byte hdwr sectors (251000 MB) SCSI device sda: drive cache: write back SCSI device sda: 490234752 512-byte hdwr sectors (251000 MB) SCSI device sda: drive cache: write back sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 sda8 sda9 > sd 0:0:0:0: Attached scsi disk sda I'll recompile against 2.6.15.2, and re-apply the patch and set libata into debug mode... (also increasing the buffer to 4mb so I can get everything..) and get back with something more verbose... - vin
btw, is it "options sata_via atapi_enabled=1" or "options libata atapi_enabled=1" that I should add to my modprobe.conf? ... Anyway, I'm building the kernel built-in at the moment so it's not a big deal. - vin
Created attachment 7239 [details] Kernel output from serial port 2.6.15.2- ata2 0xa0 timeout - Boot OK I either get a time out, a kernel panic or a some sort of kernel infinite looping... Here is a scenario where it seemed to boot fine but still got a time out... I should note that in deblug mode it tends to hang more often (kernel panic) than without debug mode... I'm using at the moment a 2.6.15.1, sata built-in, patched and until now it always booted fine, with a time out on ata2... - vin
I don't know if it's the same bug, but I am unable to get the following hardware working: Pioneer DVR-109BLK DVD writer Plextor 40/12/40A CD writer connected via 2x ACARD AEC-7900A SATA-to-IDE converters, to the following on-board SATA controller: RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) The dmesg output following loading libata with atapi_enabled=1 and then sata_via, is: [4553436.014000] libata version 1.20 loaded. [4553443.709000] sata_via 0000:00:0f.0: version 1.1 [4553443.709000] ACPI: PCI Interrupt 0000:00:0f.0[B] -> Link [ALKA] -> GSI 20 (level, low) -> IRQ 16 [4553443.709000] sata_via 0000:00:0f.0: routed to hard irq line 0 [4553443.709000] ata1: SATA max UDMA/133 cmd 0x9800 ctl 0x9C02 bmdma 0xA800 irq 16 [4553443.709000] ata2: SATA max UDMA/133 cmd 0xA000 ctl 0xA402 bmdma 0xA808 irq 16 [4553450.954000] ata1 is slow to respond, please be patient [4553473.925000] ata1 failed to respond (30 secs) [4553473.925000] scsi6 : sata_via [4553481.177000] ata2 is slow to respond, please be patient [4553504.153000] ata2 failed to respond (30 secs) [4553504.153000] scsi7 : sata_via and that is it. I have sr_mod loaded (USB DVD writer is mountable), but neither of these 2 drives show. This happens every boot and apart from taking a long time to start, there are no other effects.
I've compiled 2.6.15.3 and made sure sata_via was in modules instead of built-in... Also applied the patch to keep has much has possible the same environment has built-in... After quite a few reboots (about 20 !!! and the proper line in the modprobe.conf to enable ATAPI) I can tell that I still get the exact same problem which is either a timeout, BLIST_INQUIRY_36 + kernel panic, a detection + a kernel panic and once a detection without a kernel panic (but after trying to access my dvdr the dmesg output kept saying device error or device too slow and finally a call to cdrecord -scanbus made my pc freeze). Seems that PIO mode setting is not the trouble maker... so it might be that something is wrong with sata_via ATAPI command handling? or since INQUIRY succeed sometimes the problem could be in the INQUIRY ? - vin
Hello, Vincent. Yeap, I don't think the PIO thing is the issue. I was suspecting maybe something's wrong with the SATA-PATA bridge in 716sa or something but it was long shot in the first place. At this point, it seems like ATAPI packet command issueing doens't work on sata_via. I'm trying to contact via to get more information but other than that I'm pretty much lost. Thanks for all your effort.
If you need the exact model of my chipset and the BIOS revision of the onboard sata controler I can give it to you .... when I'll get back home!... Although it's a A8V Deluxe motherboard... and they did not updated the bios of the sata controler which is at version 2.01 if I remember correctly... (since it's built-in ASUS told me that it was impossible to update the sata bios although MSI seemed to do it on an equivalent mobo has told in their bios changelog?)
Any news from via?
Sorry, haven't heard anything from via. Will try again.
Any news? ... If none, how can we proceed to resolve this bug? Is there any way to "reverse engeneer" the ATAPI used in this VIA chipset?
Created attachment 7577 [details] A 2.6.16-rc6 kernel panic I just tought it was worth sending this picture of my latest SATA-via ATAPI kernel panic... Using 2.6.16-rc6 I now get two BUG: messages appearing instead of one. - vin
I just gave a try at 2.6.17-rc0-git14 since there is a big libata update and that ATAPI is enabled by default... It looks better... I did got the BLIST_INQUIRY_36 warning but it automatically waited 30secs and tried a second time and I finally got a time out.. best of all... my PC did not crashed (at least, not on that warning, maybie it will when it will get detected?). SCSI subsystem initialized libata version 1.20 loaded. sata_via 0000:00:0f.0: version 1.1 ACPI: PCI Interrupt 0000:00:0f.0[B] -> GSI 20 (level, low) -> IRQ 16 PCI: Via IRQ fixup for 0000:00:0f.0, from 10 to 0 sata_via 0000:00:0f.0: routed to hard irq line 0 ata1: SATA max UDMA/133 cmd 0xD000 ctl 0xC802 bmdma 0xB800 irq 16 ata2: SATA max UDMA/133 cmd 0xC400 ctl 0xC002 bmdma 0xB808 irq 16 ata1: SATA link up 1.5 Gbps (SStatus 113) ata1: dev 0 cfg 49:2f00 82:7c6b 83:7f09 84:4673 85:7c69 86:3e01 87:4663 88:407f ata1: dev 0 ATA-7, max UDMA/133, 490234752 sectors: LBA48 ata1: dev 0 configured for UDMA/133 scsi0 : sata_via ata2: SATA link up 1.5 Gbps (SStatus 113) ata2: dev 0 cfg 49:0f00 82:0000 83:0000 84:0000 85:0000 86:0000 87:0000 88:001f ata2: dev 0 ATAPI, max UDMA/66 ata2(0): applying bridge limits ata2: dev 0 configured for UDMA/66 scsi1 : sata_via Vendor: ATA Model: Maxtor 6B250S0 Rev: BANC Type: Direct-Access ANSI SCSI revision: 05 SCSI device sda: 490234752 512-byte hdwr sectors (251000 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: drive cache: write back SCSI device sda: 490234752 512-byte hdwr sectors (251000 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: drive cache: write back sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 sda8 sda9 > sd 0:0:0:0: Attached scsi disk sda ata2: command 0xa0 timeout, stat 0xd0 host_stat 0x1 ata2: translated ATA stat/err 0xd0/00 to SCSI SK/ASC/ASCQ 0xb/47/00 scsi scan: 96 byte inquiry failed. Consider BLIST_INQUIRY_36 for this device ata2 is slow to respond, please be patient ata2 failed to respond (30 secs) ata2: command 0xa0 timeout, stat 0xd0 host_stat 0x0 ata2: translated ATA stat/err 0xd0/00 to SCSI SK/ASC/ASCQ 0xb/47/00 sata_promise 0000:00:08.0: version 1.04 GSI 17 sharing vector 0xB1 and IRQ 17 ACPI: PCI Interrupt 0000:00:08.0[A] -> GSI 18 (level, low) -> IRQ 17 ata3: SATA max UDMA/133 cmd 0xFFFFC20000004200 ctl 0xFFFFC20000004238 bmdma 0x0 irq 17 ata4: SATA max UDMA/133 cmd 0xFFFFC20000004280 ctl 0xFFFFC200000042B8 bmdma 0x0 irq 17 ata3: SATA link down (SStatus 0) scsi2 : sata_promise ata4: SATA link down (SStatus 0) scsi3 : sata_promise
Created attachment 7700 [details] dmesg of 2.6.17-rc0-git13-x86_64 when detecting the drive This my dmesg output... It detected the DVD drive then it failed to respond (30 secs) then: ata2 is slow to respond, please be patient ata2 failed to respond (30 secs) BUG: warning at drivers/scsi/libata-core.c:3303/ata_pio_complete() Call Trace: <ffffffff88031bd0>{:libata:ata_pio_task+1398} <ffffffff810298cf>{__wake_up+56} <ffffffff81219b3a>{_spin_unlock_irqrestore+11} <ffffffff8803165a>{:libata:ata_pio_task+0} <ffffffff8103f2ed>{run_workqueue+159} <ffffffff8103fcd0>{worker_thread+0} <ffffffff8104265f>{keventd_create_kthread+0} <ffffffff8103fdd9>{worker_thread+265} <ffffffff8102880b>{default_wake_function+0} <ffffffff8104265f>{keventd_create_kthread+0} <ffffffff8104265f>{keventd_create_kthread+0} <ffffffff81042964>{kthread+212} <ffffffff8100a7a6>{child_rip+8} <ffffffff8104265f>{keventd_create_kthread+0} <ffffffff81218504>{thread_return+0} <ffffffff81042890>{kthread+0} <ffffffff8100a79e>{child_rip+0} One again, my PC did not crashed (I'm actually running it at the moment)... which is quite a good start. - vin
This bug is finally resolved!!! Use patch: Patch: http://www.kernel.org/pub/linux/kernel/people/jgarzik/libata/2.6.17-rc4-git2-libata1.patch.bz2 (patch posted on lklm) I've been able to burn my first DVD yesterday night and it is working like a charm! Theses patches will be included in 2.6.18 so I think we should wait till then before marking it has closed! thnx Jeff!
Are you forcing DMA off to get the burning to work? Things burn quickly and apparantly successfully for me, but I keep getting shiny decorations instead of working CDs.
I have a K8T800 chipset under a ASUS A8V deluxe motherboard. I also hear that irqbalance service caused troubles since the chipset is not yet well supported... Give a try at stopping irqbalance service. - vin
Don't have a daemon by that name running.
Under Fedora Core 5 it's called irqbalance located into /etc/init.d/irqbalance I don't know what it's called under other distro although it exists on ubuntu: http://packages.ubuntulinux.org/dapper/utils/irqbalance Daemon to balance irq's across multiple CPUs on systems with the 2.4 or 2.6 kernel. This can lead to better performance and IO balance on SMP systems. Useful mostly just for 2.4 kernels, or 2.6 kernels with CONFIG_IRQBALANCE turned off. Also note that there might be a independent patch sent to 2.6.17 just for this specific sata_via bug instead of having to wait for 2.6.18... Wait and see. Hope this helps!
Just got included into 2.6.17-rc4-git13 ... And it works! closing!.. thnx jeff, Tejun Heo and Albert Lee for resolving this!