Description of problem: We killed all the wacky device specific probing code that grokked around in OF for devices. Yay. Not all drivers have been properly converted to export OF aliases, however - so they don't get loaded on boot. Notable offenders: - snd-powermac - i2c-* - therm-* bmac and airport look OK, and are probably good starting places for grabbing code from. Version-Release number of selected component (if applicable): 2.6.15-1.1863_FC5
Things are still changing in this area... not all of them can be converted. snd-powermac is a nasty critter and needs complete rewrite, i2c is now a single i2c-powermac that matches on a platform device, not OF, I don't think we have anything to autoload these things... On the other hand, it could probably be built-in. Same with therm- ... the old pm72 is sort-of trying to match on OF using the fcu as an anchor, but the new windfarm stuff isn't... Platforn devices there too
Reassigning to kudzu according to comment #1. It's a fine goal, but please let's try it just _after_ FC5 release rather than just _before_ FC5 release.
Doesn't help. kudzu *is not used to load modules*. So there's nothing it can do. (Is this the first anyone has noticed - it's been this way since mid December...)
Ah, OK. For sound, I suspect it affects new installations rather than upgrades, because the latter will have it in /etc/modprobe.conf already, won't they? I did notice that snd_powermac wasn't detected in firstboot on a recent rawhide install; only my USB audio device was. But then after another reboot without selinux it _was_ present, and I didn't investigate further. I'll do so when I get home. We build the important (i.e. G5) thermal control stuff into the kernel now, because those modules weren't getting loaded. It would be nice to build those as a module too.
If it generates a sound-slot-0 kmod event it will manage to get loaded if it's in /etc/modprobe.conf, yes. New installs won't have that, though.
Out of curiosity, what of 'snd-powermac is a nasty critter and needs complete rewrite' makes it impossible to add a MODULE_DEVICE_TABLE with a OF alias? I assume the nasty parts are about how it actually runs, not how you'd detect it?
Re comment #6: I'm not sure -- I'll check. It may involve compiling a table of all the OF aliases on various different machines; I'm not sure how consistent Apple have been with it.
(In reply to comment #3) > (Is this the first anyone has noticed - it's been this way since mid December...) therm-* aren't obvious if they don't get loaded. In terms of snd-powermac, there were overlapping issues with gnome-volume-manager and problems with the driver itself. (In reply to comment #4) > because the latter will have it in /etc/modprobe.conf already, won't they? Doesn't work for me as mentioned in bug 178375. I don't know if there's another problem, though. My /etc/modeprobe.conf currently contains: alias snd-card-0 snd-powermac options sound-card-0 index=0 options snd-powermac index=0 remove snd-powermac { /usr/sbin/alsactl store 0 >/dev/null 2>&1 || : ; }; /sbin/modprobe -r --ignore-remove snd-powermac
*** Bug 183095 has been marked as a duplicate of this bug. ***
*** Bug 186353 has been marked as a duplicate of this bug. ***
*** Bug 176761 has been marked as a duplicate of this bug. ***
*** Bug 186544 has been marked as a duplicate of this bug. ***
I have tried the following quick-fix: Add the following line to "/etc/sysconfig/modules/udev-stw.modules": /sbin/modprobe snd-powermac I assume the module is being loaded now, but FC-5 still does not detect a sound device on my system. I have a stock G5 single tower (PowerMac 9.1) Here is the listed hardware in OS X: Built In Sound Card: Devices: Burr Brown PCM3052: Inputs and Outputs: Line Level Input: Controls: Mute, Master Playthrough: No PluginID: Onyx Headphones: Controls: Mute, Left, Right PluginID: Onyx Internal Speakers: Controls: Mute, Master PluginID: Onyx Line Level Output: Controls: Mute, Left, Right PluginID: Onyx Crystal Semiconductor CS84xx: Inputs and Outputs: S/PDIF Digital Output: Controls: Mute PluginID: Topaz Formats: PCM 16: Bit Depth: 16 Bit Width: 16 Channels: 2 Mixable: Yes Sample Rates: 32 KHz, 44.1 KHz, 48 KHz, 64 KHz, 88.2 KHz, 96 KHz PCM 24: Bit Depth: 24 Bit Width: 32 Channels: 2 Mixable: Yes Sample Rates: 32 KHz, 44.1 KHz, 48 KHz, 64 KHz, 88.2 KHz, 96 KHz AC3 16: Bit Depth: 16 Bit Width: 16 Channels: 2 Mixable: No Sample Rates: 32 KHz, 44.1 KHz, 48 KHz, 64 KHz, 88.2 KHz, 96 KHz Built In Sound Card: Devices: Crystal Semiconductor CS84xx: Inputs and Outputs: S/PDIF Digital Input: Controls: Mute Playthrough: No PluginID: Topaz Formats: PCM 16: Bit Depth: 16 Bit Width: 16 Channels: 2 Mixable: Yes Sample Rates: 32 KHz, 44.1 KHz, 48 KHz, 64 KHz, 88.2 KHz, 96 KHz PCM 24: Bit Depth: 24 Bit Width: 32 Channels: 2 Mixable: Yes Sample Rates: 32 KHz, 44.1 KHz, 48 KHz, 64 KHz, 88.2 KHz, 96 KHz AC3 16: Bit Depth: 16 Bit Width: 16 Channels: 2 Mixable: No Sample Rates: 32 KHz, 44.1 KHz, 48 KHz, 64 KHz, 88.2 KHz, 96 KHz
Brian, (In reply to comment #14) > I assume the module is being loaded now, but FC-5 still does not detect a > sound device on my system. I have a stock G5 single tower (PowerMac 9.1) I think you can stop searching for now. AFAIK your model is simply not supported by snd-powermac. Someone is currently working on a replacement: http://lists.debian.org/debian-powerpc/2006/03/msg00423.html
*** Bug 187709 has been marked as a duplicate of this bug. ***
*** Bug 189075 has been marked as a duplicate of this bug. ***
Rawhide fixes some of the symptoms, but perhaps the real issue is not yet fixed (see bug title?) At least, snd-powermac is loaded automatically now. From udev's RPM changelog: * Thu Apr 13 2006 Harald Hoyer <harald> - 089-1 - version 089 - do not force loading of parport_pc (bug #186850) - manually load snd-powermac (bug #176761) - added usb floppy symlink (bug #185171) - start_udev uses udevtrigger now instead of udevst
*** Bug 190312 has been marked as a duplicate of this bug. ***
A new kernel update has been released (Version: 2.6.18-1.2200.fc5) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. In the last few updates, some users upgrading from FC4->FC5 have reported that installing a kernel update has left their systems unbootable. If you have been affected by this problem please check you only have one version of device-mapper & lvm2 installed. See bug 207474 for further details. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. If this bug has been fixed, but you are now experiencing a different problem, please file a separate bug for the new problem. Thank you.
This bug is still valid. Situation on my PowerBook5,6 with devel: Sound modules are working. If it's the mentioned manual loading of snd-powermac through udev (see comment #18), or the new snd-aoa driver behaving correctly -- I don't know. Funnily enough, both of them are getting loaded. But sound works though. therm-adt746x definitly isn't automatically loaded. Not sure about the remaining i2c-* stuff as i2c-powermac is built-in.
As this is all likely to get fixed in rawhide first, and backported later, I'll reassign for now to get it off the constant "did it get fixed yet" hit list. We should aim to get at least the more common devices auto-loading again in FC7, so adding to blocker. This needs to be owned by someone with some familiarity with this hardware however, so reassigning to dwmw2, my usual ppc victim :)
Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
This bug has been in NEEDINFO for more than 30 days since feedback was first requested. As a result we are closing it. If you can reproduce this bug in the future against a maintained Fedora version please feel free to reopen it against that version. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp