With the current rawhide kernel (2.6.19-2913.fc7), my G5 PowerMac locks up hard (does not respond to keypresses, no sysrq, etc) after about a minute of uptime. The following messages appear just before it locks: ide-pmac lost interrupt, dma status: 8400 hda lost interrupt hda is the DVD drive. Interestingly this does not happen during the installation. Maybe this is triggered by HAL poking at optical drives?
Confirmed - if I start the system in interactive mode and skip hal, it doesn't lock up. Once HAL gets started, it locks the system soom after hald-probe-storage starts. I might add that this works fine in FC6, both the original release and with current updates.
Hm, I've seen something on my laptop which may be related -- I think it's only when the CD drive is empty though, and it doesn't actually die. This is FC6 userspace but rawhide kernel. It happens with the 2.6.19-1.2914 kernel but I don't _think_ it was happening with a slightly earlier kernel (2913?). Will double-check that when I get home and post actual dmesg output. It's possible that I had never actually run 2913 without a disc in the drive. It would be really good to do a pata_pmac driver before F7 proper, so that we can finally turn off CONFIG_IDE in Fedora.
Well pata_pmac would be a bad model, ide/ppc/pmac is about 8 drivers and some supporting code all mushed into a horrible mess. You'd want a libata-pmac akin to libata-sff, and some small clean drivers for the chips one per chip type. Good project for someone with a macintoy
On the powerbook (with 2.6.19-1.2914) it started like this, while the machine was idle and the drive was empty: Jan 31 19:18:33 shinybook kernel: hdc: irq timeout: status=0xc0 { Busy } Jan 31 19:18:33 shinybook kernel: ide: failed opcode was: unknown Jan 31 19:18:38 shinybook kernel: hdc: status timeout: status=0xc0 { Busy } Jan 31 19:18:38 shinybook kernel: ide: failed opcode was: unknown Jan 31 19:18:38 shinybook kernel: hdc: drive not ready for command Jan 31 19:18:43 shinybook kernel: hdc: status timeout: status=0xc0 { Busy } Jan 31 19:18:43 shinybook kernel: ide: failed opcode was: unknown Jan 31 19:18:43 shinybook kernel: hdc: drive not ready for command I've never seen this before on the powerbook, and it stopped happening when I put a disc in the drive... Feb 1 07:07:52 shinybook kernel: hdc: status timeout: status=0xc0 { Busy } Feb 1 07:07:52 shinybook kernel: ide: failed opcode was: unknown Feb 1 07:07:52 shinybook kernel: hdc: drive not ready for command Feb 1 07:07:53 shinybook gnome-power-manager: (dwmw2) Screen resume because idl e mode ended Feb 1 07:08:12 shinybook hald: mounted /dev/hdc on behalf of uid 500
telinit 3 kill off all the hal stuff see if the box then behaves
I'm beginning to suspect that the error on the shinybook was a one-off and not related; I cannot reproduce it, although I have other interesting breakage in post-2913 kernels which I'll investigate separately. I cannot reproduce on a G5 because userspace is non-functional -- as described in bug 226956. Will, did you see this on an FC6 install with newer kernel or is this a relatively recent installer breakage?
Hm, otoh hald-addon-storage _is_ running for /dev/hda on the G5 in question, so if it's going to happen I probably ought to see it. On an iMac G5 where userspace _is_ fully functional because it's upgraded from FC6 by yum, I don't see the problem. Precisely what machine are you seeing this on?
This is a dual 2.0GHz Power Mac G5. Still locks up in current rawhide, but passing 'hda=noprobe' keeps the machine alive.
I'm seeing similar CD drive weirdness. After inserting an audio CD, I start getting lots of messages like so: Apr 21 17:14:09 monolith kernel: ide: failed opcode was: unknown Apr 21 17:14:09 monolith kernel: hda: drive not ready for command Apr 21 17:14:09 monolith kernel: status error: status=0x58 { DriveReady Seek Complete DataRequest } ... After this, the drive does not want to eject or anything so if I want to get my CD back, I have to reboot. Kernel version was kernel-2.6.20-1.3094.fc7.ppc64. Haven't tried anything later than that yet.
Seems to be fixed in current rawhide. Chris, you can reopen the bug if it's not working for you.