Hide Forgot
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.
Could you please give "dmesg" output for both the xen and non-xen kernels? Thanks.
Created attachment 139993 [details] kernel messages from .fc6 boot lines containing named grepped out for privacy
Created attachment 139994 [details] kernel messages from .xenfc6 boot lines containing named grepped out for privacy
- 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.
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.
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.)
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.