ELRepo Bugtracker

Viewing Issue Simple Details Jump to Notes ] << ] >> ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0000072 [channel: elrepo/el5] kmod-atl1e minor unable to reproduce 2010-07-28 03:19 2010-08-17 08:43
Reporter ohw0571 View Status public  
Assigned To burakkucat
Priority normal Resolution no change required  
Status resolved  
Summary 0000072: kmod-atl1e stops working after today's CentOS5 updates
Description After applying the recent CentOS5 updates (mostly glibc related), the kmod-atl1e driver has stopped working in one of our machines (there is no similar config available for testing). The eth0 interface is listed as inactivated, and cannot be re-activated ("has a different MAC address than expected").
Reverting to the old kmod-atl1c (which has been superceded by kmod-atl1e) brought the nic back to life, and updating to kmod-atl1e did not do any harm either.
My guess is that something has gone wrong with the driver during the glibc updates.
Additional Information
Tags No tags attached.
Attached Files

- Relationships

-  Notes
(0000322)
burakkucat (administrator)
2010-07-28 06:23

If I understand your situation:

An up to date EL5.5 system.
Using the currently available kmod-atl1e package.
Updated the glibc package -- atl1e driver stops working.
Re-installed the kmod-atl1e package -- atl1e driver now works again.

Have I summarised the situation correctly?

If that is the case, I suspect that a system shutdown, followed by a cold system boot would have resolved the "different MAC address than expected" issue.

I am surprised that a glibc update has brought this on and a careful watch should be kept for any other issues arising since that glibc package update.
(0000323)
ohw0571 (reporter)
2010-07-28 06:57

Yes, that is exactly our situation.
Well, of course we did a reboot after the glibc update, but not a shutdown/cold boot.
No further issues so far; other kmod packages seem to work as expected.
(0000324)
burakkucat (administrator)
2010-07-28 07:44

My feeling is that the glibc update has caused a re-init of udev and that has got confused with regard to the NIC MAC address. Udev has then attempted to perform its "magic" and resulted in different parameters being assigned to the NIC.

I think that this is going to have to be put done as an artefact of the glibc update and not a driver bug.

Let's keep that system carefully monitored for the next few days.
(0000337)
burakkucat (administrator)
2010-08-17 08:42

Issue arose as a result of an incorrect update process. Now resolved.

- Issue History
Date Modified Username Field Change
2010-07-28 03:19 ohw0571 New Issue
2010-07-28 03:19 ohw0571 Status new => assigned
2010-07-28 03:19 ohw0571 Assigned To => burakkucat
2010-07-28 06:23 burakkucat Note Added: 0000322
2010-07-28 06:24 burakkucat Status assigned => feedback
2010-07-28 06:57 ohw0571 Note Added: 0000323
2010-07-28 07:44 burakkucat Note Added: 0000324
2010-07-28 07:44 burakkucat Status feedback => assigned
2010-08-17 08:42 burakkucat Note Added: 0000337
2010-08-17 08:43 burakkucat Status assigned => resolved
2010-08-17 08:43 burakkucat Resolution open => no change required


Mantis 1.1.8[^]
Copyright © 2000 - 2009 Mantis Group
Powered by Mantis Bugtracker