Booting vmlinuz-2.6.24.4-64.fc8, it gets stuck on: ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x2 frozen over and over. I can't boot. However, vmlinuz-2.6.23.14-107.fc8 boots nicely. No problems booting! This is on a Dell Inspiron 530s (bought last XMAS for $300).
The ICH9R SATA RAID controller might be configurable several different ways in the BIOS setup. Can it be set to AHCI if it is not already set that way? Can you attach the file /var/log/dmesg after booting the latest working kernel?
I can only set the controller to "IDE" (the default for the Dell) or "RAID" in the BIOS. No "AHCI". Attaching the dmesg.
Created attachment 300377 [details] /var/log/dmesg
Created attachment 301755 [details] dmesg generated from Dell E520, BIOS 2.4.0, kernel 2.6.24.4-64
I also have a Dell, an E520. While I don't have any particular problem booting, the version of K3B currently in F8 (1.0.4-5) gives the kernel (2.6.24.4-64) *fits* when it tries to detect the burners: Apr 8 21:17:15 dell kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen It bangs on ata2 until it gets disabled: Apr 8 21:18:51 dell kernel: ata2.00: disabled Then it moves on to ata6: Apr 8 21:38:11 dell kernel: ata6.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen With ultimately the same result: Apr 8 21:39:46 dell kernel: ata6.00: disabled Downgrading to F7's K3B (1.0-1) makes things quieter, but it eventually screws up again. I haven't tried to actually *burn* anything with it... I can't get that far because the ports keep getting disabled. dmesg is attached (before my comments, sorry about that, new to bugzilla).
I may not be able to burn using K3B, but burning with Nautilus works just fine (it's using growisofs at the moment). For what it's worth, anyway...
I get the same error messages. Here's what I know is needed to reproduce them: 1) module pata_amd 2) running haldaemon Somehow, between the two of them, it causes the DVD drive to spew these error messages. If I shut down the haldaemon, eventually it gets to a point where the kernel says nobody's using pata_amd... I then modprobe -r pata_amd, modprobe pata_amd, and I can access the drive just fine... but if I restart haldaemon, *zap* Currently running kernel 2.6.25.6-27.fc8 on an i686 with KDE as the desktop.
Try running the command 'hal-disable-polling'
Yes, that disables the error messages... but it doesn't necessarily resolve the underlying issue. I should mention that I'm running on a Core 2 Duo as well.
Has this been fixed in Fedora 10? I haven't tried Fedora 9... would prefer to go directly to 10.
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
See Bug 465838. This appears to be the same thing.
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.