Re: How to get rid of sungem at boot time?
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.
Reply to: