On Mon, 2005-10-17 at 08:54 +1000, Benjamin Herrenschmidt wrote:
...
> > 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 settin
On Mon, 2005-10-17 at 08:54 +1000, Benjamin Herrenschmidt wrote:
> > I've done tests this afternoon, and what I found is that the devices
> > change that the system "sees" from one reboot to another. Specifically
> > it is this device on a Titanium IV that the system knows about in one
> > instance
On Thu, 2005-10-20 at 16:33 -0600, Spuhler, Peter wrote:
> 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 sometime
On Thu, 2005-10-20 at 16:33 -0600, Spuhler, Peter wrote:
> 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 sometime
periencing 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
> "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
Hi Ben
Hi All
On Mon, Oct 17, 2005 at 08:54:00AM +1000, Benjamin Herrenschmidt wrote:
>
> > I've done tests this afternoon, and what I found is that the devices
> > change that the system "sees" from one reboot to another. Specifically
> > it is this device on a Titanium IV that the system knows
On 17/10/2005 at 08:54 +1000, Benjamin Herrenschmidt wrote:
> 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 ?
I use something like this in a couple of multihomed servers:
http
> I've done tests this afternoon, and what I found is that the devices
> change that the system "sees" from one reboot to another. Specifically
> it is this device on a Titanium IV that the system knows about in one
> instance, that it does not know about any more at another reboot:
>
> # ifconfi
On Sun, Oct 16, 2005 at 07:36:27PM +0200, Wolfgang Pfeiffer wrote:
[ ... ]
>
> With the device above seen by the system having set the orinoco card in
> the /etc/network/interfaces file to eth2 everything is fine: The access
> point will be recognised at boot-up, and WLAN is worki
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:
>
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 10/13/05, Dean Hamstead <[EMAIL PROTECTED]> wrote:
> > 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.
>
> this is
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.
this is a good argument for bsd style network interfaces
/dev/vr0 /dev/fxp0 /d
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:
>
Benjamin Herrenschmidt wrote:
> 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 :)
On Thu, 2005-10-13 at 09:57 +1000, Benjamin Herrenschmidt wrote:
> 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 t
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 aut
Hi All
2.6.12, TitaniumIV, unstable.
This Debian boot system seems to be obsessed to find my ethernet crap
at boot time: I want to load my airport drivers, and only those, at
boot time, and not the ethernet crap, and I set
/etc/network/interfaces
accordingly:
Excerpt:
__
On Sun, 08 Aug 2004 the mental interface of
Derrik Pates told:
> Elimar Riesebieter wrote:
> >dmesg -n1 is doing the job. But isn't it possible to put that option
> >to an initscript other than rcboot.local? man syslogd doesn`t show
> >an equal solution.
>
> man klogd
I've put
KLOGD="-c 6"
in
Elimar Riesebieter wrote:
dmesg -n1 is doing the job. But isn't it possible to put that option
to an initscript other than rcboot.local? man syslogd doesn`t show
an equal solution.
man klogd
--
Derrik Pates
[EMAIL PROTECTED]
On Sun, 08 Aug 2004 the mental interface of
Michel Dänzer told:
> On Sun, 2004-08-08 at 18:18 +0200, Elimar Riesebieter wrote:
> > of printing out "adt746x: Stopping CPU fan." and "Setting speed to:
> > 0 for CPU fan." to console. In therm_adt746x.c these messages are
> > done as a KERN_INFO. My s
On Sun, 2004-08-08 at 18:18 +0200, Elimar Riesebieter wrote:
> of printing out "adt746x: Stopping CPU fan." and "Setting speed to:
> 0 for CPU fan." to console. In therm_adt746x.c these messages are
> done as a KERN_INFO. My syslog.conf tells all
> kern.* /var/log/kern.log and not to console.
of printing out "adt746x: Stopping CPU fan." and "Setting speed to:
0 for CPU fan." to console. In therm_adt746x.c these messages are
done as a KERN_INFO. My syslog.conf tells all
kern.* /var/log/kern.log and not to console.
Any hints?
Elimar
--
"Talking much about oneself can also
b
Hi,
to get rid of this modem garbage use this
init script for the modem:
ATZM0L0
or if you want to save it in your modem
use minicom and enter:
ATZ
ATM0L0
AT&W
this disables the "garbage" and saves it to the modem.
Afterwards you can use ATZ with all applications again.
It should also survive
25 matches
Mail list logo
