Bug 128962 - eth1394 loaded instead of via-rhine
|
Bug#:
128962
|
Product: Gentoo Release Media
|
Version: 2006.0
|
Platform: x86
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: minor
|
Priority: P4
|
|
Resolution: FIXED
|
Assigned To: release@gentoo.org
|
Reported By: pascal.bodin@free.fr
|
|
Component: Everything
|
|
|
URL:
|
|
Summary: eth1394 loaded instead of via-rhine
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2006-04-05 13:57 0000
|
With LiveCD 2006.0, for a VIA EPIA ME6000 mother board, the boot sequence loads
the eth1394 module instead of via-rhine module, for the network. This prevents
the network from being configured correctly later on, with net-setup eth0 (in
my configuration, the network cable is plugged into the ethernet connector,
there is nothing connected to the firewire connector).
Workaround :
modprobe -r eth1394
modprobe via-rhine
Ehh... both should have been loaded, as the CD checks eth0 through eth1. Are
you sure you aren't connected on another ethernet interface? Also, by LiveCD
you mean the Installer LiveCD, correct?
I guess that's the Installer LiveCD. The file name of the ISO image is :
install-x86-minimal-2006.0.iso.
I have one ethernet interface only.
OK, so you aren't using the LiveCD, but the InstallCD... no problem...
Now, I understand that you have one *physical* interface, but how many are you
seeing when running "ifconfig -a | grep eth" ?
ifconfig just after boot returns eth1 and lo. A few seconds later, it returns
only lo. Then, ifconfig -a returns eth0 (with Link encap: UNSPEC and HWaddr
quite long (16 bytes)), eth1 (with Link encap : Ethernet and HWaddr 6
byte-long), and lo.
So it appears that the physical ethernet interface is mapped to eth1. If I
perform a net-setup on eth1, network works OK (I can ping an internet site
name). So, the only point is perhaps to add a few lines to documentation, to
explain that such a configuration may happen ?
Greg: do you have a problem with us adding "eth1394" to the hotplug blacklist
by default? We've gotten quite a few reports of this problem, and the eth1394
stuff is more of a special case for a network device.
No objection from me, blacklist away.
While you are at it, you might want to also add the shpchp driver to the list,
as almost no one has that device...
OK... I've added a new revision of hotplug that adds these two to blacklist.
I'm leaving this open until we get a new release out with this in it.
Woah, the blacklist in the hotplug package isn't going to help out much,
now that udev does the module loading :(
This needs to go into the module config file package instead.
Are you sure this is the best way? I haven't read any other reports on this
"problem", but if they all refer to the interface being eth1 instead of eth0 I
have to admit I can't see how that is a problem. It seems to me that the docu
should simply be updated to tell people to not just look at eth0 but look at
all interfaces?
Just my 2 cents :)
Honestly, the documentation covers it pretty well. Nowhere does it tell you
that your ethernet will necessarily be eth0, you (and others) simply assumed
that. However, I think the best solution would be to resolve the problem from
happening in the first place, as anyone using eth1394 for network connectivity
will have to do manual steps anyway, since it is point-to-point. I still plan
on having documentaion updates done, so we're solving this on multiple fronts.
*** Bug 132774 has been marked as a duplicate of this bug. ***
*** Bug 132775 has been marked as a duplicate of this bug. ***
This should be fixed on 2006.1, as we're still using udev 089.
Seems like you also need to add
blacklist eth1394
to /etc/modprobe.conf (or to whatever raw material this is generated from) in
order to prevent eth1394 to be loaded by hotplug. I don't know though if this
is relevant in the context of the installer CDs.
BTW, the _real_ fix is to allow linux/drivers/ieee1394 to be compiled without
the IP-over-1394 ROM entry and have this entry added by eth1394 itself when it
is loaded manually. I'll look into this eventually.
I proposed a patch for upstream Linux 2.6.22-rc which lets eth1394 behave like
most people would expect: Loading ohci1394 will not automatically load eth1394
per hotplug anymore. (With one exception: If there is already an external
IP-over-1394 capable device connected, the ieee1394 core will still trigger a
respective hotplug event.)
Patch is located at http://bugzilla.kernel.org/show_bug.cgi?id=7793 or
http://lkml.org/lkml/2007/3/26/298 .
Will, nevertheless it will be fixed at some time in the kernel, I added
"blacklist eth1394" to udev-110.
Upstream bug http://bugzilla.kernel.org/show_bug.cgi?id=7793 was closed, fix
went into mainline for 2.6.22-rc1.
Note, after that fix ieee1394 will still generate a hotplug event to let
userspace load eth1394 if it detects an external IP-over-1394 capable device.