FYI rtl8192ce maintainers (and maillist archive readers),
I recently bought Toshiba Satellite C850D-107 version PSC9SE-00T00DEN
which comes with Realtek hardware[1].
Initially I had a bit of problems with Arch Linux kernel 3.5.4-1-ARCH
which froze after running wpa_supplicant. Once the command had been
entered it took about 5 to 10 seconds before real trouble, by which I
mean terminal did not echo keystrokes nor feel any way responsive. I did
not try Magic SysRq's.
Strange enough that problem persisted over boot, and went away only if I
went to BIOS and set factory defaults. Once factory defaults where set I
could use console again, as long I did not try to do anything with
wpa_supplicant command. After wondering for while I found
instructions[2] how to go around; disable power saving, e.g., the set the
lines below.
$ cat /etc/modprobe.d/rtl8192ce.conf
options rtl8192ce ips=0 fwlps=0
That worked I became curious if the latest kernel would have the same
issue. Now I am running 3.6.0-rc6-ARCH-00193-ge5e77cf from Linus's git
with new firmware[3], and power save enabled. At least after an hour all
seems to work fine.
Did you anticipate firmware change to fix this these sort of problem?
[1] The hardware:
06:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8188CE
802.11b/g/n WiFi Adapter (rev 01)
Subsystem: Realtek Semiconductor Co., Ltd. Device 8212
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 17
Region 0: I/O ports at 3000 [size=256]
Region 2: Memory at f0200000 (64-bit, non-prefetchable) [size=16K]
Capabilities: <access denied>
Kernel driver in use: rtl8192ce
[2] https://bbs.archlinux.org/viewtopic.php?id=132931
[3] md5sum /usr/lib/firmware/rtlwifi/rtl8192cfwU_B.bin
dd371739aa401ea1d615436b24598bc4 /usr/lib/firmware/rtlwifi/rtl8192cfwU_B.bin
--
Sami Kerola
http://www.iki.fi/kerolasa/
On 09/25/2012 01:00 PM, Sami Kerola wrote:
>
> Well, I had no idea about any firmware update before I compiled
> Linus git
>
> commit e5e77cf9f9a275083f9a365a20d956fa8a67803e
>
> and after boot the driver was more broken. With rmmod & modprobe
> I realized rtl8192cfwU_B.bin was expected, so I added it to
> /usr/lib/firmware/ manually from
>
> http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=blob_plain;f=rtlwifi/rtl8192cfwU_B.bin;hb=HEAD
>
> That made dmesg telling insmod is happy...
My distro (openSUSE) provides regular updates of the firmware from the
linux-firmware git repository. As you noted, the B-cut firmware for the
RTL8188CE has been in that repo for some time.
> kerolasa@kerolasa-home ~ dmesg | grep rtl
> [ 7.901371] rtl8192ce: ****** This B_CUT device may not work with
> kernels 3.6 and earlier
> [ 7.901383] rtl8192ce: Using firmware rtlwifi/rtl8192cfwU_B.bin
> [ 8.104591] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
> [ 8.105394] rtlwifi: wireless switch is on
>
> ...and quite frankly so am I, even tough this is strange way to
> fix peculiar problem.
What is strange about it? We discovered that certain cards would not work about
10 days ago. By comparison with the vendor driver, the fix was found; however,
it was too invasive to be applied at this time to kernel 3.6, thus the partial
patch was prepared. For most of the affected cards, it is not enough, which is
why the message says "may not work". You are lucky that it does. As I said
earlier, the real fix will be in kernel 3.7, and the above message is deleted.
Larry
On Tue, Sep 25, 2012 at 2:25 PM, Larry Finger <[email protected]> wrote:
Hi Larry et.al.,
> As I do not have a Toshiba laptop, I have no idea what the
> change in BIOS setting might have done.
All I know it happen every time, so if someone has any idea how
to debug what is going on proposals are welcome.
> I doubt that adding the rtl8192cfwU_B.bin firmware to your
> system made any difference. The device that needs that
> firmware is a B-cut RTL8188CE, and the code to drive it has
> been submitted to wireless-testing, but not yet merged. I
> expect that it will be in kernel 3.7. Kernel 3.6-rc7 from
> mainline contains code that detects the B-cut device and logs a
> warning, but there are no other changes.
>
> The output of the dmesg command will say what firmware has been
> loaded.
Well, I had no idea about any firmware update before I compiled
Linus git
commit e5e77cf9f9a275083f9a365a20d956fa8a67803e
and after boot the driver was more broken. With rmmod & modprobe
I realized rtl8192cfwU_B.bin was expected, so I added it to
/usr/lib/firmware/ manually from
http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=blob_plain;f=rtlwifi/rtl8192cfwU_B.bin;hb=HEAD
That made dmesg telling insmod is happy...
kerolasa@kerolasa-home ~ dmesg | grep rtl
[ 7.901371] rtl8192ce: ****** This B_CUT device may not work with
kernels 3.6 and earlier
[ 7.901383] rtl8192ce: Using firmware rtlwifi/rtl8192cfwU_B.bin
[ 8.104591] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
[ 8.105394] rtlwifi: wireless switch is on
...and quite frankly so am I, even tough this is strange way to
fix peculiar problem.
--
Sami Kerola
http://www.iki.fi/kerolasa/
On 09/24/2012 02:49 PM, Sami Kerola wrote:
> FYI rtl8192ce maintainers (and maillist archive readers),
>
> I recently bought Toshiba Satellite C850D-107 version PSC9SE-00T00DEN
> which comes with Realtek hardware[1].
>
> Initially I had a bit of problems with Arch Linux kernel 3.5.4-1-ARCH
> which froze after running wpa_supplicant. Once the command had been
> entered it took about 5 to 10 seconds before real trouble, by which I
> mean terminal did not echo keystrokes nor feel any way responsive. I did
> not try Magic SysRq's.
>
> Strange enough that problem persisted over boot, and went away only if I
> went to BIOS and set factory defaults. Once factory defaults where set I
> could use console again, as long I did not try to do anything with
> wpa_supplicant command. After wondering for while I found
> instructions[2] how to go around; disable power saving, e.g., the set the
> lines below.
>
> $ cat /etc/modprobe.d/rtl8192ce.conf
> options rtl8192ce ips=0 fwlps=0
>
> That worked I became curious if the latest kernel would have the same
> issue. Now I am running 3.6.0-rc6-ARCH-00193-ge5e77cf from Linus's git
> with new firmware[3], and power save enabled. At least after an hour all
> seems to work fine.
>
> Did you anticipate firmware change to fix this these sort of problem?
>
>
> [1] The hardware:
> 06:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8188CE
> 802.11b/g/n WiFi Adapter (rev 01)
> Subsystem: Realtek Semiconductor Co., Ltd. Device 8212
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0, Cache Line Size: 64 bytes
> Interrupt: pin A routed to IRQ 17
> Region 0: I/O ports at 3000 [size=256]
> Region 2: Memory at f0200000 (64-bit, non-prefetchable) [size=16K]
> Capabilities: <access denied>
> Kernel driver in use: rtl8192ce
>
> [2] https://bbs.archlinux.org/viewtopic.php?id=132931
>
> [3] md5sum /usr/lib/firmware/rtlwifi/rtl8192cfwU_B.bin
> dd371739aa401ea1d615436b24598bc4 /usr/lib/firmware/rtlwifi/rtl8192cfwU_B.bin
As I do not have a Toshiba laptop, I have no idea what the change in BIOS
setting might have done.
I doubt that adding the rtl8192cfwU_B.bin firmware to your system made any
difference. The device that needs that firmware is a B-cut RTL8188CE, and the
code to drive it has been submitted to wireless-testing, but not yet merged. I
expect that it will be in kernel 3.7. Kernel 3.6-rc7 from mainline contains code
that detects the B-cut device and logs a warning, but there are no other changes.
The output of the dmesg command will say what firmware has been loaded.
Larry