Unsolved
This post is more than 5 years old
34 Posts
0
42727
December 19th, 2003 17:00
Broadcom 5700 / tg3 vs bcm5700 driver and kernel upgrades -
I have a question for our collective Linux wizardry. The Dell 2650s and 1750s have a known problem with the tg3 driver supplied with RedHat 9, sometimes locking up (we had one lockup on one lightly loaded box in the 3 1/2 months we ran it with the tg3 driver.)
Updated drivers from Broadcom (bcm5700.o) fix the problem without any further workarounds, and I have installed them on all my 2650s and the new 1750s. Here's the rub: The install procedure is do make, make install, and then edit modules.conf to point the interfaces to "bcm5700" instead of "tg3". This works fine, but there are problems looming if a kernel upgrade is done in the future.
I presume the driver built on an old kernel would not work on a new kernel (particulary since the next upgrade one does is likely to be to 2.6). The up2date kernel upgrade process does not remake or migrate the bcm5700 driver.
So, if one were to upgrade the kernel and not downgrade the modules.conf file back to the tg3 driver, or if one forgot to rebuild the driver, the newly-upgraded system would not fully boot.
Currently is the best alternative to document this and not forget to downgrade the modules.conf to tg3 before a kernel upgrade, upgrade, reboot, then rebuild the driver, and reboot again?
Or is one of the following better:
- Are future (post 2.4.20-24.9 and 2.6.XXX) kernel rpms going to include a fixed tg3 or better yet a bcm5700 driver?
- Is there a way to "kudzuify" the driver so and entry does not have to be made in modules.conf?
For now I am going to put a message in the motd so no one on my team forgets and upgrades the kernel without backing out to tg3.
-w
Updated drivers from Broadcom (bcm5700.o) fix the problem without any further workarounds, and I have installed them on all my 2650s and the new 1750s. Here's the rub: The install procedure is do make, make install, and then edit modules.conf to point the interfaces to "bcm5700" instead of "tg3". This works fine, but there are problems looming if a kernel upgrade is done in the future.
I presume the driver built on an old kernel would not work on a new kernel (particulary since the next upgrade one does is likely to be to 2.6). The up2date kernel upgrade process does not remake or migrate the bcm5700 driver.
So, if one were to upgrade the kernel and not downgrade the modules.conf file back to the tg3 driver, or if one forgot to rebuild the driver, the newly-upgraded system would not fully boot.
Currently is the best alternative to document this and not forget to downgrade the modules.conf to tg3 before a kernel upgrade, upgrade, reboot, then rebuild the driver, and reboot again?
Or is one of the following better:
- Are future (post 2.4.20-24.9 and 2.6.XXX) kernel rpms going to include a fixed tg3 or better yet a bcm5700 driver?
- Is there a way to "kudzuify" the driver so and entry does not have to be made in modules.conf?
For now I am going to put a message in the motd so no one on my team forgets and upgrades the kernel without backing out to tg3.
-w
No Events found!
Eric BY
2 Intern
•
815 Posts
0
December 19th, 2003 21:00
I would recommend commenting out the bcm5700 driver from the modules.conf file prior to installing the new kernel, then once booted into the newer kernel, compile and install the new driver, uncomment the bcm5700 driver in the modules.conf file and update the initrd.
I do realize that the bcm5700 driver may not have anything to do with the initrd, but the bourne shell script used to create the initrd (mkinitrd) does read the /etc/modules.conf file and if any modules listed in there are not in the new kernel, it may not create the initrd at all. I see this all the time with qla2300_6x, and updated megaraid 2x series drivers all the time.
wsanders
34 Posts
0
January 12th, 2004 20:00
We've got a couple non-production 1750s installed and we're leaving the tg3 on them that's in the latest RH9 up2date kernel (2.4.20-28.9). We'll see how they do.
Vi6
2 Posts
0
February 5th, 2004 17:00
Could you say anything about new kernel 2.4.21-9.EL in RHEL 3.0 and tg3 kernel module. Has it already fixed ?
Vi6
2 Posts
0
February 5th, 2004 18:00
http://lwn.net/Alerts/66615/
---
Bug IDs fixed:
...
106004 - Broadcom tg3 driver duplex won't set
...
---
Eric BY
2 Intern
•
815 Posts
0
February 17th, 2004 00:00
When ever you plan to upgrade your kernel you have to consider what additional drivers or modules you installed that are not provided by the Red Hat Kernel. Any of these drivers should be disabled or reconfigured into the new kernel before booting into that new kernel. Dell is taking strides to improve this functionality with DKMS (Dynamic Kernel Module Support).
Also unless there is a reason you are sticking with RHEL 2.1, you may want to consider moving up to RHEL 3. Dell currently supports RHEL 3 w/o the SAN. Just as soon as EMC validates Powerpath 3.05 for RHEL 3 and the Qlogic 6.07 driver, we plan to have have the SAN option with RHEL 3 also.
With RHEL 3, the bonding driver will be the way to team your NIC's together. While this is also an option for RHEL 2.1, it is rather tricky to configure. You can read up on the kernel documention if you want to try this out for teaming your nics together.
greymatter
2 Posts
0
February 17th, 2004 00:00
greymatter
2 Posts
0
February 17th, 2004 01:00
this is a production server and the upgrade to 3 would be highly dissruptive to my customers. I need to seek an alternative to that. the fact that the box is remote to my current location how am i supposed to upgrade the kernel without dropping the NIC? if i ran up2date to upgrade the kernel, would i be able to configure the NIC before the reboot to so that upon reboot the basp team and bcm5700 would start correctly?
Thanks,
Todd Smetanka
greymatter hosting
wsanders
34 Posts
0
July 20th, 2004 16:00
YOUR MILEAGE MAY VARY!