Bug 213376 - ethernet driver module problem w/8139 chip set
Summary: ethernet driver module problem w/8139 chip set
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel-xen
Version: 6
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Xen Maintainance List
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-11-01 07:16 UTC by Sam Azer
Modified: 2008-08-02 23:40 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2007-05-06 16:30:16 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
kernel messages from .fc6 boot (39.81 KB, text/plain)
2006-11-01 15:33 UTC, Sam Azer
no flags Details
kernel messages from .xenfc6 boot (39.36 KB, text/plain)
2006-11-01 15:33 UTC, Sam Azer
no flags Details

Description Sam Azer 2006-11-01 07:16:18 UTC
Description of problem:

If I boot into the non-xen OS, everything works great: eth0 is connected to my
local subnet, eth1 is connected to my external subnet. No problems.

If I boot into the xen os (2.6.18-1.2798.fc6xen) the system detects an 8139 chip
set, loads the 8139cp module, then decides to load the 8139too module instead.
Both modules remain in memory and neither are working. The system boots and
operates normally except that there is no external network. See the excerpt from
the message log in "additional information" below.

Version-Release number of selected component (if applicable):

Linux dev 2.6.18-1.2798.fc6xen #1 SMP Mon Oct 16 15:11:19 EDT 2006 i686 i686
i386 GNU/Linux

How reproducible:

always / every boot

Steps to Reproduce:
1.Boot the xen FC6 os
2.
3.
  
Actual results:

* eth1 not working.
* 8139cp and 8139too modules both appear on lsmod | grep 8139

Expected results:

* eth1 should be working
* only 8139too module should be loaded

Additional info:

After booting: eth0 is up but using the e100 driver, eth1 is not visible to
ifconfig (can't bring it up or down,) and both the 8139cp and 8139too drivers
are found on lsmod | grep 8139. 

Work Around:

rmmod 8139cp
rmmod 8139too
modprobe 8139too

(After doing the above: eth1 is properly configured and functional, external
network is accessible.)

from /var/log/messages:

8139cp: 10/100 PCI Ethernet driver v1.2 (Mar 22, 2004)
8139cp 0000:01:00.0: This (id 10ec:8139 rev 10) is not an 8139C+ compatible chip
8139cp 0000:01:00.0: Try the "8139too" driver instead.
8139too Fast Ethernet driver 0.9.27
ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 21 (level, low) -> IRQ 21
eth0: RealTek RTL8139 at 0xee07ec00, 00:40:f4:2b:49:fa, IRQ 21
eth0:  Identified 8139 chip type 'RTL-8139C'
hdd: ATAPI 40X DVD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
e100: Intel(R) PRO/100 Network Driver, 3.5.10-k2-NAPI
e100: Copyright(c) 1999-2005 Intel Corporation
ACPI: PCI Interrupt 0000:01:08.0[A] -> GSI 20 (level, low) -> IRQ 22
e100: eth1: e100_probe: addr 0xff8fe000, irq 22, MAC addr 00:11:11:0A:35:EF

Thank You.

Comment 1 Stephen Tweedie 2006-11-01 13:02:46 UTC
Could you please give "dmesg" output for both the xen and non-xen kernels?  Thanks.


Comment 2 Sam Azer 2006-11-01 15:33:04 UTC
Created attachment 139993 [details]
kernel messages from .fc6 boot

lines containing named grepped out for privacy

Comment 3 Sam Azer 2006-11-01 15:33:58 UTC
Created attachment 139994 [details]
kernel messages from .xenfc6 boot

lines containing named grepped out for privacy

Comment 4 Sam Azer 2006-11-01 15:46:37 UTC
- additional IPs (10.177.1.7 and 1.8) don't show in the xen boot because I
removed them after reviewing old bugzilla entries.

- samba is configured to listen to some VPN subnets that don't exist at boot time.

Thanks again.



Comment 5 Sam Azer 2006-12-10 01:57:25 UTC
This problem appeared recently when booting into the non-xen OS. This leads me
to think that perhaps this is related to the code that determines which network
driver to use at boot time. Something about the XEN boot process causes the bug
to appear consistently.

Thanks,
Sam.



Comment 6 Bill Nottingham 2006-12-11 20:13:47 UTC
I'm not seeing this in your posted messages - in both of them, the proper thing
happens - 8139cp loads, ignores the device. 8139too loads, initializes as eth0.
e100 loads, initializes as eth1.

Do you have the proper HWADDR in /etc/sysconfig/network-scripts/ifcfg-ethX? Do
you have a log from when it fails for you?

(kudzu has nothing to do with module loading, FWIW - pushing back to kernel.)

Comment 7 Sam Azer 2007-05-06 16:30:16 UTC
This problem no longer appears - I'm not sure why. I note that you mention eth0
and eth1 backwards in your last comment - so perhaps the HWADDR had something to
do with it. I did find it missing and added it at some point but never got
around to doing any more tests. Sorry for that and thanks again for your effort.


Note You need to log in before you can comment on or make changes to this bug.