On 05/02/2010 11:56 AM, twelveeighty wrote:
>
> I bought a Toshiba A500 two days ago (was in a rush, my old A200 had a
> catastrophic failure) and the wireless doesn’t work.
>
> I have two network related devices listed with lspci:
>
>
> Code:
> --------------------
>
> 07:00.0 Network controller: Realtek Semiconductor Co., Ltd. Device 8172 (rev 10)
> 0c:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03)
>
> --------------------
>
>
> lspci -n returns:
>
>
> Code:
> --------------------
>
> 07:00.0 0280: 10ec:8172 (rev 10)
> 0c:00.0 0200: 10ec:8168 (rev 03)
>
> --------------------
>
>
> When I check dmesg, I see entries related to “r8169 Gigabit Ethernet
> driver 2.3LK-NAPI loaded”, but nothing about a wireless adapter.
>
> iwconfig returns only my “wired” connections: lo, eth0 and vboxnet0.
>
> To my question: I found this article (‘HOWTO: Xplora E16 Ubuntu 9.04
> 32Bit and 64Bit with wired and wireless networking - Novatech Community
> Forums’ (http://forum.novatech.co.uk/showthread.php?t=15068)), which
> seems be consistent with my situation (wired connection works, wifi
> doesn’t and my kernel is 2.6.31). I ran the installation and it appears
> it worked…BUT, is this going to create major problems down the line
> (kernel upgrades, etc.?)
>
> Or is there a better way to get this WLAN to work?
As there are no drivers that handle a device with PCI ID 10ec:8172 in
the kernel, your solution is correct. There is a driver for the rtl8192e
in staging, but it is not clear that this is the same device.
As with any out-of-kernel driver, you will need to rebuild it whenever
the kernel changes. Just make sure that the kernel headers are updated
whenever the kernel is changed.
FWIW, the Realtek web site has a later version of this driver than is
newer than the one in the links you list.
OK - it seems I need a better or more recent version of this driver. I had installed it, it connected to a WAN, but then after 5 minutes my laptop hung completely: I had to hold down the power button to get it to shut off. When I checked /var/log/messages, I had a gazillion of the following line in there:
May 2 14:58:56 finrod kernel: 420.064657] ==========>HTSetConnectBwMode():pHTInfo->bCurBW40MHz:0
May 2 14:58:56 finrod kernel: 420.074710] =================>ieee80211_authentication_req():auth->algorithm is 0
May 2 14:58:56 finrod kernel: 420.076111] ===>rtl8192_SetWirelessMode(), wireless_mode:0x6, support_mode:0x16
May 2 14:58:56 finrod kernel: 420.076126] <===rtl8192_SetWirelessMode(), wireless_mode:4, bEnableHT = 0
May 2 14:58:56 finrod kernel: 420.078206] Association response status code 0x8a
May 2 14:58:56 finrod kernel: 420.078376] DMA: Out of SW-IOMMU space for 9100 bytes at device 0000:07:00.0
May 2 14:58:56 finrod kernel: 420.078394] ===>ieee80211_associate_procedure_wq(), chan:1
May 2 14:58:56 finrod kernel: 420.078399] ==========>HTSetConnectBwMode():pHTInfo->bCurBW40MHz:0
May 2 14:58:56 finrod kernel: 420.079307] DMA: Out of SW-IOMMU space for 9100 bytes at device 0000:07:00.0
May 2 14:58:56 finrod kernel: 420.088443] =================>ieee80211_authentication_req():auth->algorithm is 0
May 2 14:58:56 finrod kernel: 420.090565] ===>rtl8192_SetWirelessMode(), wireless_mode:0x6, support_mode:0x16
May 2 14:58:56 finrod kernel: 420.090581] <===rtl8192_SetWirelessMode(), wireless_mode:4, bEnableHT = 0
May 2 14:58:56 finrod kernel: 420.090746] DMA: Out of SW-IOMMU space for 9100 bytes at device 0000:07:00.0
May 2 14:58:56 finrod kernel: 420.092621] Association response status code 0x8a
(over and over again), until finally:
May 2 15:00:11 finrod kernel: 494.424083] DMA: Out of SW-IOMMU space for 9100 bytes at device 0000:07:00.0
May 2 15:00:11 finrod kernel: 494.435112] DMA: Out of SW-IOMMU space for 9100 bytes at device 0000:07:00.0
May 2 15:00:11 finrod kernel: 494.456975] ====================>haha:IPSEnter()
May 2 15:00:11 finrod kernel: 494.457004] =========>NicIFDisableNIC()
May 2 15:00:11 finrod kernel: 494.457027] PHY_SetRtl8192seRfHalt save BB/RF
I really hope the “haha” reference is not some kind of joke
I’ll try the later version, if I can find it from Realtek, but this is not encouraging…
OK - here’s the latest - I downloaded the driver from the Realtek site (which is not for the faint-of-heart, took me a while to find the **** thing).
I’ve been online for well over 30 minutes without a system hang, and while there are messages in /var/log/messages, they seem to be “debug” messages, not errors.
On now to Power Management, which seems broken as well. Thanks for the help on Wireless, everyone!
I’m not asking this out of pure curiosity, but without any information on that, I certainly won’t even think about building packages for driver:wireless from a vendor driver with obviously not the highest stability.
On 05/03/2010 06:06 AM, Akoellh wrote:
> I’m not asking this out of pure curiosity, but without any information
> on that, I certainly won’t even think about building packages for
> driver:wireless from a vendor driver with obviously not the highest
> stability.
Unfortunately, this device and many others made by Realtek have only the
vendor driver, or its close equivalent - the staging driver.
The way that these drivers are coded is atrocious by kernel standards,
but they do prove to be remarkably stable. With my RTL8187SE, the
staging driver will connect reliably and remain connected for days
without as much as a burp.
Yup, and the thing is, I have packages for all those drivers now (either from vendor or -if available- from staging backported to 11.2, some packages even build “down to 11.0” atm), but I won’t publish even one of them without any confirmation of somebody actually telling me “yes, this driver from Realtek site including this firmware works for me on openSUSE XYZ”.
I don’t want to throw c.r.a.p. at people in driver:wireless, that’s what home-projects are already for.
I am not a coder and my knowledge about C is very small indeed, but at least I can announce that one of those vendor drivers set a new “highest ratio of warnings against clean lines when compiling”-record yesterday.
Well, that baby had some time to mature in staging and as with that driver I got this feedback from users, there are packages available in driver:wireless (for 11.0 and 11.1, 11.2 contained the driver on release).
Considering my first package builds with what happened after it got some attention by kernel hackers, the difference is remarkable when talking about “clean builds”.
The first builds based on an external project (not even from Realtek but somewhere on google-code and based on one of their old driver versions for that device) were full of warnings, recent versions from staging compile without any “noise”.
The same goes for the drivers I backported from 2.6.34 staging to 2.6.31, no noise at all, but the ones being built from code downloaded from the Realtek site … /* no comment */.
@Akoellh, I am but a simple amateur when it comes to hardware, but I can try
Exact name of the driver download? (filename with version, maybe a download link)
It appears Realtek does not believe in download links - they have some kind of “post” operation for which you need to push a “go” button; I went to this page: Realtek
Navigation-wise, it’s:
HOME > Downloads > Communications Network ICs > Wireless LAN ICs > WLAN NIC > IEEE 802.11b/g Single-Chip > Software
The file that was pushed out was:
rtl8192se_linux_2.6.0015.0127.2010.tar.gz
Which firmware file(s) did you install?
This was all performed by the “make install”, but it appears it pushed it into
/lib/firmware/2.6.31.12-0.2-desktop/RTL8192SE/. Here is the listing in that folder:
Only one thing (and I am not paranoid, I saw this happening twice with rt2870.bin, a binary for Ralink USB cards that got changed without any notice from the vendor).
Yeah, I meant “show me the md5sums YOU get from those files”, so something like this.
And BTW, I am pretty sure you don’t need to install it into “/lib/firmware/<Kernelversion>/RTL8192SE/”, please confirm by moving the folder directly to /lib/firmware (as you can see above) and reloading the module (modprobe -rv r8192se_pci && modprobe -v r8192se_pci), for obvious reasons, if putting RTL8192SE directly to /lib/firmware works, packaging will be a lot easier (and especially the user will only have to download/install the firmware files once and not after every kernel update).
The packages are already there (have been for a few days to be honest), so I only need confirmation and as there is even license file included which explicitly allows redistribution, they could be published right away.
And BTW, I am pretty sure you don’t need to install it into “/lib/firmware//RTL8192SE/”, please confirm by moving the folder directly to /lib/firmware
OK - bear with me on that one (I don’t have any experience with this hardware driver stuff): when I look at the /lib/firmware folder, I only see “.cis” files in that folder:
finrod:/lib/firmware # ls -l /lib/firmware
total 60
drwxr-xr-x 30 root root 4096 May 2 23:05 2.6.31.12-0.2-desktop
-rw-r--r-- 1 root root 137 Oct 23 2009 3CCFEM556.cis
-rw-r--r-- 1 root root 134 Oct 23 2009 3CXEM556.cis
-rw-r--r-- 1 root root 109 Oct 23 2009 COMpad2.cis
-rw-r--r-- 1 root root 76 Oct 23 2009 COMpad4.cis
-rw-r--r-- 1 root root 136 Oct 23 2009 DP83903.cis
-rw-r--r-- 1 root root 53 Oct 23 2009 E-CARD.cis
-rw-r--r-- 1 root root 253 Oct 23 2009 LA-PCM.cis
-rw-r--r-- 1 root root 107 Oct 23 2009 MT5634ZLX.cis
-rw-r--r-- 1 root root 54 Oct 23 2009 NE2K.cis
-rw-r--r-- 1 root root 210 Oct 23 2009 PCMLM28.cis
-rw-r--r-- 1 root root 68 Oct 23 2009 PE-200.cis
-rw-r--r-- 1 root root 74 Oct 23 2009 PE520.cis
-rw-r--r-- 1 root root 86 Oct 23 2009 RS-COM-2P.cis
-rw-r--r-- 1 root root 85 Oct 23 2009 tamarack.cis
However, in the /lib/firmware/2.6.31.12-0.2-desktop subfolder, I see all the “other” firmware folders:
So… the RTL8192SE folder is sitting at the same level as the 3com/ folder, inside the <kernelversion> folder.
I won’t mind trying out what you suggest, but please confirm that is what you really meant.
Also - what if my wireless doesn’t work after I make this change. Is there an easy way to go back…? Like I said, commands like “modprobe” are a little “black magic” to me…
OK - wait a minute - for us newbies on this hardware driver stuff: it took me a while to figure out there is actually an openSUSE hosted repository for these wireless drivers (I would have searched there first, for sure). And - lo! my card is in there (now).
On 05/04/2010 10:06 PM, Akoellh wrote:
>
> twelveeighty;2161327 Wrote:
>>>
> Code:
> --------------------
> > >
> > md5sum /lib/firmware/2.6.31.12-0.2-desktop/RTL8192SE/*
> >
> > 972eca3225a018e949a097ad7b91567f /lib/firmware/2.6.31.12-0.2-desktop/RTL8192SE/Realtek-Firmware-License.txt
> > a5ad703551efb108ba012b4b8a830d93 /lib/firmware/2.6.31.12-0.2-desktop/RTL8192SE/rtl8192sfw.bin
> > 70ff412e813567ee331ce5edf05f4ddc /lib/firmware/2.6.31.12-0.2-desktop/RTL8192SE/rtl8192sfw492.bin
> > a65de7d458c00adbe96893341a3ff151 /lib/firmware/2.6.31.12-0.2-desktop/RTL8192SE/rtl8192sfw74.bin
> >
> --------------------
>>>
>>
>> So I believe the md5sums are the same.
>
> Yes, packages have been uploaded to driver:wireless already.
>
> twelveeighty;2161327 Wrote:
>> OK - bear with me on that one (I don’t have any experience with this
>> hardware driver stuff):
>
> Nevermind, thanks for confirmation.
Beware of the x86_64 package. It seems that those compilation warnings
can not be ignored as that driver panics my kernel. I have not yet
traced the problem. On a 32-bit system (a VirtualBox VM), the driver
spams the logs badly, but it works - at least in 802.11g mode. I don’t
have an 802.11n router. For the record, my device is a D-Link DWA-130N
Rev E with USB ID’s 07d1:3300. My plan is to fix the 64-bit driver,
clean up the log spamming, and submit the driver to staging.
and hesitated to publish them for other reasons, they overlap strongly in supported USB ids (maybe same driver in different versions?) and one of the drivers does not even unregister himself from /proc/net on unloading the module.
Or are you talking about the latest “vendor” driver which -yes, why not another one- has been given another nice name (8712u, WTF)?
That one spews out tons of warnings when compiling it on x86_64 (while i586 is completely “noise free”) and although it builds, it fails the rpmlint checks with “64 bit compatibility issues”.
The warnings related to what rpmlint is complaining about are (paths are shortened for clarity):
.... hal/rtl8712/usb_ops_linux.c:716: warning: assignment makes pointer from integer without a cast
..... hal/rtl8712/usb_ops_linux.c:717: warning: assignment makes pointer from integer without a cast
..... hal/rtl8712/usb_ops_linux.c:726: warning: assignment makes pointer from integer without a cast
..... hal/rtl8712/usb_ops_linux.c:727: warning: assignment makes pointer from integer without a cast
On 05/05/2010 10:56 AM, Akoellh wrote:
>
> @Larry
>
> You are talking about some USB devices, this package here is for PCI(E)
> cards.
>
> However, I also built packages for rtl8192 USB devices from 2.6.34
>
> http://tinyurl.com/286ps74
>
> (RTL8192U/RTL8192SU)
>
> and hesitated to publish them for other reasons, they overlap strongly
> in supported USB ids (maybe same driver in different versions?) and one
> of the drivers does not even unregister himself from /proc/net on
> unloading the module.
>
> Or are you talking about the latest “vendor” driver which -yes, why not
> another one- has been given another nice name (8712u, WTF)?
>
> That one spews out tons of warnings when compiling it on x86_64 (while
> i586 is completely “noise free”) and although it builds, it fails the
> rpmlint checks with “64 bit compatibility issues”.
>
> The warnings related to what rpmlint is complaining about are (paths
> are shortened for clarity):
>
>
> Code:
> --------------------
> … hal/rtl8712/usb_ops_linux.c:716: warning: assignment makes pointer from integer without a cast
> … hal/rtl8712/usb_ops_linux.c:717: warning: assignment makes pointer from integer without a cast
> … hal/rtl8712/usb_ops_linux.c:726: warning: assignment makes pointer from integer without a cast
> … hal/rtl8712/usb_ops_linux.c:727: warning: assignment makes pointer from integer without a cast
> --------------------
>
>
> and the respective lines are
>
>
> Code:
> --------------------
> tmpaddr = (u32)precvbuf->pskb->data;
> alignment = tmpaddr & (RECVBUFF_ALIGN_SZ-1);
> skb_reserve(precvbuf->pskb, (RECVBUFF_ALIGN_SZ - alignment));
>
> precvbuf->phead = precvbuf->pskb->head;
> precvbuf->pdata = precvbuf->pskb->data;
> precvbuf->ptail = precvbuf->pskb->tail;
> precvbuf->pend = precvbuf->pskb->end;
>
> precvbuf->pbuf = precvbuf->pskb->data;
>
> }
> else//reuse skb
> {
> precvbuf->phead = precvbuf->pskb->head;
> precvbuf->pdata = precvbuf->pskb->data;
> precvbuf->ptail = precvbuf->pskb->tail;
> precvbuf->pend = precvbuf->pskb->end;
> precvbuf->pbuf = precvbuf->pskb->data;
> --------------------
> I remember a similar issue in the ralink staging drivers (skb->tail vs
> skb_tail_pointer(skb)), but my knowledge is too limited to fix this
> myself.
Sorry, I got confused. As I stated before, the warnings with x86_64
indicate real problems with the driver, but I have not had time to sort
it out. At the moment, the rtl8192u and rtl8192su drivers in staging,
and this vendor driver all work for the same set of devices.
Trying to run make, make install on unarchived tarball:
rtl8192se_linux_2.6.0015.0127.2010.tar.gz
I arrive at the following make error:
make
make: *** /lib/modules/2.6.31.12-0.2-desktop/build: No such
file or directory. Stop.
make: *** [all] Error 2
It’s obvious I need to edit path(s) in Makefile, anybody care to toss out suggestion?
Seems I had good reason for avoiding tarballs as often as I have over the years…
Unknown to me at time of purchase, this laptop is pure trouble for most any Linux release, at least 6 or so flavors I’ve tried. But I did manage to get NVIDIA (Geforce 310m) working, and have since turned on Compiz.
On 05/31/2010 05:26 PM, bigpat wrote:
>
> On a Toshiba A505-S6020 laptop.
>
> Trying to run make, make install on unarchived tarball:
>
> rtl8192se_linux_2.6.0015.0127.2010.tar.gz
>
> I arrive at the following make error:
>
> make
> make: *** /lib/modules/2.6.31.12-0.2-desktop/build: No such
> file or directory. Stop.
> make: *** [all] Error 2
>
> It’s obvious I need to edit path(s) in Makefile, anybody care to toss
> out suggestion?
Do NOT edit the Makefile!
To compile a kernel module, you need to have (at least) the kernel
headers installed. That missing directory should be a link that points
to the directory in which the “include” directory resides.
I went to install kernel headers, Yast told be to compile a module I needed kernel-source. So fine, that’s what I installed.
After that, make and make install worked fine.
After reboot I’m able to sniff active local wifi, configured connect to my router WPA2, but it never finalizes connection now. In Network Manager bar shows it makes about 90% progress is all. Almost like it doesn’t like my D-Link, Win 7 connects to it fine, and I’ve rechecked settings too many times to count.
There are two places to check for diagnostic information: (1) the output
of the dmesg command, and (2) the contents of the file
/var/log/wpa_supplicant.log. Do you see anything of interest?
If possible, can you try your network without encryption? It would not
be safe to leave it that way, but it would eliminate a lot of steps.
Please be aware that I have been chasing a bug in the 8172u code that
prevents the USB version of your chip from connecting when using 64-bit
systems, even though it works perfectly on 32-bit machines. From a
combination of log viewing (as recommended above), extra log printouts,
and wireshark sniffing of the traffic on the air, I see that the AP is
responding to the request for authentication with a so-called EAPOL
packet. The packet is acknowledged by the firmware, thus I know it was
received. The next step in authentication would be for the driver to
issue a responding EAPOL packet. For unknown reasons, this never happens
and NetworkManager keeps requesting the WPA2 secret.
