Potential kernel modification to get reliable wifi
Forum: DSL Ideas and Suggestions
Topic: Potential kernel modification to get reliable wifi
started by: tempestuous
Posted by tempestuous on Jan. 12 2006,09:19
Forum member quirky recently made a post attributing the Ralink rt2500 driver's problems to the fact that DSL's kernel has SMP enabled.< http://damnsmalllinux.org/cgi-bin....t=10772 >
This is interesting. By disabling SMP in the kernel, would the numerous wifi problems with DSL2 reported on the forum be solved?
Anyone have any supporting information?
Posted by cbagger01 on Jan. 12 2006,18:13
Many of these reports also state that their wifi cards worked properly under DSL version 1.5DSL 1.5 uses the 2.4.26 smp enabled kernel.
So I doubt that disabling smp support will solve the specific problem that those people are observing.
But it MIGHT help some others out. I dunno.
Posted by roberts on Jan. 13 2006,07:01
Indeed it does appear that the atmelwlandriver requires a non-SMP kernel!There has been a report on the mailing list of big problems with an SMP kernel, which went away when a non-SMP kernel was used.
The latest readme from the stable sources now also indicates that a non-SMP kernel is required!
Posted by tempestuous on Jan. 13 2006,14:37
Ironically, these wifi drivers may work OK with DSL2+ on non-SMP-capable PC's (just a hunch) because this older hardware can't use SMP routines.Perhaps what we're seeing is a result of more people using DSL now on newer hardware?
Posted by quirky on Jan. 13 2006,18:58
I can confirm that the rt2500 driver causes a hang on my single CPU, non hyper-threaded CPU machine.EDIT: But after remastering the CD with a non SMP kernel, the same hardware and driver works as expected.
Posted by paku on Jan. 14 2006,07:59
How did you do it so you get the card function? I have the same problem with my Rt2500 card and cant use the Dsl. Its very harm because it a fine distro. Help,please.
Posted by quirky on Jan. 14 2006,13:36
You have to download the 2.4.31 kernel sources, and dsl.config, use dsl.config as .config, make menuconfig -> remove SMP, add APIC, apply the Knoppix kernel patch, remove the part that hard codes gcc-2.95. I used a seperate Ubuntu installation to build the actual kernel, gcc3.4, since that way I could use the make-kpkg tools.Then I more or less followed this guide:
< http://www.eng.uwaterloo.ca/twiki/bin/view/Linux/RemasteringGuide >
I had 2 remastering/source directories, one with dpkg reenabled so I could install the new kernel .deb, the other was the original nothing-added DSL. Installed the kernel.deb, the rt2500.o and cloop.o, in the chrooted, beefed up source directory. depmod'd to rebuild the modules dependency file. Then copied across the newly created /lib/modules/2.4.31 and /boot directory (Not sure the /boot dir is needed) to the original DSL source, (ie. not the one full of the restored dpkg stuff). I removed the lib/modules/2.4.31 directory from here first, to avoid potential kernel panics if it used the wrong module.
Then in the master/boot/isolinux dir, I changed the linux24 file for the new kernel. Loop mounted up minrt24.gz, replaced the cloop.o and scsi drivers, closed minirt24.gz again. Remastered the iso as per the guide.
Oh, I also copied across /etc/networks/interfaces from my Ubuntu distro, which is used to set up the card (security note - I have the WPA key stored on the CD... very secure! Not.).
It's not exactly a newbie friendly process and isn't too well documented "step by step". Also, once booted I have to type "sudo /etc/init.d/networking restart" to get the network going. This could possibly be overcome by added the appropriate link in rc.d before remastering, not sure.
Posted by paku on Jan. 14 2006,15:42
Thanks!I will try, i hope i can do all of that you explained. Little difficult....yes it is.
Posted by cbagger01 on Jan. 16 2006,05:31
But I still don't understand why it worked with DSL 1.5DSL 1.5 also has a SMP enabled kernel.
Posted by quirky on Jan. 16 2006,20:00
Well, does the latest cvs rt2500 driver work in DSL 1.5? If so, then the changes are probably related to changes made in the kernel between 2.4.26 and 2.4.31. I'm afraid I don't know exactly what the changes were, but I can guess that they made soft interrupts "more concurrent" and have uncovered deadlocks lurking in this driver.