Description of problem: Odd messages showing up in dmesg: eth0: freeing mc frame. ifconfig shows: eth0 Link encap:Ethernet HWaddr 00:D0:B7:81:CB:A8 inet addr:66.93.168.238 Bcast:66.93.168.255 Mask:255.255.255.224 inet6 addr: fe80::2d0:b7ff:fe81:cba8/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:931 errors:0 dropped:0 overruns:0 frame:0 TX packets:270 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:59502 (58.1 KiB) TX bytes:295047 (288.1 KiB) Interrupt:5 lspci shows: 02:04.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] (rev 05) Version-Release number of selected component (if applicable): kernel-2.6.14-1.1696_FC5 How reproducible: Occuring at about 1 per sec Steps to Reproduce: 1. dmesg 2. 3. Actual results: eth0: freeing mc frame. Expected results: Additional info:
Stopping avahi-daemon stops the messages.
Please try using the e100 driver instead of the eepro100. Edit /etc/modprobe.conf and change all references to "eepro100" to reference "e100" instead. Please give that a try and post the results...thanks!
There were no references to eepro100 that I could find. It alread had "alias eth0 e100" in /etc/modprobe.conf I can't recreate the problem today, with or without avahi-daemon running. kernel-2.6.14-1.1729_FC5 avahi-0.6-2 iptables-1.3.4-2
CORRECTION I *can* recreate the problem today with the packages. (I was checking /var/log/messages instead of dmesg. I should read my own bug reports! ) With avahi-daemon running, dmesg is getting "eth0: freeing mc frame" messages. With avahi-daemon stopped, the dmesg messages stop. There are no relevant messages in /var/log/messages.
Very strange...the text for "freeing mc frame" is only in the eepro100 driver, not the e100 driver. Please attach the output from running sysreport...thanks!
Created attachment 121720 [details] output of sysreport sysreport generated with avahi-daemon running
Your lsmod output shows that you are loading both the eepro100 and e100 drivers. It would appear that eepro100 is loading first and claiming the hardware. Unfortunately, I don't see anything else in the sysreport that explains to me how/why eepro100 is getting loaded at all. The e100 driver should work with your hardware. Can you find-out how/why eepro100 is getting loaded on your box? If nothing else, please attach the output of this command: find /etc -type f -exec grep -l eepro100 {} \; You might also try this (as root): mv /lib/modules/`uname -r`/kernel/drivers/net/eepro100.ko /root Hopefully that will prevent eepro100 from loading... :-) Thanks!
You might try this is an a nicer alternative to the 'mv' command above: echo eepro100 >> /etc/hotplug/blacklist Please try that and reboot, and post the results here...thanks!
find /etc -type f -exec grep -l eepro100 {} \; returned nothing. echo eepro100 >> /etc/hotplug/blacklist and rebooting didn't prevent eepro100 from being loaded !!! lsmod shows both e100 and eepro100 as loaded. Is it significant that the two interfaces are on a single PCI card? I have: alias eth0 e100 alias eth1 e100 in /etc/modprobe.conf . Is it possible that this file is being ignored in favor of /etc/modprobe.d/modprobe.conf.dist ? I tried: mv /lib/modules/`uname -r`/kernel/drivers/net/eepro100.ko /root reboot and that worked: eepro100 module not loaded, starting avahi-daemon doesn't produce error messages in dmesg. But this is just hiding the problem under the rug. I have other systems that are also loading both drivers for no apparent reason.
I've put back the module so that I can test. Adding: alias eth0 e100 alias eth1 e100 to /etc/modprobe.d/modprobe.conf.dist and the rebooting did not fix the problem.
I tried rmmod eepro100 and I've lost remote access to the system, so I won't be able to test further until I get home this afternoon. I was wondering if the eepro100 module was getting installed via mkinitrd and just getting carried through from one version of the kernel to the next. I was going to: rmmod eepro100 mkinitrd ..... then reboot to see if that avoided reloading it. I'll try the experiment later unless you have other ideas.
Hmm, we could probably just disable the EEPRO100 driver for fc5. The only thing it does that e100 doesn't afaik is work on some wierdo ARM platform which we don't build for in Fedora anyway.
Its being loaded by mkinitrd but not getting carried forward that way. With the eepro100.ko file in out of the way I rebooted the system so that only e100 was loaded. Then I did a mkinitrd and then put eepro100.ko back in its normal place. The I rebooted and lsmod showed no eepro100 loaded. I then upgraded to kernel-2.6.14-1.1735_FC5 and rebooted and the eepro100 module was loaded again. There are lots of references to eepro100 in /lib/modules/2.6.14-1.1735_FC5/module* so my guess is that /sbin/depmod is not creating the right module dependencies during kernel installs.
I'm kinda leaning towards Dave's suggestion from comment 12... Dave, do you want a patch?
I've just disabled eepro100 in the config. After this, everything should just pick up the e100 driver and 'just work'. hwdata already has the eepro100 -> e100 migration, so upgrades should be fine. Adding Bill to cc as a sanity check :-)
Should work fine to remove it.