On Thu, 2005-10-13 at 00:12 +0200, Wolfgang Pfeiffer wrote: > So anyone knows which app/config at boot time might be responsible for > loading the sungem stuff? > I already completely removed discover to fix this:
sungem is your built-in ethernet. It show up on the PCI bus, thus hotplug will automatically load the driver. Besides, it's a good thing anyway as the sungem driver will deal with power management of the chip even when you are not using it, for example, for sleep mode. It's just a wrong way of thinking that you should remove drivers for HW you do not use in fact :) The problem here is assuming any kind of stability of the ethX numbers. This can't work. Ever. You need some other ways of identifying your interfaces. I don't know if debian network configure scripts provide any such thing though. > apt-get remove discover1-data discover1 libdiscover1 > > but to no avail so far ... > > Where are these apps/files that load this ethernet crap? Hal, udev, > hotplug? It's not crap, it's your ethernet interface and the drivers should be loaded :) And yes, it's probably hotplug. > I already grepped the whole /etc/ area for the "eth" pattern and > such, but nothing so far ... > > And sure, I know I can blacklist sungem altogether somewhere in > /etc/hotplug .. But I think it's brain-dead to firstly let some > routine/script try loading a driver I don't want, Bla bla bla bla.. > and then remove it > again via the hotplug stuff. That's why I'm looking for this boot > routine that's obsessed by the idea to load sungem ... Because you have the hw, so it loads the driver, period. > Just in case: No, sungem is not loaded via /etc/modules. > > Ah yes, nearly forgot that: Loading my airport card manually after > booting works like charm, after unloading the airport > etc./sungem(_phy) drivers. So it seems it's simply a lousy boot time > set up being responsible for the mess .... airport isn't (yet) auto-detected by hotplug (soon). When that will happen, your airport driver will also be automagically loaded and there is no way to know which one will end up eth0 and which one will end up eth1. > Again: My primary target is to get *sensibly* rid of sungem and > sungem_phy being loaded at boot time. I'm sure if you put your machine on the floor, then jump on it several times until it splits in at least 3 or 4 pieces, sungem will no longer be loaded at boot time. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
