I have finally gotten permission from Realtek to submit the new driver to the
staging directory of the mainline kernel. This also means that I can allow users
to download from the git source repository so that they can build their own
versions. If you are interested in doing this, you will need to install some
packages. To get the ones you need,
sudo zypper in gcc make git-core qt3-devel
Once these packages are loaded, then get a copy of the source:
That linux-r8712 at the end is the directory that will be created to hold the
source tree. You should change it to whatever you want. After that command
finishes, change to that directory and do the following:
zcat /proc/config.gz > .config
If the make step fails because of missing packages, resolve them. Once the
configuration screen comes up, navigate to the “Staging drivers” section of the
left panel, and in the right panel deselect the items for RTL8192 and select
RTL8712U. Save the new configuration and do the following:
If you have more than one CPU, add “-jN” to the command where N is one more than
the number of CPUs. After that finishes without error (it will take a while), then
sudo make modules_install install
When that command finishes, you will have new options in the GRUB menu. Boot the
one that has 2.6.36 in its name. The new driver has the firmware built in, thus
you will not have to worry about it.
Let me know how it goes. The git tree is up to date with the Linux-2.6 mainline
tree, which now has kernel 2.6.36-rc3.
OK I did all this - and personally it’s quite a hassle, I had to download over 500Mb worth of stuff, which is difficult without an internet connection! Anyway I did all this and got the new kernel entry in GRUB but it just says waiting for /dev/sda1 to appear and just fails to boot the OS.
Is there not an easy way I can just compile the module for my current kernel and insmod it? I don’t like the idea of using a RC kernel especially since I’m not a linux expert.
On 08/31/2010 03:06 PM, rash m wrote:
> OK I did all this - and personally it’s quite a hassle, I had to
> download over 500Mb worth of stuff, which is difficult without an
> internet connection! Anyway I did all this and got the new kernel entry
> in GRUB but it just says waiting for /dev/sda1 to appear and just fails
> to boot the OS.
You did not get the kernel configuration done correctly, and the driver for your
disk is not available. I never said it would be easy.
> Is there not an easy way I can just compile the module for my current
> kernel and insmod it? I don’t like the idea of using a RC kernel
> especially since I’m not a linux expert.
That would require me to backport the driver to 2.6.34 after I just put in 3
months of work getting it cleaned up and running with the mainline kernel. I
have no interest in that, thank you. I made the URL available so that this
driver would be available before openSUSE 11.4. No one is forcing you to use it.
You can go to the Realtek web site, find the RTL8192SU driver and build it. As
long as you are running a 32-bit system, you will be OK, but it will crash any
64-bit system. You could also extract the sources from the kernel you
downloaded, copy them to the 2.6.34 tree, and modify the driver source for the
2.6.34 system features and the build system to accept them. That may be beyond
your skills as well.
Its not that I don’t appreciate the hard work you have put in, it’s just frustrating getting wireless to work in Linux. I had a bluenext wireless usb stick and I only had to copy the .bin file to lib/firmware and it worked, this is much more hard work.
How can I get it to work with my hard disk? Should it not automatically detect it? This is strange as its the first time I’ve had problems with Linux not detecting my SATA disk - I’ve had these issues with XP but never linux.
On 09/01/2010 07:06 AM, rash m wrote:
> Its not that I don’t appreciate the hard work you have put in, it’s just
> frustrating getting wireless to work in Linux. I had a bluenext wireless
> usb stick and I only had to copy the .bin file to lib/firmware and it
> worked, this is much more hard work.
Every device has these same growing pains, some are even worse as they have no
vendor support at all. See the Broadcom BCM43xx devices as an example.
> How can I get it to work with my hard disk? Should it not automatically
> detect it? This is strange as its the first time I’ve had problems with
> Linux not detecting my SATA disk - I’ve had these issues with XP but
> never linux.
Did you get any errors with the ‘sudo make install’ step? As long as you copied
the configuration from the running system with the ‘zcat /proc/config.gz >
…config’ step and did not try to eliminate any disk drivers during the
configuration step, it should just work. The only times that I have had such
boot failures is when I got too aggressive in trying to eliminate drivers for
devices I did not have so that the compile step would be quicker.
Unfortunately, I will be off-line after this posting for about 2 months. Good
luck, or buy a Netgear WG111V2 from Ebay. They do work right out of the box.
cost about $10, and require no external firmware. They have a Realtek RTL8187L chip.
Perfect, I have downloaded the rc3 kernel, patched bootsplash (at some point I am sure opensuse will change to splashy). and can confirm that the driver works with the Asus N10 USB module on 64 bit achitecture with no problems. Apparmour boot script fails but this is due to a version mismatch and will no doubt be fixed in 11.4 in the mean time I will hack that by hand.
It is very nice to have the driver as an entire module (no firmware to get mismatched), well done and thank you.
Your boot problem is probably due to an initrd related problem. I suggest after running the make install step running the script mkinitrd and seeing if this gives any errors. Also look in the module list to make sure the driver for your SATA controller is present. This is always a bit of a bugger to do. I am a self confessed idiot so if I can anyone can. It just takes patience… (I am an animal trainer so having infinite patience is in my job description, computers though, they require more patience sometimes than the most aggressive wolves, dogs or tigers).
Backports checked into repository driver:/wireless for openSUSE 11.2 and 11.3.
Driver packages are called “rtl8712u-kmp-$flavor”, decent test reports are welcome, any questions like “how do I install this?” or “which package do I need?” will be ignored (at least by me, if you don’t know how to do this, it is very unlikely you can give a decent test report later).
Use at your own risk, if these packages break your grandma’s leg, it’s not my fault.
Addendum for Larry (I know, this might take a while before getting an answer, but maybe you will read this):
Backporting was not really difficult on a “technical” point of view but on deciding if the patch is OK when it comes to functionality, meaning “can I disable this without destroying something vital to the driver”.
The only problem was the function “key_2char2num” in “usb_intf.c” and (depending on that) the module parameter “initmac”.
The function calls “hex_to_bin” which seems to have been added to mainline in 2.6.35.
Some googling around told me, that in most cases this function replaced cumstom implementations in the respective drivers, so I searched for this functionality in the vendor driver and didn’t find anything.
My conclusion was
you added this functionality to the driver, it is not implemented in the vendor driver
the functionality is nice but not vital to the driver as it “only” seems to enable setting a custom MAC-address on loading the module
it is safe to just remove this functionality for backporting the driver to 11.2/11.3, which I did
Can you confirm this?
The driver compiles without any “noise” on 11.2/11.3, so you did an outstanding job considering the state of this driver before you cleaned it up.
Installed the backported driver fine, but after re-booting caused an odd error during boot…
Could not recognize the EXT4 file system
The User is then dumped to the command line.
Rebooted again just to make sure with the same result.
I guess my next try might be to uninstall remove the new kernel modified by the new driver, then attempt to compile from source (original instructions in this thread)… My only thought might be how to delete/remove the new kernel before attempting the compile from scratch.
If no timely answer how to remove the new modified kernel, of course I made a backup ahead of time so I’d probably go ahead and do a restore…
Also, didn’t get fully the message during driver/kernel compilation the requested logfile and/or other essential data, can anyone re-post if I can’t get it without re-installing to a certain dead kernel?
The compiled driver “rtl8192se-kmp-desktop” seems to only support PCI cards (not consistent with the title of this thread), here is the driver description
rtl8192se-kmp-desktop - Linux driver for Realtek RTL8192SE PCI WiFi cards
rtl8192se-kmp-desktop - Linux driver for Realtek RTL8192SE PCI WiFi cards
This package contains a kernel module for Realtek RTL8192SE PCI “draft-N” WiFi cards.
The driver will be called “r8192se_pci.ko”, the follwong PCI-IDs are supported:
10ec:8171 10ec:8172 10ec:8173 10ec:8174
You really want to state installing a kmp-package broke your installation with THIS type of error message?
Are you kidding?
This error states it can not find a file system driver -most likely missing in the initrd or kernel configuration-, a kmp-package NEITHER changes the kernel configuration (otherwise one wouldn’t NEED an external kmp-package) NOR does it lead to changing anything at the initrd, so whatever you did to break your system, it has nothing to do with installing a kmp-package, especially a kmp-package from a totally different class of drivers.
And I would normally agree with you, but nothing else was done at all except to install the NIC RPM. The system was booted cold so could not have possibly retained anything from another procedure that I can think of, and no effort was made to compile anything else during that session.
I could test again after removing the newly created kernel that doesn’t work to verify but that would only be to test whether the situation is reproducible since I already know that the target NIC isn’t supported.
Is there a logfile created somewhere by the compilation that can be retrieved? Perhaps there’s an answer in there somewhere.
Well, insult me if you must but if you ignore what I’m getting then you can deal with the fallout later if anyone follows in my footsteps, even if I did something wrong.
I just re-produced the error <twice> on my machine.
During each session I methodically did the following:
Bootup with no Internet connection
Inspected Installation Summary to be certain nothing was pending
Using YAST configured with the repository source