banzaikai
10-28-2007, 09:11 AM
(or, "How do I get my hardware working?")
At the request of saikee, I'm posting this to help out all the newbies with a problem that's been popping up more often in our distros. It affects video, audio, network, and wireless cards, and it goes something like this...
You've just installed Linux, and everything works. Except your "gotta-have-it-working-or-my-dog'll-get-shot" card. Bummer. So, you come here to these forums to get some help, but the things we have you check all seem to indicate that everything's working. Confused? You bet we are! After helping out with a couple of these, I finally figured out what is happening in a majority of cases: Misidentified hardware/modules.
What happens at installation is the installer (Anaconda on Fedora) will look for and ID your hardware, then look through a hardware database to find out which module (driver) to load for it. In most cases, the kernel will have some built-in modules for standard items to keep the extra modules to a minimum. If developers were to keep all the old modules while adding all the new ones that are needed, we'd have a kernel as big as... well... Vista's!
So, to help keep things small, they just use the ID method of determining the proper module. This means that one little typo or error in the database (or "chip change" on the card) results in the wrong module loading. It may be the fault of the developer, or just a production change at the manufacturing plant. For that matter, I wish manufacturers would change chip suppliers less often, or use another (easier) way of letting everyone know there's been a chip change. Then, instead of loading up a useless module, it'd just fail to modprobe. I feel it's better to have a non-loading module than a loaded module that doesn't work - poor newbies see the module loaded, but can't get the hardware going, so they assume they (or Linux) really suck at installing things.
Now, if one knows that the correct module was loaded with an earlier distro or Live CD (like Knoppix), then it's a simple matter to just:
{old_distro} -> /sbin/lspci #see what the heck you've got in there
{old_distro} -> /sbin/lsmod #check for module loaded and working
{new_distro} -> /sbin/lsmod #check for module loaded and not working
{new_distro} -> /sbin/rmmod module_name #get rid of bad module
{new_distro} -> /sbin/modprobe old_module_name #load up module from old distro's list
For a real-world example, let's pretend that the card uses a Rhine chipset, and it was mistaken for an "ep100". So, in a shell/terminal window, we'll type (in red):
[banzai@blossom ~]$ /sbin/lspci
00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74)
So, our card's ID shows a VIA Rhine. Good. Now, we'll peek at what module is loading:
[banzai@blossom ~]$ /sbin/lsmod
ep100 31361 0
Most newbies will think this is normal, but we know better. So, to correct this oversight, we switch over to root (su) to issue some commands (note that any user can look, but only root can change things) :
[banzai@blossom ~]$ su #super user power... activate!
Password:
[root@blossom banzai]# /sbin/rmmod ep100 #get rid of that bad boy
[root@blossom banzai]# /sbin/modprobe via_rhine #load up the correct one
[root@blossom banzai]# exit #we're done, back to user mode
[banzai@blossom ~]$ #user mode shows the dollar sign ($)
I've helped out with this problem a couple of times, and it seems to happen to Fedora and Ubuntu distros more often than others (perhaps because these distros tend to update releases more often, hence, more chance of an error sneaking through).
The other problem is that you look at your card (say, a WPC-54G), and see that it has four or five different versions, each one meaning they used a different chipset. So now you're off to figure out which chipset went with what version. You quickly get an appreciation for what the developers have to go through. A handy trick is to use Google and search using keywords like "linux wpc-54G ver 4" to get the right chipset and module.
For Newbies:
lsmod = LiSt MODules
lspci = LiSt PCI devices (usually includes AGP/PCIe as well)
modprobe = MODule PROBE for matching hardware, and load if found
rmmod = ReMove MODule
/sbin/ = System BINaries (directory where these commands should be sitting)
su = Super User (root) mode (newer shells use "exit" to, well, exit to regular user
Newer distros allow you to do this using a GUI interface for networking (in Fedora, it's "System -> Administration -> Network"). Instead of typing things in, you just click on tabs and add/remove things as neccessary (like Windows). However, the GUI typically doesn't let you force a module to be loaded, as it'll just re-probe and find the bad database entry once again, and you're back to square one.
banzai "square one" kai
At the request of saikee, I'm posting this to help out all the newbies with a problem that's been popping up more often in our distros. It affects video, audio, network, and wireless cards, and it goes something like this...
You've just installed Linux, and everything works. Except your "gotta-have-it-working-or-my-dog'll-get-shot" card. Bummer. So, you come here to these forums to get some help, but the things we have you check all seem to indicate that everything's working. Confused? You bet we are! After helping out with a couple of these, I finally figured out what is happening in a majority of cases: Misidentified hardware/modules.
What happens at installation is the installer (Anaconda on Fedora) will look for and ID your hardware, then look through a hardware database to find out which module (driver) to load for it. In most cases, the kernel will have some built-in modules for standard items to keep the extra modules to a minimum. If developers were to keep all the old modules while adding all the new ones that are needed, we'd have a kernel as big as... well... Vista's!
So, to help keep things small, they just use the ID method of determining the proper module. This means that one little typo or error in the database (or "chip change" on the card) results in the wrong module loading. It may be the fault of the developer, or just a production change at the manufacturing plant. For that matter, I wish manufacturers would change chip suppliers less often, or use another (easier) way of letting everyone know there's been a chip change. Then, instead of loading up a useless module, it'd just fail to modprobe. I feel it's better to have a non-loading module than a loaded module that doesn't work - poor newbies see the module loaded, but can't get the hardware going, so they assume they (or Linux) really suck at installing things.
Now, if one knows that the correct module was loaded with an earlier distro or Live CD (like Knoppix), then it's a simple matter to just:
{old_distro} -> /sbin/lspci #see what the heck you've got in there
{old_distro} -> /sbin/lsmod #check for module loaded and working
{new_distro} -> /sbin/lsmod #check for module loaded and not working
{new_distro} -> /sbin/rmmod module_name #get rid of bad module
{new_distro} -> /sbin/modprobe old_module_name #load up module from old distro's list
For a real-world example, let's pretend that the card uses a Rhine chipset, and it was mistaken for an "ep100". So, in a shell/terminal window, we'll type (in red):
[banzai@blossom ~]$ /sbin/lspci
00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74)
So, our card's ID shows a VIA Rhine. Good. Now, we'll peek at what module is loading:
[banzai@blossom ~]$ /sbin/lsmod
ep100 31361 0
Most newbies will think this is normal, but we know better. So, to correct this oversight, we switch over to root (su) to issue some commands (note that any user can look, but only root can change things) :
[banzai@blossom ~]$ su #super user power... activate!
Password:
[root@blossom banzai]# /sbin/rmmod ep100 #get rid of that bad boy
[root@blossom banzai]# /sbin/modprobe via_rhine #load up the correct one
[root@blossom banzai]# exit #we're done, back to user mode
[banzai@blossom ~]$ #user mode shows the dollar sign ($)
I've helped out with this problem a couple of times, and it seems to happen to Fedora and Ubuntu distros more often than others (perhaps because these distros tend to update releases more often, hence, more chance of an error sneaking through).
The other problem is that you look at your card (say, a WPC-54G), and see that it has four or five different versions, each one meaning they used a different chipset. So now you're off to figure out which chipset went with what version. You quickly get an appreciation for what the developers have to go through. A handy trick is to use Google and search using keywords like "linux wpc-54G ver 4" to get the right chipset and module.
For Newbies:
lsmod = LiSt MODules
lspci = LiSt PCI devices (usually includes AGP/PCIe as well)
modprobe = MODule PROBE for matching hardware, and load if found
rmmod = ReMove MODule
/sbin/ = System BINaries (directory where these commands should be sitting)
su = Super User (root) mode (newer shells use "exit" to, well, exit to regular user
Newer distros allow you to do this using a GUI interface for networking (in Fedora, it's "System -> Administration -> Network"). Instead of typing things in, you just click on tabs and add/remove things as neccessary (like Windows). However, the GUI typically doesn't let you force a module to be loaded, as it'll just re-probe and find the bad database entry once again, and you're back to square one.
banzai "square one" kai