Bug 468624
Summary: | 5000x chipset, cutting data DVD with K3b/growisofs causes kernel panic and trashes file system | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | Todd <ToddAndMargo> | ||||||
Component: | kernel | Assignee: | David Milburn <dmilburn> | ||||||
Status: | CLOSED DUPLICATE | QA Contact: | Red Hat Kernel QE team <kernel-qe> | ||||||
Severity: | high | Docs Contact: | |||||||
Priority: | medium | ||||||||
Version: | 5.2 | CC: | dzickus, pasteur | ||||||
Target Milestone: | rc | ||||||||
Target Release: | --- | ||||||||
Hardware: | i386 | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2009-02-19 15:09:39 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Todd
2008-10-26 21:12:59 UTC
Would you please attach dmesg output and "lspci -v"? Also, when you see the kernel panic do you see any specific libata routines on the stack trace? Thanks. Created attachment 321709 [details]
lspci -v > lspci.txt
Created attachment 321711 [details] dmesg > dmesg.txt > Also, when you see the kernel panic do you see any specific > libata routines on the stack trace? I apologize, but I do not know what a libata routine or a stack trace is. -T Looking at dmesg, you are using ata_piix driver, this is a low-level driver that is part of the linux sata subsystem (libata). Normally, a kernel panic will generate a stack trace showing where the kernel is actually crashing, in this case I would expect something like the following (Just an example). In this example we know that ata_sff_check_status was called right before the crash. Process insmod (pid: 776, threadinfo ffff81027f5ca000, task ffff810108fc17e0) Stack: ffffffff880c3330 0000000000000001 ffffffff880c3475 ffff810108cc4000 ffffffff880bec82 0000000000000282 ffffffff880bee80 0000000000000016 ffff810108cc4000 ffff81027fb5a9d8 ffffffff880b5eb9 ffff8104bf8f2400 Call Trace: [<ffffffff880c3330>] :libata:ata_sff_check_status+0x10/0x16 [<ffffffff880c3475>] :libata:ata_sff_freeze+0x3a/0x4c [<ffffffff880bec82>] :libata:__ata_port_freeze+0x52/0x58 [<ffffffff880bee80>] :libata:ata_eh_freeze_port+0x2b/0x40 [<ffffffff880b5eb9>] :libata:ata_host_start+0x10f/0x169 [<ffffffff880c28a6>] :libata:ata_pci_sff_activate_host+0x32/0x1c3 [<ffffffff880c5335>] :libata:ata_sff_interrupt+0x0/0x1c7 [<ffffffff802177ce>] pcibios_set_master+0x80/0x85 [<ffffffff880e9cd4>] :ata_piix:piix_init_one+0x66a/0x695 [<ffffffff80155b50>] pci_device_probe+0x104/0x184 [<ffffffff801b758c>] driver_probe_device+0x52/0xaa [<ffffffff801b76bb>] __driver_attach+0x65/0xb6 [<ffffffff801b7656>] __driver_attach+0x0/0xb6 [<ffffffff801b6ed5>] bus_for_each_dev+0x43/0x6e [<ffffffff801b6b1b>] bus_add_driver+0x7e/0x130 [<ffffffff80155d28>] __pci_register_driver+0x4b/0x6c [<ffffffff880f8017>] :ata_piix:piix_init+0x17/0x28 [<ffffffff800a4d15>] sys_init_module+0xaf/0x1e8 [<ffffffff8005d116>] system_call+0x7e/0x83 Do you have a system available to test on? A few things come to mind, from the link above, the chipset supports ahci mode, have you tried changing the sata controller settings in the bios? It would good to know if this is reproducible using ahci driver, as well as the ata_piix driver. If possible setting up a serial console may help catching a stack trace that shows where the kernel was at the time of the crash, I would expect to see the libata and ata_piix routines on the call trace. Also, we have a rhel5.3 beta test kernel which includes a significant update to the sata subsystem, if possible it would be good to know if it fails under the kernel-2.6.18-120.el5 test kernel http://people.redhat.com/dzickus/el5/120.el5/ Thanks. > Do you have a system available to test on?
Yes and no.
There is a 2 in 3 chance I will be spending an hour with fsck
There is a 1 in 3 chance my hard drive will be trashed and I loose
an entire day's billings (a lot on $).
There is an indeterminate chance something will go wrong with
my backups I will loose my entire livelihood. My life would be
very nearly ruined.
So, "yes" to non-destructive testing and "no" to destructive testing.
Is the fact I can burn data DVD's just fine with the Windows Deep Burner
under Wine any kind of clue? What does Wine do differently over K3b/
growisofs?
-T
I rebooted and checked my BIOS: Enhanced (NON-AHCI) mode: Sata and Pata drivers are autodetected and placed in native IDE mode. I was too chicken to change it. -T Ok, thanks for the info. I don't want to potentially trash your system, those suggestions were only if you had another test system, same configuration. I will see if I can find a system to reproduce the problem, it is possible that it is a timing related bug so you may not be hitting it when running the app under Wine. Todd, I am going to close this as a duplicate of BZ 446086, I was able to crash a system and verify the problem was no longer reproducible with the patch attached to BZ 446086, this was also confirmed by the reporter of that bug. *** This bug has been marked as a duplicate of bug 446086 *** |