[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
> 



Reply to: