Re: How to get rid of sungem at boot time?
Hi Ben
Hi All
First this: Removing sungem(_phy) at boot time helps getting airport
up (more in the test report #1 at the end of this mail) And yes, I
believe you, Ben, when you write it's no good to remove these drivers .. :)
On Thu, Oct 13, 2005 at 09:57:00AM +1000, Benjamin Herrenschmidt wrote:
> 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 :)
Thanks for letting me know. That's new for me.
>
> 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..
[ ... ]
... OK. Given your lessons above. ... :)
> > 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).
Oh. Again thanks for letting me know. So this makes the errors look
logic for me ...
> 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.
[ ... ]
OK. I'll try that. But before I'll send you the results from playing
with sungem/airport settings :) .. :
3 little tests:
1:
removing
sungem
sungem_phy
via /etc/hotplug/blacklist
and then loading airport at boot time set to eth1 via
/etc/network/interfaces
results in a working airport driver: I checked that success via the
'iwconfig' output and by actually and successfully connecting to www
with the radio card - tested it with about 3 reboots of the machine ..
2:
But if a do the same as above, but instead set the radio card to eth0
instead of eth1 airport doesn't work. I didn't even make it to my
wireless router with orinoco.
Tested that with 2 reboots
3:
2 reboots with these settings/results:
doing the same as in #1 (eth1) but instead load the the
sungem
sungem_phy
drivers results in no radio connection, not even until the wireless router.
I told the system via /etc/network/interfaces to map eth1 to airport
but instead I got this
# ifconfig
eth1 Link encap:Ethernet HWaddr [ deleted ]
[deleted]
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:1465 errors:0 dropped:0 overruns:0 frame:0
TX packets:1465 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:411186 (401.5 KiB) TX bytes:411186 (401.5 KiB)
[the lo output above slightly varied from reboot 1 to reboot 2 in the RX
packets, TX packets etc sections ..]
# iwconfig
lo no wireless extensions.
eth0 no wireless extensions.
eth1 no wireless extensions.
sit0 no wireless extensions.
eth2 IEEE 802.11-DS ESSID:"" Nickname:"HERMES I"
Mode:Managed Frequency:2.422 GHz Access Point: 00:00:00:00:00:00
Bit Rate:11 Mb/s Tx-Power=15 dBm Sensitivity:1/3
Retry limit:4 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Now things become complicated a bit: eth1, that I thought I set via
the interfaces file to orinoco, is seen by the system as an ethernet
card, as it seems, set to the characteristics of the radio card via
the interfaces file, which can't work, as it seems. If you have a
look at the ifconfig line from above:
eth1 Link encap:Ethernet HWaddr [ deleted ]
The deleted HW address for the ethernet card (eth1) actually was for
security reasons meant and set as a fake address in the interfaces
file for the radio card. In the /etc/network/interfaces line is a line
like
hwaddress ether [deleted]
The system simply set these airport characteristics to the ethernet
card ... :)
And radio eth2 has the correct HW address as shipped by Apple, as it
seems:
$ macchanger -s eth2
Current MAC: 00:30:65:28:e4:78 [wireless] (Apple Airport Card 2002)
Can't help but sometimes even bugs are funny .... :)
So the system sees the radio-card as the radio-card, sets it to eth2,
but does no set the options from the interfaces file to it.
I'm really not sure whether all this helps, but who knows ...
Best Regards
And Thanks for the lessons, Ben.
Wolfgang
--
Wolfgang Pfeiffer
http://profiles.yahoo.com/wolfgangpfeiffer
Key ID: E3037113
Key fingerprint = A8CA 9D8C 54C4 4CC1 0B26 AA3C 9108 FB42 E303 7113
Reply to: