Just to verify Ben's experience with this, I have been recently experiencing the same problem as described by Ben with my NIC switching between eth0 and eth1 randomly during startup probably due to the firewire network driver sometimes being loaded before the sungem one. I'm also experiencing problems with udev and my keyboard no longer working with the newer kernels.
-----Original Message----- From: Benjamin Herrenschmidt [mailto:[EMAIL PROTECTED] Sent: Thursday, October 20, 2005 4:16 PM To: Wolfgang Pfeiffer Cc: debian-powerpc Subject: Re: How to get rid of sungem at boot time? > "Ethernet-over-firewire": If you mean the firewire connector/system on > the machine by that: Yes, there is a kernel module that implements ethernet-like networking on top of FireWire. > And what if it's a hardware bug? In that the firewire system on the > machine has, e.g. a loose contact to the rest of the machine. In that case > even the best kernel/drivers would not be able to detect some firewire > system, with some eth0 device called > 00-03-93-FF-FE-CD-E4-C4-00-00-00-00-00-00-00-00 ... :) Well, in that case it would have a lose contact on all macs including mine :) No, I think the problem is with that damn driver that randomly don't work. > A few hours ago I remembered again the times when I connected a hard disk > via firewire to the Titanium, and I had problems to let kernel drivers > detect the partitions of that disk ... I think the linux firewire stack is fairly broken, but you can complain on their mailing list. > So perhaps we're a bit too much a accustomed to blame Linux if > something does not work ... or at least in my case that might be true > ... :) > > > > > > If the eth0 device above is missing at another system boot the whole > > > devices order is shifting, and changed, and as a consequence > > > previous eth2 (radio card) simply does not exist any more, thus > > > rendering my settings in the /etc/network/interfaces useless ... :) > > > > The solution would be to able to specify interfaces by MAC or position > > in sysfs rather than ethX name in /etc/network/interfaces... Volunteer > > to fix those scripts ? > > > > With sysfs you mean the scripts in the kernel source tree below > /fs/sysfs, is this correct? If that's true: I don't even understand > to *read* those scripts ... Sorry ... > > > My workaround, so far: > > After system boot, if the radio card couldn't connect to the access > point, I firstly shut down the networking system (on Debian/unstable) > completely with that little script: > > ------------------------------------ > #!/bin/sh -x > > echo "Stopping networking .. " && \ > > /etc/init.d/portmap stop && \ > /etc/init.d/dnsmasq stop && \ > /etc/init.d/networking stop && \ > /etc/init.d/ifupdown stop && \ > /etc/init.d/dns-clean stop && \ > > echo "OK: Network is down" > --------------------------------- > > After that I make sure the wireless drivers are removed (not being > sure whether this is OK ... :) > > ------------------------------------- > #!/bin/sh -x > /bin/sh -n /home/shorty/scripts/removeairport.sh && \ > rmmod airport && \ > rmmod orinoco && \ > rmmod hermes > --------------------------------------- > > Then with a 'ifconfig -a', 'iwconfig' or 'macchanger -s <device>' I > try to see which names my system gave to which devices. So if it > thinks that eth2 is my wireless card I change /etc/network/interfaces > file accordingly. > > Following that I try to restart my networking system with that script: > > -------------------------- > #!/bin/sh > > echo "Bringing up networking ..." && \ > > /etc/init.d/dns-clean start && \ > /etc/init.d/ifupdown start && \ > /etc/init.d/networking start && \ > /etc/init.d/dnsmasq start && \ > /etc/init.d/portmap start && \ > echo "OK: Network is up and running" > ------------------------------------ > > Too much work? ... :) > > All of you, be careful please: I'd bet there are mistakes in the > scripts above. Don't just use them, but please try to find out what > they do instead. > > My idea behind it simply was to clone the Debian boot/shutdown system > as to what it does when starting/stopping networking .... These > scripts work rather well here since quite some time, IIRC, (provided I > do not try to establish a WLAN connection to my AP when its wireless > system is switched off, as it happened to me this afternoon ... :) but > something that works does not necessarily mean it's right ... > > At any rate: HTH > > Best Regards > Wolfgang > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
