r8187se panic

r8187se panic

[Robie Basak]

Hi,

I'm getting a panic when I to turn off the wireless using the Fn-F2
combination on my Asus Eee PC 701SDX. Although I'm using Ubuntu 10.10,
I've tried it using the mainline kernel (as supplied by Ubuntu for
testing bugs against mainline). So far I've reproduced consistently
against Ubuntu's 2.6.35-22-generic-pae as well as Ubuntu-supplied
mainstream 2.6.35-02063504.201008271919 and
2.6.37-020637rc1.201011020905.

There are no problems at all if I rmmod r8187se before hitting the
switch; I can turn wireless back on and r8187se autoloads and wireless
works fine.

I have also reported this to Ubuntu downstream; that report also
includes various automatic information about my system you might find
helpful: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/674285

Please also see my side note in that report about r8187se causing a hang
after disconnecting AC after suspend. I don't know if that is related or
not.

I can't seem to get a crash dump. Setting /proc/sys/kernel/panic doesn't
seem to help the kernel reboot after a panic. I've taken a photo of what
I can see at http://i.imgur.com/QSXMD.jpg

Is this a problem with Eee PC ACPI or in r8187se? Which way up is the
backtrace? I think it's most-recent first at an educated guess?

What else can I do? I'm happy to hack, try patches etc.  Any pointers
would be appreciated, particularly towards getting a full dump - I've
spent a while trying to find a solution but haven't got anywhere. I've
installed (Ubuntu) linux-crashdump but nothing appears in /var/crash,
presumably because I'm killing the power since I can't get it to reboot,
and there's no reset button. If you need me to compile a kernel direct
from mainstream source instead of using the Ubuntu mainstream builds I
can manage that.

Cheers,

Robie

Re: r8187se panic

[Larry Finger]

On 11/11/2010 06:41 PM, Robie Basak wrote:
> Hi,
> 
> I'm getting a panic when I to turn off the wireless using the Fn-F2
> combination on my Asus Eee PC 701SDX. Although I'm using Ubuntu 10.10,
> I've tried it using the mainline kernel (as supplied by Ubuntu for
> testing bugs against mainline). So far I've reproduced consistently
> against Ubuntu's 2.6.35-22-generic-pae as well as Ubuntu-supplied
> mainstream 2.6.35-02063504.201008271919 and
> 2.6.37-020637rc1.201011020905.

Is Fn-F2 the radio kill switch?

> There are no problems at all if I rmmod r8187se before hitting the
> switch; I can turn wireless back on and r8187se autoloads and wireless
> works fine.
> 
> I have also reported this to Ubuntu downstream; that report also
> includes various automatic information about my system you might find
> helpful: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/674285
> 
> Please also see my side note in that report about r8187se causing a hang
> after disconnecting AC after suspend. I don't know if that is related or
> not.
> 
> I can't seem to get a crash dump. Setting /proc/sys/kernel/panic doesn't
> seem to help the kernel reboot after a panic. I've taken a photo of what
> I can see at http://i.imgur.com/QSXMD.jpg
> 
> Is this a problem with Eee PC ACPI or in r8187se? Which way up is the
> backtrace? I think it's most-recent first at an educated guess?

The calling sequence is up screen. Thus rtl8180_pci_remove() calls
unregister_netdev(), etc. It is really tough debugging without seeing what
routine is actually causing the panic.

> What else can I do? I'm happy to hack, try patches etc.  Any pointers
> would be appreciated, particularly towards getting a full dump - I've
> spent a while trying to find a solution but haven't got anywhere. I've
> installed (Ubuntu) linux-crashdump but nothing appears in /var/crash,
> presumably because I'm killing the power since I can't get it to reboot,
> and there's no reset button. If you need me to compile a kernel direct
> from mainstream source instead of using the Ubuntu mainstream builds I
> can manage that.

At this point, I see no point in building a mainstream kernel.

Do you have another host that might be setup as a net console?

Larry

Re: r8187se panic

[Robie Basak]

On 2010-11-12, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> On 11/11/2010 06:41 PM, Robie Basak wrote:
>> I'm getting a panic when I to turn off the wireless using the Fn-F2
>> combination on my Asus Eee PC 701SDX. Although I'm using Ubuntu 10.10,
>> I've tried it using the mainline kernel (as supplied by Ubuntu for
>> testing bugs against mainline). So far I've reproduced consistently
>> against Ubuntu's 2.6.35-22-generic-pae as well as Ubuntu-supplied
>> mainstream 2.6.35-02063504.201008271919 and
>> 2.6.37-020637rc1.201011020905.
>
> Is Fn-F2 the radio kill switch?

Yes, that's right.

> At this point, I see no point in building a mainstream kernel.
>
> Do you have another host that might be setup as a net console?

Yes, I managed to get net console working (eventually):

(the first four lines are from when I modprobed r8187se)

[  941.787361] r8187se: module is from the staging directory, the quality is unknown, you have been warned.
[  941.821968] rtl8180_init:Error channel plan! Set to default.
[  941.825000] Dot11d_Init()
[  941.877241] r8180: WW:**PLEASE** REPORT SUCCESSFUL/UNSUCCESSFUL TO Realtek!
[  947.318002] ------------[ cut here ]------------
[  947.321315] WARNING: at /home/kernel-ppa/COD/linux/fs/proc/generic.c:816 remove_proc_entry+0x1e5/0x240()
[  947.328160] Hardware name: 701SDX
[  947.331607] name 'wlan0'
[  947.334987] Modules linked in: r8187se(C) netconsole eeprom_93cx6 parport_pc ppdev binfmt_misc snd_hda_codec_realtek snd_hda_intel i915 snd_hda_codec snd_hwdep snd_pcm drm_kms_helper joydev snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq drm snd_timer snd_seq_device intel_agp i2c_algo_bit intel_gtt snd psmouse eeepc_laptop video shpchp soundcore serio_raw agpgart sparse_keymap snd_page_alloc output led_class lp parport atl1e configfs [last unloaded: r8187se]
[  947.354968] Pid: 1350, comm: kworker/0:2 Tainted: G        WC  2.6.37-020637rc1-generic #201011020905
[  947.363331] Call Trace:
[  947.367541]  [<c02700d5>] ? remove_proc_entry+0x1e5/0x240
[  947.371870]  [<c02700d5>] ? remove_proc_entry+0x1e5/0x240
[  947.376103]  [<c014f7c1>] warn_slowpath_common+0x81/0xa0
[  947.380279]  [<c02700d5>] ? remove_proc_entry+0x1e5/0x240
[  947.384481]  [<c014f883>] warn_slowpath_fmt+0x33/0x40
[  947.388672]  [<c02700d5>] remove_proc_entry+0x1e5/0x240
[  947.392856]  [<c050c847>] ? netdev_refcnt_read+0x37/0x50
[  947.397022]  [<e02c4d3b>] rtl8180_proc_remove_one+0x6b/0x80 [r8187se]
[  947.401375]  [<e02dd876>] rtl8180_pci_remove+0x36/0x107 [r8187se]
[  947.405780]  [<c0420206>] ? __pm_runtime_resume+0x46/0x60
[  947.410280]  [<c038372a>] pci_device_remove+0x3a/0xc0
[  947.414794]  [<c0418301>] __device_release_driver+0x51/0xa0
[  947.419234]  [<c0418855>] device_release_driver+0x25/0x40
[  947.423530]  [<c0417c07>] bus_remove_device+0x57/0x80
[  947.427800]  [<c041556f>] device_del+0xff/0x160
[  947.432005]  [<c04155e0>] device_unregister+0x10/0x20
[  947.436160]  [<c037eabd>] pci_stop_dev+0x3d/0x50
[  947.440196]  [<c037eaee>] pci_stop_bus_device+0x1e/0x30
[  947.444076]  [<c037ec59>] pci_remove_bus_device+0x19/0x50
[  947.447790]  [<e0101306>] eeepc_rfkill_hotplug+0x126/0x160 [eeepc_laptop]
[  947.451614]  [<c03afe84>] ? acpi_bus_get_device+0x25/0x37
[  947.455483]  [<e0101407>] eeepc_rfkill_notify+0x17/0x20 [eeepc_laptop]
[  947.459306]  [<c03bd2a4>] acpi_ev_notify_dispatch+0x58/0x6a
[  947.463010]  [<c03adb3f>] acpi_os_execute_deferred+0x22/0x2d
[  947.466599]  [<c0168819>] process_one_work+0xd9/0x330
[  947.470019]  [<c03adb1d>] ? acpi_os_execute_deferred+0x0/0x2d
[  947.473369]  [<c0169413>] worker_thread+0xb3/0x210
[  947.476555]  [<c0169360>] ? worker_thread+0x0/0x210
[  947.479606]  [<c016c935>] kthread+0x75/0x80
[  947.482648]  [<c016c8c0>] ? kthread+0x0/0x80
[  947.485659]  [<c01032fe>] kernel_thread_helper+0x6/0x10
[  947.488760] ---[ end trace ff99ebfd52b415a2 ]---
[  947.491911] Kernel panic - not syncing: HwThreeWire(): CmdReg: 0XFF RE|WE bits are not clear!!
[  947.491916] 
[  947.498375] Pid: 1350, comm: kworker/0:2 Tainted: G        WC  2.6.37-020637rc1-generic #201011020905
[  947.505177] Call Trace:
[  947.508561]  [<c014f90f>] panic+0x5f/0x190
[  947.511965]  [<e02ccd3f>] HwHSSIThreeWire+0x4f/0x270 [r8187se]
[  947.515424]  [<e02ccfd2>] RF_WriteReg+0x32/0x40 [r8187se]
[  947.518877]  [<e02cb29a>] rtl8225z2_rf_close+0x1a/0x50 [r8187se]
[  947.522384]  [<e02dd885>] rtl8180_pci_remove+0x45/0x107 [r8187se]
[  947.525861]  [<c0420206>] ? __pm_runtime_resume+0x46/0x60
[  947.529347]  [<c038372a>] pci_device_remove+0x3a/0xc0
[  947.532819]  [<c0418301>] __device_release_driver+0x51/0xa0
[  947.536370]  [<c0418855>] device_release_driver+0x25/0x40
[  947.539862]  [<c0417c07>] bus_remove_device+0x57/0x80
[  947.543417]  [<c041556f>] device_del+0xff/0x160
[  947.546974]  [<c04155e0>] device_unregister+0x10/0x20
[  947.550492]  [<c037eabd>] pci_stop_dev+0x3d/0x50
[  947.553947]  [<c037eaee>] pci_stop_bus_device+0x1e/0x30
[  947.557330]  [<c037ec59>] pci_remove_bus_device+0x19/0x50
[  947.560682]  [<e0101306>] eeepc_rfkill_hotplug+0x126/0x160 [eeepc_laptop]
[  947.564130]  [<c03afe84>] ? acpi_bus_get_device+0x25/0x37
[  947.567535]  [<e0101407>] eeepc_rfkill_notify+0x17/0x20 [eeepc_laptop]
[  947.571020]  [<c03bd2a4>] acpi_ev_notify_dispatch+0x58/0x6a
[  947.574490]  [<c03adb3f>] acpi_os_execute_deferred+0x22/0x2d
[  947.577982]  [<c0168819>] process_one_work+0xd9/0x330
[  947.581465]  [<c03adb1d>] ? acpi_os_execute_deferred+0x0/0x2d
[  947.585032]  [<c0169413>] worker_thread+0xb3/0x210
[  947.588588]  [<c0169360>] ? worker_thread+0x0/0x210
[  947.592117]  [<c016c935>] kthread+0x75/0x80
[  947.595463]  [<c016c8c0>] ? kthread+0x0/0x80
[  947.598740]  [<c01032fe>] kernel_thread_helper+0x6/0x10
[  947.601954] panic occurred, switching back to text console

Re: r8187se panic

[Larry Finger]

[-- Attachment #1: Type: text/plain, Size: 3716 bytes --]

On 11/12/2010 05:06 AM, Robie Basak wrote:
> On 2010-11-12, Larry Finger <Larry.Finger@lwfinger.net> wrote:
>> On 11/11/2010 06:41 PM, Robie Basak wrote:
>>> I'm getting a panic when I to turn off the wireless using the Fn-F2
>>> combination on my Asus Eee PC 701SDX. Although I'm using Ubuntu 10.10,
>>> I've tried it using the mainline kernel (as supplied by Ubuntu for
>>> testing bugs against mainline). So far I've reproduced consistently
>>> against Ubuntu's 2.6.35-22-generic-pae as well as Ubuntu-supplied
>>> mainstream 2.6.35-02063504.201008271919 and
>>> 2.6.37-020637rc1.201011020905.
>>
>> Is Fn-F2 the radio kill switch?
> 
> Yes, that's right.
> 
>> At this point, I see no point in building a mainstream kernel.
>>
>> Do you have another host that might be setup as a net console?
> 
> Yes, I managed to get net console working (eventually):
> 
> (the first four lines are from when I modprobed r8187se)
> 
> [  941.787361] r8187se: module is from the staging directory, the quality is unknown, you have been warned.
> [  941.821968] rtl8180_init:Error channel plan! Set to default.
> [  941.825000] Dot11d_Init()
> [  941.877241] r8180: WW:**PLEASE** REPORT SUCCESSFUL/UNSUCCESSFUL TO Realtek!
> [  947.318002] ------------[ cut here ]------------
> [  947.321315] WARNING: at /home/kernel-ppa/COD/linux/fs/proc/generic.c:816 remove_proc_entry+0x1e5/0x240()
> [  947.328160] Hardware name: 701SDX
> [  947.331607] name 'wlan0'
> [  947.334987] Modules linked in: r8187se(C) netconsole eeprom_93cx6 parport_pc ppdev binfmt_misc snd_hda_codec_realtek snd_hda_intel i915 snd_hda_codec snd_hwdep snd_pcm drm_kms_helper joydev snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq drm snd_timer snd_seq_device intel_agp i2c_algo_bit intel_gtt snd psmouse eeepc_laptop video shpchp soundcore serio_raw agpgart sparse_keymap snd_page_alloc output led_class lp parport atl1e configfs [last unloaded: r8187se]
> [  947.354968] Pid: 1350, comm: kworker/0:2 Tainted: G        WC  2.6.37-020637rc1-generic #201011020905
> [  947.363331] Call Trace:
> [  947.367541]  [<c02700d5>] ? remove_proc_entry+0x1e5/0x240

--snip--

> [  947.491911] Kernel panic - not syncing: HwThreeWire(): CmdReg: 0XFF RE|WE bits are not clear!!
> [  947.491916] 
> [  947.498375] Pid: 1350, comm: kworker/0:2 Tainted: G        WC  2.6.37-020637rc1-generic #201011020905
> [  947.505177] Call Trace:
> [  947.508561]  [<c014f90f>] panic+0x5f/0x190
> [  947.511965]  [<e02ccd3f>] HwHSSIThreeWire+0x4f/0x270 [r8187se]
> [  947.515424]  [<e02ccfd2>] RF_WriteReg+0x32/0x40 [r8187se]
> [  947.518877]  [<e02cb29a>] rtl8225z2_rf_close+0x1a/0x50 [r8187se]
> [  947.522384]  [<e02dd885>] rtl8180_pci_remove+0x45/0x107 [r8187se]
> [  947.525861]  [<c0420206>] ? __pm_runtime_resume+0x46/0x60
> [  947.529347]  [<c038372a>] pci_device_remove+0

Thanks for the netconsole output. That helps a lot.

The warning in remove_proc_entry() is essentially harmless. I'll take care of
that later.

The driver should never panic over a condition as trivial as the RE/WE bits are
not zero. I missed that when I worked on the original version of the driver. As
the bits are all 1, it appears that the device is partially disabled before this
code is reached. One thing I notice is that there is no lock around the
unregister_netdevice() call.

Attached are two patches. One changes the panic statements into log entries with
a stack dump, and the second provides a lock for the call noted above. The first
patch cannot cause any problems; however, the second may cause the machine to
freeze. At least with the first, the system will no longer crash.

While you are testing these, I'll try to sort out why there is a warning in
remove_proc_entry().

Larry




[-- Attachment #2: rtl8187se_change_panic_to_warn --]
[-- Type: text/plain, Size: 1714 bytes --]

Index: linux-2.6/drivers/staging/rtl8187se/r8185b_init.c
===================================================================
--- linux-2.6.orig/drivers/staging/rtl8187se/r8185b_init.c
+++ linux-2.6/drivers/staging/rtl8187se/r8185b_init.c
@@ -264,8 +264,12 @@ HwHSSIThreeWire(
 
 			udelay(10);
 		}
-		if (TryCnt == TC_3W_POLL_MAX_TRY_CNT)
-			panic("HwThreeWire(): CmdReg: %#X RE|WE bits are not clear!!\n", u1bTmp);
+		if (TryCnt == TC_3W_POLL_MAX_TRY_CNT) {
+			printk(KERN_ERR "rtl8187se: HwThreeWire(): CmdReg:"
+			       " %#X RE|WE bits are not clear!!\n", u1bTmp);
+			dump_stack();
+			return 0;
+		}
 
 		/* RTL8187S HSSI Read/Write Function */
 		u1bTmp = read_nic_byte(dev, RF_SW_CONFIG);
@@ -298,13 +302,23 @@ HwHSSIThreeWire(
 				int idx;
 				int ByteCnt = nDataBufBitCnt / 8;
 								/* printk("%d\n",nDataBufBitCnt); */
-				if ((nDataBufBitCnt % 8) != 0)
-				panic("HwThreeWire(): nDataBufBitCnt(%d) should be multiple of 8!!!\n",
-				nDataBufBitCnt);
-
-			       if (nDataBufBitCnt > 64)
-				panic("HwThreeWire(): nDataBufBitCnt(%d) should <= 64!!!\n",
-				nDataBufBitCnt);
+				if ((nDataBufBitCnt % 8) != 0) {
+					printk(KERN_ERR "rtl8187se: "
+					       "HwThreeWire(): nDataBufBitCnt(%d)"
+					       " should be multiple of 8!!!\n",
+					       nDataBufBitCnt);
+					dump_stack();
+					nDataBufBitCnt += 8;
+					nDataBufBitCnt &= ~7;
+				}
+
+			       if (nDataBufBitCnt > 64) {
+					printk(KERN_ERR "rtl8187se: HwThreeWire():"
+					       " nDataBufBitCnt(%d) should <= 64!!!\n",
+					       nDataBufBitCnt);
+					dump_stack();
+					nDataBufBitCnt = 64;
+				}
 
 				for (idx = 0; idx < ByteCnt; idx++)
 					write_nic_byte(dev, (SW_3W_DB0+idx), *(pDataBuf+idx));

[-- Attachment #3: rtl8187se_lock_pci_remove --]
[-- Type: text/plain, Size: 689 bytes --]

Index: linux-2.6/drivers/staging/rtl8187se/r8180_core.c
===================================================================
--- linux-2.6.orig/drivers/staging/rtl8187se/r8180_core.c
+++ linux-2.6/drivers/staging/rtl8187se/r8180_core.c
@@ -3656,12 +3656,15 @@ static void __devexit rtl8180_pci_remove
 {
 	struct r8180_priv *priv;
 	struct net_device *dev = pci_get_drvdata(pdev);
+	unsigned long flags;
 
 	if (dev) {
-		unregister_netdev(dev);
-
 		priv = ieee80211_priv(dev);
 
+		spin_lock_irqsave(&priv->rf_ps_lock, flags);
+		unregister_netdev(dev);
+		spin_unlock_irqrestore(&priv->rf_ps_lock, flags);
+
 		rtl8180_proc_remove_one(dev);
 		rtl8180_down(dev);
 		priv->rf_close(dev);

Re: r8187se panic

[Robie Basak]

Larry,

The patches have helped - thanks!

Failure case A:
  1) Boot with AC power connected and wireless on
  2) Switch wireless off
  3) Kernel panic

With just the change_panic_to_warn patch, case A works fine now.
However, the following sequence of events now causes some sort of
infinite loop (with lots of stack traces in dmesg) instead of a hang
like it did before:

Failure case B:
  1) Boot with AC power connected and wireless on
  2) Suspend
  3) Resume (and Network Manager kicks in to reconnect etc)
  4) Remove AC power
  5) (wait a few seconds)
  6) Some sort of loop with lots being dumped to dmesg, no wireless
connection resumes

With the addition of the lock_pci_remove patch, case B goes away too.
However, adding more to the failure case still causes problems:

Failure case C:
  1) Boot with AC power connected and wireless on
  2) Suspend
  3) Resume (and Network Manager kicks in to reconnect etc)
  4) Remove AC power
  5) (wait a few seconds)
  6) Restore AC power
  7) (wireless disconnects; some sort of loop in dmesg; it does manage
to associate at times but this never lasts long)
  8) (network Manager gives up) but the loop in dmesg continues
  9) Reloading the module and toggling the wireless switch seems to fix
     it

Note that I can work around cases B and C by having
SUSPEND_MODULES=r8187se in /etc/pm/config.d. The original problem does
seem to be resolved. Case C also seems pretty non-deterministic. I can't
reproduce it reliably. I have also managed to cause a hang using various
combinations of switching AC power, suspend and the wireless switch but
I haven't managed to reproduce it.

All of the stuff in dmesg I could see seems to be the same RE|WE bits
not clear stack trace from your patch.

Does this help? Is there anything else I can do?

Thanks,

Robie

On 2010-11-12, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> This is a multi-part message in MIME format.
> --------------070405020109010304050501
> Content-Type: text/plain; charset=ISO-8859-1
> Content-Transfer-Encoding: 7bit
>
> On 11/12/2010 05:06 AM, Robie Basak wrote:
>> On 2010-11-12, Larry Finger <Larry.Finger@lwfinger.net> wrote:
>>> On 11/11/2010 06:41 PM, Robie Basak wrote:
>>>> I'm getting a panic when I to turn off the wireless using the Fn-F2
>>>> combination on my Asus Eee PC 701SDX. Although I'm using Ubuntu 10.10,
>>>> I've tried it using the mainline kernel (as supplied by Ubuntu for
>>>> testing bugs against mainline). So far I've reproduced consistently
>>>> against Ubuntu's 2.6.35-22-generic-pae as well as Ubuntu-supplied
>>>> mainstream 2.6.35-02063504.201008271919 and
>>>> 2.6.37-020637rc1.201011020905.
>>>
>>> Is Fn-F2 the radio kill switch?
>> 
>> Yes, that's right.
>> 
>>> At this point, I see no point in building a mainstream kernel.
>>>
>>> Do you have another host that might be setup as a net console?
>> 
>> Yes, I managed to get net console working (eventually):
>> 
>> (the first four lines are from when I modprobed r8187se)
>> 
>> [  941.787361] r8187se: module is from the staging directory, the quality is unknown, you have been warned.
>> [  941.821968] rtl8180_init:Error channel plan! Set to default.
>> [  941.825000] Dot11d_Init()
>> [  941.877241] r8180: WW:**PLEASE** REPORT SUCCESSFUL/UNSUCCESSFUL TO Realtek!
>> [  947.318002] ------------[ cut here ]------------
>> [  947.321315] WARNING: at /home/kernel-ppa/COD/linux/fs/proc/generic.c:816 remove_proc_entry+0x1e5/0x240()
>> [  947.328160] Hardware name: 701SDX
>> [  947.331607] name 'wlan0'
>> [  947.334987] Modules linked in: r8187se(C) netconsole eeprom_93cx6 parport_pc ppdev binfmt_misc snd_hda_codec_realtek snd_hda_intel i915 snd_hda_codec snd_hwdep snd_pcm drm_kms_helper joydev snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq drm snd_timer snd_seq_device intel_agp i2c_algo_bit intel_gtt snd psmouse eeepc_laptop video shpchp soundcore serio_raw agpgart sparse_keymap snd_page_alloc output led_class lp parport atl1e configfs [last unloaded: r8187se]
>> [  947.354968] Pid: 1350, comm: kworker/0:2 Tainted: G        WC  2.6.37-020637rc1-generic #201011020905
>> [  947.363331] Call Trace:
>> [  947.367541]  [<c02700d5>] ? remove_proc_entry+0x1e5/0x240
>
> --snip--
>
>> [  947.491911] Kernel panic - not syncing: HwThreeWire(): CmdReg: 0XFF RE|WE bits are not clear!!
>> [  947.491916] 
>> [  947.498375] Pid: 1350, comm: kworker/0:2 Tainted: G        WC  2.6.37-020637rc1-generic #201011020905
>> [  947.505177] Call Trace:
>> [  947.508561]  [<c014f90f>] panic+0x5f/0x190
>> [  947.511965]  [<e02ccd3f>] HwHSSIThreeWire+0x4f/0x270 [r8187se]
>> [  947.515424]  [<e02ccfd2>] RF_WriteReg+0x32/0x40 [r8187se]
>> [  947.518877]  [<e02cb29a>] rtl8225z2_rf_close+0x1a/0x50 [r8187se]
>> [  947.522384]  [<e02dd885>] rtl8180_pci_remove+0x45/0x107 [r8187se]
>> [  947.525861]  [<c0420206>] ? __pm_runtime_resume+0x46/0x60
>> [  947.529347]  [<c038372a>] pci_device_remove+0
>
> Thanks for the netconsole output. That helps a lot.
>
> The warning in remove_proc_entry() is essentially harmless. I'll take care of
> that later.
>
> The driver should never panic over a condition as trivial as the RE/WE bits are
> not zero. I missed that when I worked on the original version of the driver. As
> the bits are all 1, it appears that the device is partially disabled before this
> code is reached. One thing I notice is that there is no lock around the
> unregister_netdevice() call.
>
> Attached are two patches. One changes the panic statements into log entries with
> a stack dump, and the second provides a lock for the call noted above. The first
> patch cannot cause any problems; however, the second may cause the machine to
> freeze. At least with the first, the system will no longer crash.
>
> While you are testing these, I'll try to sort out why there is a warning in
> remove_proc_entry().
>
> Larry
>
>
>
>
> --------------070405020109010304050501
> Content-Type: text/plain;
>  name="rtl8187se_change_panic_to_warn"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: attachment;
>  filename="rtl8187se_change_panic_to_warn"
>
> Index: linux-2.6/drivers/staging/rtl8187se/r8185b_init.c
>===================================================================
> --- linux-2.6.orig/drivers/staging/rtl8187se/r8185b_init.c
> +++ linux-2.6/drivers/staging/rtl8187se/r8185b_init.c
> @@ -264,8 +264,12 @@ HwHSSIThreeWire(
>  
>  			udelay(10);
>  		}
> -		if (TryCnt == TC_3W_POLL_MAX_TRY_CNT)
> -			panic("HwThreeWire(): CmdReg: %#X RE|WE bits are not clear!!\n", u1bTmp);
> +		if (TryCnt == TC_3W_POLL_MAX_TRY_CNT) {
> +			printk(KERN_ERR "rtl8187se: HwThreeWire(): CmdReg:"
> +			       " %#X RE|WE bits are not clear!!\n", u1bTmp);
> +			dump_stack();
> +			return 0;
> +		}
>  
>  		/* RTL8187S HSSI Read/Write Function */
>  		u1bTmp = read_nic_byte(dev, RF_SW_CONFIG);
> @@ -298,13 +302,23 @@ HwHSSIThreeWire(
>  				int idx;
>  				int ByteCnt = nDataBufBitCnt / 8;
>  								/* printk("%d\n",nDataBufBitCnt); */
> -				if ((nDataBufBitCnt % 8) != 0)
> -				panic("HwThreeWire(): nDataBufBitCnt(%d) should be multiple of 8!!!\n",
> -				nDataBufBitCnt);
> -
> -			       if (nDataBufBitCnt > 64)
> -				panic("HwThreeWire(): nDataBufBitCnt(%d) should <= 64!!!\n",
> -				nDataBufBitCnt);
> +				if ((nDataBufBitCnt % 8) != 0) {
> +					printk(KERN_ERR "rtl8187se: "
> +					       "HwThreeWire(): nDataBufBitCnt(%d)"
> +					       " should be multiple of 8!!!\n",
> +					       nDataBufBitCnt);
> +					dump_stack();
> +					nDataBufBitCnt += 8;
> +					nDataBufBitCnt &= ~7;
> +				}
> +
> +			       if (nDataBufBitCnt > 64) {
> +					printk(KERN_ERR "rtl8187se: HwThreeWire():"
> +					       " nDataBufBitCnt(%d) should <= 64!!!\n",
> +					       nDataBufBitCnt);
> +					dump_stack();
> +					nDataBufBitCnt = 64;
> +				}
>  
>  				for (idx = 0; idx < ByteCnt; idx++)
>  					write_nic_byte(dev, (SW_3W_DB0+idx), *(pDataBuf+idx));
>
> --------------070405020109010304050501
> Content-Type: text/plain;
>  name="rtl8187se_lock_pci_remove"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: attachment;
>  filename="rtl8187se_lock_pci_remove"
>
> Index: linux-2.6/drivers/staging/rtl8187se/r8180_core.c
>===================================================================
> --- linux-2.6.orig/drivers/staging/rtl8187se/r8180_core.c
> +++ linux-2.6/drivers/staging/rtl8187se/r8180_core.c
> @@ -3656,12 +3656,15 @@ static void __devexit rtl8180_pci_remove
>  {
>  	struct r8180_priv *priv;
>  	struct net_device *dev = pci_get_drvdata(pdev);
> +	unsigned long flags;
>  
>  	if (dev) {
> -		unregister_netdev(dev);

Re: r8187se panic

[Larry Finger]

[-- Attachment #1: Type: text/plain, Size: 2550 bytes --]

On 11/12/2010 09:55 AM, Robie Basak wrote:
> Larry,
> 
> The patches have helped - thanks!
> 
> Failure case A:
>   1) Boot with AC power connected and wireless on
>   2) Switch wireless off
>   3) Kernel panic
> 
> With just the change_panic_to_warn patch, case A works fine now.
> However, the following sequence of events now causes some sort of
> infinite loop (with lots of stack traces in dmesg) instead of a hang
> like it did before:
> 
> Failure case B:
>   1) Boot with AC power connected and wireless on
>   2) Suspend
>   3) Resume (and Network Manager kicks in to reconnect etc)
>   4) Remove AC power
>   5) (wait a few seconds)
>   6) Some sort of loop with lots being dumped to dmesg, no wireless
> connection resumes
> 
> With the addition of the lock_pci_remove patch, case B goes away too.
> However, adding more to the failure case still causes problems:
> 
> Failure case C:
>   1) Boot with AC power connected and wireless on
>   2) Suspend
>   3) Resume (and Network Manager kicks in to reconnect etc)
>   4) Remove AC power
>   5) (wait a few seconds)
>   6) Restore AC power
>   7) (wireless disconnects; some sort of loop in dmesg; it does manage
> to associate at times but this never lasts long)
>   8) (network Manager gives up) but the loop in dmesg continues
>   9) Reloading the module and toggling the wireless switch seems to fix
>      it
> 
> Note that I can work around cases B and C by having
> SUSPEND_MODULES=r8187se in /etc/pm/config.d. The original problem does
> seem to be resolved. Case C also seems pretty non-deterministic. I can't
> reproduce it reliably. I have also managed to cause a hang using various
> combinations of switching AC power, suspend and the wireless switch but
> I haven't managed to reproduce it.
> 
> All of the stuff in dmesg I could see seems to be the same RE|WE bits
> not clear stack trace from your patch.
> 
> Does this help? Is there anything else I can do?

OK, we are making progress.

First of all, that locking patch that I sent is garbage. Throw it away.

I have fixed the problem with the remove_proc_entry() warning. See the attached
patch.

Apply the new patch and the "change panic to warning" patch and redo your case
B. Send me the dmesg output and a description of what happened. That data you
can send directly. No need to spam the list with the lengthy dmesg output.

I think my guess of a locking problem was correct, but turning IRQs off was not
the solution. I hope the stack dumps from the first patch will clue me as to the
source of the problem.

Larry

[-- Attachment #2: rtl8187se_fix_proc_entry_warning --]
[-- Type: text/plain, Size: 724 bytes --]

When the driver is unloaded, it generates a warning at fs/proc/generic.c:816.

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---

Index: linux-realtek/drivers/staging/rtl8187se/r8180_core.c
===================================================================
--- linux-realtek.orig/drivers/staging/rtl8187se/r8180_core.c
+++ linux-realtek/drivers/staging/rtl8187se/r8180_core.c
@@ -322,7 +322,7 @@ void rtl8180_proc_remove_one(struct net_
 		remove_proc_entry("stats-tx", priv->dir_dev);
 		remove_proc_entry("stats-rx", priv->dir_dev);
 		remove_proc_entry("registers", priv->dir_dev);
-		remove_proc_entry(dev->name, rtl8180_proc);
+//		remove_proc_entry(dev->name, rtl8180_proc);
 		priv->dir_dev = NULL;
 	}
 }

Re: r8187se panic

[Robie Basak]

On 2010-11-12, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> Apply the new patch and the "change panic to warning" patch and redo your case
> B. Send me the dmesg output and a description of what happened. That data you
> can send directly. No need to spam the list with the lengthy dmesg output.

OK this is with change_panic_to_warn and fix_proc_entry_warning. I
forgot to mention that I'm applying all these patches to Ubuntu's stock
10.10 kernel, since module symbols etc. come with the build - and then
just compiling the one kernel module and copying it over (not much space
or CPU power on the netbook and the keyboard is tiny!).

Behaviour is the same as case B from before. To clarify, after step 3 in
case B, wireless has always reconnected no problem. It is after a few
seconds after removing AC power that it loses connection (or perhaps it
takes a few seconds for Network Manager to notice). Once it has lost
connection it does seem to occasionally associate and then loses it
again (according to Network Manager).

Reloading the kernel module doesn't fix it, but then toggling the
wireless switch after the reload does.

I reproduced it a second time, this time not reloading the module but
just toggling the wireless switch afterwards. This seemed to fix it as
well, so it seems that reloading the module is not required.

(dmesg output sent directly to Larry)

Thanks,

Robie

Re: r8187se panic

[Larry Finger]

On 11/12/2010 11:00 AM, Robie Basak wrote:
> On 2010-11-12, Larry Finger <Larry.Finger@lwfinger.net> wrote:
>> Apply the new patch and the "change panic to warning" patch and redo your case
>> B. Send me the dmesg output and a description of what happened. That data you
>> can send directly. No need to spam the list with the lengthy dmesg output.
> 
> OK this is with change_panic_to_warn and fix_proc_entry_warning. I
> forgot to mention that I'm applying all these patches to Ubuntu's stock
> 10.10 kernel, since module symbols etc. come with the build - and then
> just compiling the one kernel module and copying it over (not much space
> or CPU power on the netbook and the keyboard is tiny!).
> 
> Behaviour is the same as case B from before. To clarify, after step 3 in
> case B, wireless has always reconnected no problem. It is after a few
> seconds after removing AC power that it loses connection (or perhaps it
> takes a few seconds for Network Manager to notice). Once it has lost
> connection it does seem to occasionally associate and then loses it
> again (according to Network Manager).
> 
> Reloading the kernel module doesn't fix it, but then toggling the
> wireless switch after the reload does.
> 
> I reproduced it a second time, this time not reloading the module but
> just toggling the wireless switch afterwards. This seemed to fix it as
> well, so it seems that reloading the module is not required.

What does the following log entry signify?

Nov 12 16:29:03 tiny kernel: [  160.306731]
=>>>>>>>>>>=============================>set power:0,0!

On my system, switching to battery does not affect the rtl8187se at all.

I will be working on a patch that improves the error handling of the read routines.

Larry

Re: r8187se panic

[Robie Basak]

On 2010-11-12, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> What does the following log entry signify?
>
> Nov 12 16:29:03 tiny kernel: [  160.306731]
>=>>>>>>>>>>=============================>set power:0,0!
>
> On my system, switching to battery does not affect the rtl8187se at all.

That is consistently showing up every time I switch from AC to battery
(but not battery to AC) while wireless is on. It does not appear if I
turn the wireless off, disconnect AC and then turn wireless on again.

Also for a suspend/resume cycle, it appears only if on battery and
wireless is on.

Robie

Re: r8187se panic

[James Womack]

Robie Basak <rb-oss-3@...> writes:

> 
> On 2010-11-12, Larry Finger <Larry.Finger@...> wrote:
> > What does the following log entry signify?
> >
> > Nov 12 16:29:03 tiny kernel: [  160.306731]
> >=>>>>>>>>>>=============================>set power:0,0!
> >
> > On my system, switching to battery does not affect the rtl8187se at all.
> 
> That is consistently showing up every time I switch from AC to battery
> (but not battery to AC) while wireless is on. It does not appear if I
> turn the wireless off, disconnect AC and then turn wireless on again.
> 
> Also for a suspend/resume cycle, it appears only if on battery and
> wireless is on.
> 
> Robie
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@...
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 


It's good to see that this problem is being examined closely. I have been living
with this issue on my EeePC 701SD for some time and it has been very
frustrating. I can confirm that the same issue Robie describes occur for my
701SD with r8187se wireless card (Fn+F2 causes a kernel panic when turning the
wireless card off -- this doesn't seem to occur when turning it on if the
netbook starts up with the wireless adapter off). This has occured in Ubuntu
versions 9.04 through to 10.10. I recently switched to Debian Squeeze (testing,
beta1), currently running 2.6.32-5-686 kernel and am experiencing an identical
problem. I'm not experienced in debugging this type of issue myself, but would
be happy to test any suggested fixes for the issue and report back results
(though you would need to advise as to how to do this and what to include in
replies).

Regards
James

Re: r8187se panic

[Larry Finger]

On 11/13/2010 12:18 PM, James Womack wrote:
> 
> It's good to see that this problem is being examined closely. I have been living
> with this issue on my EeePC 701SD for some time and it has been very
> frustrating. I can confirm that the same issue Robie describes occur for my
> 701SD with r8187se wireless card (Fn+F2 causes a kernel panic when turning the
> wireless card off -- this doesn't seem to occur when turning it on if the
> netbook starts up with the wireless adapter off). This has occured in Ubuntu
> versions 9.04 through to 10.10. I recently switched to Debian Squeeze (testing,
> beta1), currently running 2.6.32-5-686 kernel and am experiencing an identical
> problem. I'm not experienced in debugging this type of issue myself, but would
> be happy to test any suggested fixes for the issue and report back results
> (though you would need to advise as to how to do this and what to include in
> replies).

Testing would require that you have kernel source, apply the patches, and build
a new kernel with those included. On some distros, these steps are easier than
for others. Is your skill set up to this?

I will push the patch that changes the panic/crash into a simple warning with
the request that this be applied to stable. If/when this happens, you will have
that fix in your standard kernel. How long it takes will depend on the distro.

It is strange that I was not aware of this problem until Robie recently posted
in this list. Running the RTL8187SE on my computer has been a pain as the BIOS
in my computer does not have that device in its whitelist of approved devices.
As such, rebooting with it required that I shut down, remove the card, boot to
GRUB, and then hot-plug the card while being careful not to short it. That
changed in the past 2 days as I now have an ExpressCard to mini PCIe extender
that allows me to boot with the card installed. Unfortunately, I do not yet know
how to change the RFKILL setting with this device.

Larry

Re: r8187se panic

[James Womack]

On 13/11/10 18:44, Larry Finger wrote:
> On 11/13/2010 12:18 PM, James Womack wrote:
>>
>> It's good to see that this problem is being examined closely. I have been living
>> with this issue on my EeePC 701SD for some time and it has been very
>> frustrating. I can confirm that the same issue Robie describes occur for my
>> 701SD with r8187se wireless card (Fn+F2 causes a kernel panic when turning the
>> wireless card off -- this doesn't seem to occur when turning it on if the
>> netbook starts up with the wireless adapter off). This has occured in Ubuntu
>> versions 9.04 through to 10.10. I recently switched to Debian Squeeze (testing,
>> beta1), currently running 2.6.32-5-686 kernel and am experiencing an identical
>> problem. I'm not experienced in debugging this type of issue myself, but would
>> be happy to test any suggested fixes for the issue and report back results
>> (though you would need to advise as to how to do this and what to include in
>> replies).
>
> Testing would require that you have kernel source, apply the patches, and build
> a new kernel with those included. On some distros, these steps are easier than
> for others. Is your skill set up to this?
>
> I will push the patch that changes the panic/crash into a simple warning with
> the request that this be applied to stable. If/when this happens, you will have
> that fix in your standard kernel. How long it takes will depend on the distro.
>
> It is strange that I was not aware of this problem until Robie recently posted
> in this list. Running the RTL8187SE on my computer has been a pain as the BIOS
> in my computer does not have that device in its whitelist of approved devices.
> As such, rebooting with it required that I shut down, remove the card, boot to
> GRUB, and then hot-plug the card while being careful not to short it. That
> changed in the past 2 days as I now have an ExpressCard to mini PCIe extender
> that allows me to boot with the card installed. Unfortunately, I do not yet know
> how to change the RFKILL setting with this device.
>
> Larry
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
If building a kernel is as simple as building other programs from source 
(i.e. configure, make, make install), I could do that. I'm using Debian 
at the moment. Presumably I'd need a compiler of some kind, which I 
could obtain from the repos. I am not sure how one would apply patches 
to the kernel, however. Would I be able to compile a modified kernel and 
add this to grub whilst retaining the ability to boot in the unmodified 
kernel?

James

Re: r8187se panic

[Larry Finger]

On 11/13/2010 01:27 PM, James Womack wrote:
> If building a kernel is as simple as building other programs from source
> (i.e. configure, make, make install), I could do that. I'm using Debian
> at the moment. Presumably I'd need a compiler of some kind, which I
> could obtain from the repos. I am not sure how one would apply patches
> to the kernel, however. Would I be able to compile a modified kernel and
> add this to grub whilst retaining the ability to boot in the unmodified
> kernel?

It is similar to the process used with other programs. My distro is openSUSE and
the steps are to get the kernel source, the kernel development package, and the
patch utility using YaST. Other distros use emerge, apt-get, or similar
utilities. The easiest way to configure the kernel is to match the current one
using the compressed version in /proc/config.gz. You should end up with an
additional kernel in the GRUB menu that can be selected at boot time.

Larry

Re: r8187se panic

[James Womack]

On 13/11/10 20:02, Larry Finger wrote:
> On 11/13/2010 01:27 PM, James Womack wrote:
>> If building a kernel is as simple as building other programs from source
>> (i.e. configure, make, make install), I could do that. I'm using Debian
>> at the moment. Presumably I'd need a compiler of some kind, which I
>> could obtain from the repos. I am not sure how one would apply patches
>> to the kernel, however. Would I be able to compile a modified kernel and
>> add this to grub whilst retaining the ability to boot in the unmodified
>> kernel?
>
> It is similar to the process used with other programs. My distro is openSUSE and
> the steps are to get the kernel source, the kernel development package, and the
> patch utility using YaST. Other distros use emerge, apt-get, or similar
> utilities. The easiest way to configure the kernel is to match the current one
> using the compressed version in /proc/config.gz. You should end up with an
> additional kernel in the GRUB menu that can be selected at boot time.
>
> Larry
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
Okay, I've downloaded the necessary tools and extracted the kernel 
source. I have a tutorial on how to patch and build the kernel. Where 
should I apply your patches?

James

Re: r8187se panic

[Larry Finger]

On 11/14/2010 06:22 AM, James Womack wrote:
> Okay, I've downloaded the necessary tools and extracted the kernel
> source. I have a tutorial on how to patch and build the kernel. Where
> should I apply your patches?

Change directory to the main directory of the kernel source - the one with
subdirectories like arch, block, crypto, drivers, etc. Apply patches with a
command of the form

patch -p1 --dry-run < <nameofpatch>

If that works without any error, then leave out the "--dry-run" to apply the
patch. If/when it is necessary to remove the patch, adding a "-R" option will do
that.

When you build the kernel, you should do that as a normal user, not root. If the
source files are not owned by that user, you should do a chown on that tree
before starting.

Larry

Re: r8187se panic

[James Womack]

On 14/11/10 16:18, Larry Finger wrote:
> On 11/14/2010 06:22 AM, James Womack wrote:
>> Okay, I've downloaded the necessary tools and extracted the kernel
>> source. I have a tutorial on how to patch and build the kernel. Where
>> should I apply your patches?
>
> Change directory to the main directory of the kernel source - the one with
> subdirectories like arch, block, crypto, drivers, etc. Apply patches with a
> command of the form
>
> patch -p1 --dry-run<  <nameofpatch>
>
> If that works without any error, then leave out the "--dry-run" to apply the
> patch. If/when it is necessary to remove the patch, adding a "-R" option will do
> that.
>
> When you build the kernel, you should do that as a normal user, not root. If the
> source files are not owned by that user, you should do a chown on that tree
> before starting.
>
> Larry
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
Hey, I tried patching the kernel I downloaded, but the dry runs both 
presented errors detailed below:

james@mercury:/usr/src/linux-source-2.6.32$ patch -p1 --dry-run < 
/home/james/rtl8187se_change_panic_to_warn
patching file drivers/staging/rtl8187se/r8185b_init.c
Hunk #1 succeeded at 356 with fuzz 2 (offset 92 lines).
Hunk #2 FAILED at 302.
1 out of 2 hunks FAILED -- saving rejects to file 
drivers/staging/rtl8187se/r8185b_init.c.rej
james@mercury:/usr/src/linux-source-2.6.32$ patch -p1 --dry-run < 
/home/james/rtl8187se_
rtl8187se_change_panic_to_warn  rtl8187se_lock_pci_remove
james@mercury:/usr/src/linux-source-2.6.32$ patch -p1 --dry-run < 
/home/james/rtl8187se_lock_pci_remove
patching file drivers/staging/rtl8187se/r8180_core.c
patch unexpectedly ends in middle of line
patch: **** unexpected end of file in patch
james@mercury:/usr/src/linux-source-2.6.32$

Do I need to do anything to the kernel source before applying the patches?

James

Re: r8187se panic

[James Womack]

On 12/11/10 13:06, Larry Finger wrote:
> On 11/12/2010 05:06 AM, Robie Basak wrote:
>> On 2010-11-12, Larry Finger<Larry.Finger@lwfinger.net>  wrote:
>>> On 11/11/2010 06:41 PM, Robie Basak wrote:
>>>> I'm getting a panic when I to turn off the wireless using the Fn-F2
>>>> combination on my Asus Eee PC 701SDX. Although I'm using Ubuntu 10.10,
>>>> I've tried it using the mainline kernel (as supplied by Ubuntu for
>>>> testing bugs against mainline). So far I've reproduced consistently
>>>> against Ubuntu's 2.6.35-22-generic-pae as well as Ubuntu-supplied
>>>> mainstream 2.6.35-02063504.201008271919 and
>>>> 2.6.37-020637rc1.201011020905.
>>>
>>> Is Fn-F2 the radio kill switch?
>>
>> Yes, that's right.
>>
>>> At this point, I see no point in building a mainstream kernel.
>>>
>>> Do you have another host that might be setup as a net console?
>>
>> Yes, I managed to get net console working (eventually):
>>
>> (the first four lines are from when I modprobed r8187se)
>>
>> [  941.787361] r8187se: module is from the staging directory, the quality is unknown, you have been warned.
>> [  941.821968] rtl8180_init:Error channel plan! Set to default.
>> [  941.825000] Dot11d_Init()
>> [  941.877241] r8180: WW:**PLEASE** REPORT SUCCESSFUL/UNSUCCESSFUL TO Realtek!
>> [  947.318002] ------------[ cut here ]------------
>> [  947.321315] WARNING: at /home/kernel-ppa/COD/linux/fs/proc/generic.c:816 remove_proc_entry+0x1e5/0x240()
>> [  947.328160] Hardware name: 701SDX
>> [  947.331607] name 'wlan0'
>> [  947.334987] Modules linked in: r8187se(C) netconsole eeprom_93cx6 parport_pc ppdev binfmt_misc snd_hda_codec_realtek snd_hda_intel i915 snd_hda_codec snd_hwdep snd_pcm drm_kms_helper joydev snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq drm snd_timer snd_seq_device intel_agp i2c_algo_bit intel_gtt snd psmouse eeepc_laptop video shpchp soundcore serio_raw agpgart sparse_keymap snd_page_alloc output led_class lp parport atl1e configfs [last unloaded: r8187se]
>> [  947.354968] Pid: 1350, comm: kworker/0:2 Tainted: G        WC  2.6.37-020637rc1-generic #201011020905
>> [  947.363331] Call Trace:
>> [  947.367541]  [<c02700d5>] ? remove_proc_entry+0x1e5/0x240
>
> --snip--
>
>> [  947.491911] Kernel panic - not syncing: HwThreeWire(): CmdReg: 0XFF RE|WE bits are not clear!!
>> [  947.491916]
>> [  947.498375] Pid: 1350, comm: kworker/0:2 Tainted: G        WC  2.6.37-020637rc1-generic #201011020905
>> [  947.505177] Call Trace:
>> [  947.508561]  [<c014f90f>] panic+0x5f/0x190
>> [  947.511965]  [<e02ccd3f>] HwHSSIThreeWire+0x4f/0x270 [r8187se]
>> [  947.515424]  [<e02ccfd2>] RF_WriteReg+0x32/0x40 [r8187se]
>> [  947.518877]  [<e02cb29a>] rtl8225z2_rf_close+0x1a/0x50 [r8187se]
>> [  947.522384]  [<e02dd885>] rtl8180_pci_remove+0x45/0x107 [r8187se]
>> [  947.525861]  [<c0420206>] ? __pm_runtime_resume+0x46/0x60
>> [  947.529347]  [<c038372a>] pci_device_remove+0
>
> Thanks for the netconsole output. That helps a lot.
>
> The warning in remove_proc_entry() is essentially harmless. I'll take care of
> that later.
>
> The driver should never panic over a condition as trivial as the RE/WE bits are
> not zero. I missed that when I worked on the original version of the driver. As
> the bits are all 1, it appears that the device is partially disabled before this
> code is reached. One thing I notice is that there is no lock around the
> unregister_netdevice() call.
>
> Attached are two patches. One changes the panic statements into log entries with
> a stack dump, and the second provides a lock for the call noted above. The first
> patch cannot cause any problems; however, the second may cause the machine to
> freeze. At least with the first, the system will no longer crash.
>
> While you are testing these, I'll try to sort out why there is a warning in
> remove_proc_entry().
>
> Larry
>
>
>
f

Re: r8187se panic

[Larry Finger]

[-- Attachment #1: Type: text/plain, Size: 1156 bytes --]

On 11/14/2010 12:49 PM, James Womack wrote:
> Hey, I tried patching the kernel I downloaded, but the dry runs both
> presented errors detailed below:
> 
> james@mercury:/usr/src/linux-source-2.6.32$ patch -p1 --dry-run <
> /home/james/rtl8187se_change_panic_to_warn
> patching file drivers/staging/rtl8187se/r8185b_init.c
> Hunk #1 succeeded at 356 with fuzz 2 (offset 92 lines).
> Hunk #2 FAILED at 302.
> 1 out of 2 hunks FAILED -- saving rejects to file
> drivers/staging/rtl8187se/r8185b_init.c.rej
> james@mercury:/usr/src/linux-source-2.6.32$ patch -p1 --dry-run <
> /home/james/rtl8187se_
> rtl8187se_change_panic_to_warn  rtl8187se_lock_pci_remove
> james@mercury:/usr/src/linux-source-2.6.32$ patch -p1 --dry-run <
> /home/james/rtl8187se_lock_pci_remove
> patching file drivers/staging/rtl8187se/r8180_core.c
> patch unexpectedly ends in middle of line
> patch: **** unexpected end of file in patch
> james@mercury:/usr/src/linux-source-2.6.32$
> 
> Do I need to do anything to the kernel source before applying the patches?

You needed a different version of the patch for 2.6.32. Apply the attached
version. You only need the one patch.

Larry

[-- Attachment #2: rtl8187se_change_panic_to_warn --]
[-- Type: text/plain, Size: 2213 bytes --]

This driver issues a kernel panic over conditions that do not
justify such drastic action. Change these to log entries with
a stack dump.

This patch fixes the system crash reported in
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/674285.

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Reported-and-Tested-by: Robie Basik <rb-oss-3@justgohome.co.uk>
Cc: Stable <stable@kernel.org>
---

Greg,

As this fix keeps the kernel from panicking over a trivial condition,
it should be pushed as soon as possible.

Larry
---

Index: linux-2.6/drivers/staging/rtl8187se/r8185b_init.c
===================================================================
--- linux-2.6.orig/drivers/staging/rtl8187se/r8185b_init.c
+++ linux-2.6/drivers/staging/rtl8187se/r8185b_init.c
@@ -356,8 +356,12 @@ HwHSSIThreeWire(
 			}
 			udelay(10);
 		}
-		if (TryCnt == TC_3W_POLL_MAX_TRY_CNT)
-			panic("HwThreeWire(): CmdReg: %#X RE|WE bits are not clear!!\n", u1bTmp);
+		if (TryCnt == TC_3W_POLL_MAX_TRY_CNT) {
+			printk(KERN_ERR "rtl8187se: HwThreeWire(): CmdReg:"
+			       " %#X RE|WE bits are not clear!!\n", u1bTmp);
+			dump_stack();
+			return 0;
+		}
 
 		// RTL8187S HSSI Read/Write Function
 		u1bTmp = read_nic_byte(dev, RF_SW_CONFIG);
@@ -397,13 +401,23 @@ HwHSSIThreeWire(
 				int idx;
 				int ByteCnt = nDataBufBitCnt / 8;
                                 //printk("%d\n",nDataBufBitCnt);
-				if ((nDataBufBitCnt % 8) != 0)
-				panic("HwThreeWire(): nDataBufBitCnt(%d) should be multiple of 8!!!\n",
-				nDataBufBitCnt);
-
-			       if (nDataBufBitCnt > 64)
-				panic("HwThreeWire(): nDataBufBitCnt(%d) should <= 64!!!\n",
-				nDataBufBitCnt);
+				if ((nDataBufBitCnt % 8) != 0) {
+					printk(KERN_ERR "rtl8187se: "
+					       "HwThreeWire(): nDataBufBitCnt(%d)"
+					       " should be multiple of 8!!!\n",
+					       nDataBufBitCnt);
+					dump_stack();
+					nDataBufBitCnt += 8;
+					nDataBufBitCnt &= ~7;
+				}
+
+			       if (nDataBufBitCnt > 64) {
+					printk(KERN_ERR "rtl8187se: HwThreeWire():"
+					       " nDataBufBitCnt(%d) should <= 64!!!\n",
+					       nDataBufBitCnt);
+					dump_stack();
+					nDataBufBitCnt = 64;
+				}
 
 				for(idx = 0; idx < ByteCnt; idx++)
 				{

Re: r8187se panic

[James Womack]

On 14/11/10 20:23, Larry Finger wrote:
> On 11/14/2010 12:49 PM, James Womack wrote:
>> Hey, I tried patching the kernel I downloaded, but the dry runs both
>> presented errors detailed below:
>>
>> james@mercury:/usr/src/linux-source-2.6.32$ patch -p1 --dry-run<
>> /home/james/rtl8187se_change_panic_to_warn
>> patching file drivers/staging/rtl8187se/r8185b_init.c
>> Hunk #1 succeeded at 356 with fuzz 2 (offset 92 lines).
>> Hunk #2 FAILED at 302.
>> 1 out of 2 hunks FAILED -- saving rejects to file
>> drivers/staging/rtl8187se/r8185b_init.c.rej
>> james@mercury:/usr/src/linux-source-2.6.32$ patch -p1 --dry-run<
>> /home/james/rtl8187se_
>> rtl8187se_change_panic_to_warn  rtl8187se_lock_pci_remove
>> james@mercury:/usr/src/linux-source-2.6.32$ patch -p1 --dry-run<
>> /home/james/rtl8187se_lock_pci_remove
>> patching file drivers/staging/rtl8187se/r8180_core.c
>> patch unexpectedly ends in middle of line
>> patch: **** unexpected end of file in patch
>> james@mercury:/usr/src/linux-source-2.6.32$
>>
>> Do I need to do anything to the kernel source before applying the patches?
>
> You needed a different version of the patch for 2.6.32. Apply the attached
> version. You only need the one patch.
>
> Larry

Hello,

I managed to compile the patched kernel. To confirm - the issue of the 
kernel panic occuring when Fn-F2 is used to turn off the wireless card 
is resolved. Thank you. I'll let you know if I notice any side effects 
from the patch.

James

Re: r8187se panic

[Larry Finger]

On 11/15/2010 03:05 PM, James Womack wrote:
> On 14/11/10 20:23, Larry Finger wrote:
>> On 11/14/2010 12:49 PM, James Womack wrote:
>>> Hey, I tried patching the kernel I downloaded, but the dry runs both
>>> presented errors detailed below:
>>>
>>> james@mercury:/usr/src/linux-source-2.6.32$ patch -p1 --dry-run<
>>> /home/james/rtl8187se_change_panic_to_warn
>>> patching file drivers/staging/rtl8187se/r8185b_init.c
>>> Hunk #1 succeeded at 356 with fuzz 2 (offset 92 lines).
>>> Hunk #2 FAILED at 302.
>>> 1 out of 2 hunks FAILED -- saving rejects to file
>>> drivers/staging/rtl8187se/r8185b_init.c.rej
>>> james@mercury:/usr/src/linux-source-2.6.32$ patch -p1 --dry-run<
>>> /home/james/rtl8187se_
>>> rtl8187se_change_panic_to_warn  rtl8187se_lock_pci_remove
>>> james@mercury:/usr/src/linux-source-2.6.32$ patch -p1 --dry-run<
>>> /home/james/rtl8187se_lock_pci_remove
>>> patching file drivers/staging/rtl8187se/r8180_core.c
>>> patch unexpectedly ends in middle of line
>>> patch: **** unexpected end of file in patch
>>> james@mercury:/usr/src/linux-source-2.6.32$
>>>
>>> Do I need to do anything to the kernel source before applying the
>>> patches?
>>
>> You needed a different version of the patch for 2.6.32. Apply the
>> attached
>> version. You only need the one patch.
>>
>> Larry
> 
> Hello,
> 
> I managed to compile the patched kernel. To confirm - the issue of the
> kernel panic occuring when Fn-F2 is used to turn off the wireless card
> is resolved. Thank you. I'll let you know if I notice any side effects
> from the patch.

After you do the Fn-F2 sequence, there should be a stack dump in the output of
the dmesg command. Could you please post that? With it, I should be able to find
what is leading to the original error. It does not happen on my system.

Larry

Re: r8187se panic

[James Womack]

On 15/11/10 23:44, Larry Finger wrote:
> On 11/15/2010 03:05 PM, James Womack wrote:
>> On 14/11/10 20:23, Larry Finger wrote:
>>> On 11/14/2010 12:49 PM, James Womack wrote:
>>>> Hey, I tried patching the kernel I downloaded, but the dry runs both
>>>> presented errors detailed below:
>>>>
>>>> james@mercury:/usr/src/linux-source-2.6.32$ patch -p1 --dry-run<
>>>> /home/james/rtl8187se_change_panic_to_warn
>>>> patching file drivers/staging/rtl8187se/r8185b_init.c
>>>> Hunk #1 succeeded at 356 with fuzz 2 (offset 92 lines).
>>>> Hunk #2 FAILED at 302.
>>>> 1 out of 2 hunks FAILED -- saving rejects to file
>>>> drivers/staging/rtl8187se/r8185b_init.c.rej
>>>> james@mercury:/usr/src/linux-source-2.6.32$ patch -p1 --dry-run<
>>>> /home/james/rtl8187se_
>>>> rtl8187se_change_panic_to_warn  rtl8187se_lock_pci_remove
>>>> james@mercury:/usr/src/linux-source-2.6.32$ patch -p1 --dry-run<
>>>> /home/james/rtl8187se_lock_pci_remove
>>>> patching file drivers/staging/rtl8187se/r8180_core.c
>>>> patch unexpectedly ends in middle of line
>>>> patch: **** unexpected end of file in patch
>>>> james@mercury:/usr/src/linux-source-2.6.32$
>>>>
>>>> Do I need to do anything to the kernel source before applying the
>>>> patches?
>>>
>>> You needed a different version of the patch for 2.6.32. Apply the
>>> attached
>>> version. You only need the one patch.
>>>
>>> Larry
>>
>> Hello,
>>
>> I managed to compile the patched kernel. To confirm - the issue of the
>> kernel panic occuring when Fn-F2 is used to turn off the wireless card
>> is resolved. Thank you. I'll let you know if I notice any side effects
>> from the patch.
>
> After you do the Fn-F2 sequence, there should be a stack dump in the output of
> the dmesg command. Could you please post that? With it, I should be able to find
> what is leading to the original error. It does not happen on my system.
>
> Larry
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Okay, I used dmesg | tail to print the last 10 lines of dmesg. Hopefully 
this is what you were asking for:

[  812.500300]  [<f81d97c1>] ? eeepc_rfkill_hotplug+0x127/0x142 
[eeepc_laptop]
[  812.500311]  [<c116a27d>] ? acpi_ev_notify_dispatch+0x4c/0x57
[  812.500320]  [<c115db60>] ? acpi_os_execute_deferred+0x1a/0x23
[  812.500330]  [<c103fc20>] ? worker_thread+0x142/0x1c2
[  812.500337]  [<c115db46>] ? acpi_os_execute_deferred+0x0/0x23
[  812.500347]  [<c104289e>] ? autoremove_wake_function+0x0/0x29
[  812.500354]  [<c103fade>] ? worker_thread+0x0/0x1c2
[  812.500362]  [<c1042680>] ? kthread+0x5f/0x64
[  812.500369]  [<c1042621>] ? kthread+0x0/0x64
[  812.500379]  [<c1003ca7>] ? kernel_thread_helper+0x7/0x10
[  812.700057] r8180: WW:Card reset timeout!
[  812.908439] r8180: Freeing irq 18
[  812.920050] r8180 0000:01:00.0: PCI INT A disabled
[  812.920056] r8180: wlan driver removed
[  812.920058]


Regards,
James

Re: r8187se panic

[Larry Finger]

On 11/16/2010 03:55 AM, James Womack wrote:
> On 15/11/10 23:44, Larry Finger wrote:
>> On 11/15/2010 03:05 PM, James Womack wrote:
>>> On 14/11/10 20:23, Larry Finger wrote:
>>>> On 11/14/2010 12:49 PM, James Womack wrote:
>>>>> Hey, I tried patching the kernel I downloaded, but the dry runs both
>>>>> presented errors detailed below:
>>>>>
>>>>> james@mercury:/usr/src/linux-source-2.6.32$ patch -p1 --dry-run<
>>>>> /home/james/rtl8187se_change_panic_to_warn
>>>>> patching file drivers/staging/rtl8187se/r8185b_init.c
>>>>> Hunk #1 succeeded at 356 with fuzz 2 (offset 92 lines).
>>>>> Hunk #2 FAILED at 302.
>>>>> 1 out of 2 hunks FAILED -- saving rejects to file
>>>>> drivers/staging/rtl8187se/r8185b_init.c.rej
>>>>> james@mercury:/usr/src/linux-source-2.6.32$ patch -p1 --dry-run<
>>>>> /home/james/rtl8187se_
>>>>> rtl8187se_change_panic_to_warn  rtl8187se_lock_pci_remove
>>>>> james@mercury:/usr/src/linux-source-2.6.32$ patch -p1 --dry-run<
>>>>> /home/james/rtl8187se_lock_pci_remove
>>>>> patching file drivers/staging/rtl8187se/r8180_core.c
>>>>> patch unexpectedly ends in middle of line
>>>>> patch: **** unexpected end of file in patch
>>>>> james@mercury:/usr/src/linux-source-2.6.32$
>>>>>
>>>>> Do I need to do anything to the kernel source before applying the
>>>>> patches?
>>>>
>>>> You needed a different version of the patch for 2.6.32. Apply the
>>>> attached
>>>> version. You only need the one patch.
>>>>
>>>> Larry
>>>
>>> Hello,
>>>
>>> I managed to compile the patched kernel. To confirm - the issue of the
>>> kernel panic occuring when Fn-F2 is used to turn off the wireless card
>>> is resolved. Thank you. I'll let you know if I notice any side effects
>>> from the patch.
>>
>> After you do the Fn-F2 sequence, there should be a stack dump in the
>> output of
>> the dmesg command. Could you please post that? With it, I should be
>> able to find
>> what is leading to the original error. It does not happen on my system.
>>
>> Larry
>> -- 
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-wireless" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 
> Okay, I used dmesg | tail to print the last 10 lines of dmesg. Hopefully
> this is what you were asking for:
> 
> [  812.500300]  [<f81d97c1>] ? eeepc_rfkill_hotplug+0x127/0x142
> [eeepc_laptop]
> [  812.500311]  [<c116a27d>] ? acpi_ev_notify_dispatch+0x4c/0x57
> [  812.500320]  [<c115db60>] ? acpi_os_execute_deferred+0x1a/0x23
> [  812.500330]  [<c103fc20>] ? worker_thread+0x142/0x1c2
> [  812.500337]  [<c115db46>] ? acpi_os_execute_deferred+0x0/0x23
> [  812.500347]  [<c104289e>] ? autoremove_wake_function+0x0/0x29
> [  812.500354]  [<c103fade>] ? worker_thread+0x0/0x1c2
> [  812.500362]  [<c1042680>] ? kthread+0x5f/0x64
> [  812.500369]  [<c1042621>] ? kthread+0x0/0x64
> [  812.500379]  [<c1003ca7>] ? kernel_thread_helper+0x7/0x10
> [  812.700057] r8180: WW:Card reset timeout!
> [  812.908439] r8180: Freeing irq 18
> [  812.920050] r8180 0000:01:00.0: PCI INT A disabled
> [  812.920056] r8180: wlan driver removed
> [  812.920058]

I need a few more than that. The sequence I want should start with the phrase
"RE|WE bits not cleared".

Larry

Re: r8187se panic

[James Womack]

>
> I need a few more than that. The sequence I want should start with the phrase
> "RE|WE bits not cleared".
>
> Larry
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

[ 3604.120086] rtl8187se: HwThreeWire(): CmdReg: 0XFF RE|WE bits are not 
clear!!
[ 3604.120099] Pid: 17, comm: kacpi_notify Tainted: G         C 
2.6.32-custom #1
[ 3604.120106] Call Trace:
[ 3604.120151]  [<f7ff67e9>] ? HwHSSIThreeWire+0x55/0x1fe [rtl8187se]
[ 3604.120176]  [<f7ff6ae8>] ? RF_WriteReg+0xb5/0xd7 [rtl8187se]
[ 3604.120198]  [<f7ff5391>] ? rtl8225z2_rf_close+0x12/0x3d [rtl8187se]
[ 3604.120216]  [<f800293f>] ? rtl8180_pci_remove+0x3e/0xdd [rtl8187se]
[ 3604.120231]  [<c11406cd>] ? pci_device_remove+0x16/0x35
[ 3604.120241]  [<c11aab79>] ? __device_release_driver+0x54/0x97
[ 3604.120249]  [<c11aac48>] ? device_release_driver+0x15/0x1e
[ 3604.120258]  [<c11aa2a9>] ? bus_remove_device+0x6e/0x7d
[ 3604.120265]  [<c11a907d>] ? device_del+0xf0/0x146
[ 3604.120273]  [<c11a90db>] ? device_unregister+0x8/0x10
[ 3604.120281]  [<c113ce42>] ? pci_stop_bus_device+0x42/0x60
[ 3604.120288]  [<c113cece>] ? pci_remove_bus_device+0xa/0x8e
[ 3604.120301]  [<f823c7c1>] ? eeepc_rfkill_hotplug+0x127/0x142 
[eeepc_laptop]
[ 3604.120312]  [<c116a27d>] ? acpi_ev_notify_dispatch+0x4c/0x57
[ 3604.120322]  [<c115db60>] ? acpi_os_execute_deferred+0x1a/0x23
[ 3604.120331]  [<c103fc20>] ? worker_thread+0x142/0x1c2
[ 3604.120339]  [<c115db46>] ? acpi_os_execute_deferred+0x0/0x23
[ 3604.120349]  [<c104289e>] ? autoremove_wake_function+0x0/0x29
[ 3604.120356]  [<c103fade>] ? worker_thread+0x0/0x1c2
[ 3604.120364]  [<c1042680>] ? kthread+0x5f/0x64
[ 3604.120371]  [<c1042621>] ? kthread+0x0/0x64
[ 3604.120381]  [<c1003ca7>] ? kernel_thread_helper+0x7/0x10
[ 3604.320072] r8180: WW:Card reset timeout!
[ 3604.528471] r8180: Freeing irq 18
[ 3604.537501] r8180 0000:01:00.0: PCI INT A disabled
[ 3604.537507] r8180: wlan driver removed
[ 3604.537509]

This should be sufficient, hopefully!

James

Re: r8187se panic

[Larry Finger]

On 11/16/2010 08:46 AM, James Womack wrote:

> This should be sufficient, hopefully!

Perfect.

Larry

Re: r8187se panic

[Rafał Miłecki]

2010/11/16 Larry Finger <Larry.Finger@lwfinger.net>:
> On 11/16/2010 08:46 AM, James Womack wrote:
>
>> This should be sufficient, hopefully!
>
> Perfect.

Would be nice if you could decide to talk privately or on ML ;)

James you do not use "Reply to all" for most of the discussion.

-- 
Rafał

Re: r8187se panic

[Larry Finger]

On 11/16/2010 09:08 AM, Rafał Miłecki wrote:
> 2010/11/16 Larry Finger <Larry.Finger@lwfinger.net>:
>> On 11/16/2010 08:46 AM, James Womack wrote:
>>
>>> This should be sufficient, hopefully!
>>
>> Perfect.
> 
> Would be nice if you could decide to talk privately or on ML ;)
> 
> James you do not use "Reply to all" for most of the discussion.

I want it to be on the mailing list. I didn't notice that James had sent it
privately, otherwise I would not have trimmed my reply so drasticly. For
completeness, the traceback is as follows:


[ 3604.120086] rtl8187se: HwThreeWire(): CmdReg: 0XFF RE|WE bits are not clear!!
[ 3604.120099] Pid: 17, comm: kacpi_notify Tainted: G         C 2.6.32-custom #1
[ 3604.120106] Call Trace:
[ 3604.120151]  [<f7ff67e9>] ? HwHSSIThreeWire+0x55/0x1fe [rtl8187se]
[ 3604.120176]  [<f7ff6ae8>] ? RF_WriteReg+0xb5/0xd7 [rtl8187se]
[ 3604.120198]  [<f7ff5391>] ? rtl8225z2_rf_close+0x12/0x3d [rtl8187se]
[ 3604.120216]  [<f800293f>] ? rtl8180_pci_remove+0x3e/0xdd [rtl8187se]
[ 3604.120231]  [<c11406cd>] ? pci_device_remove+0x16/0x35
[ 3604.120241]  [<c11aab79>] ? __device_release_driver+0x54/0x97
[ 3604.120249]  [<c11aac48>] ? device_release_driver+0x15/0x1e
[ 3604.120258]  [<c11aa2a9>] ? bus_remove_device+0x6e/0x7d
[ 3604.120265]  [<c11a907d>] ? device_del+0xf0/0x146
[ 3604.120273]  [<c11a90db>] ? device_unregister+0x8/0x10
[ 3604.120281]  [<c113ce42>] ? pci_stop_bus_device+0x42/0x60
[ 3604.120288]  [<c113cece>] ? pci_remove_bus_device+0xa/0x8e
[ 3604.120301]  [<f823c7c1>] ? eeepc_rfkill_hotplug+0x127/0x142 [eeepc_laptop]
[ 3604.120312]  [<c116a27d>] ? acpi_ev_notify_dispatch+0x4c/0x57
[ 3604.120322]  [<c115db60>] ? acpi_os_execute_deferred+0x1a/0x23
[ 3604.120331]  [<c103fc20>] ? worker_thread+0x142/0x1c2
[ 3604.120339]  [<c115db46>] ? acpi_os_execute_deferred+0x0/0x23
[ 3604.120349]  [<c104289e>] ? autoremove_wake_function+0x0/0x29
[ 3604.120356]  [<c103fade>] ? worker_thread+0x0/0x1c2
[ 3604.120364]  [<c1042680>] ? kthread+0x5f/0x64
[ 3604.120371]  [<c1042621>] ? kthread+0x0/0x64
[ 3604.120381]  [<c1003ca7>] ? kernel_thread_helper+0x7/0x10
[ 3604.320072] r8180: WW:Card reset timeout!
[ 3604.528471] r8180: Freeing irq 18
[ 3604.537501] r8180 0000:01:00.0: PCI INT A disabled
[ 3604.537507] r8180: wlan driver removed
[ 3604.537509]

Larry

Re: r8187se panic

[James Womack]

On 16/11/10 15:00, Larry Finger wrote:
> On 11/16/2010 08:46 AM, James Womack wrote:
>
>> This should be sufficient, hopefully!
>
> Perfect.
>
> Larry

Good. Thanks for fixing this issue. Do you have any idea when we could 
expect to see this fix incorporated into a mainstream kernel?

James

Re: r8187se panic

[Larry Finger]

On 11/16/2010 10:55 AM, James Womack wrote:
> On 16/11/10 15:00, Larry Finger wrote:
>> On 11/16/2010 08:46 AM, James Womack wrote:
>>
>>> This should be sufficient, hopefully!
>>
>> Perfect.
>>
>> Larry
> 
> Good. Thanks for fixing this issue. Do you have any idea when we could
> expect to see this fix incorporated into a mainstream kernel?

The fix to change the panic into a simple warning has been pushed upstream. If
GregKH, the staging maintainer, thinks it can go into 2.6.37, then the
backporting to stable will happen fairly quickly. If he decides it is too
invasive (not likely), then the patch will wait for ~2 months for 2.6.38. Once
in mainline, there will be some delay as the patch for 2.6.37 does not apply to
your kernel (2.6.32 as I recall), thus I will have to supply a revised version.
Once it is in 2.6.32.Y, then your disto will have to pick up the changes and
create an updated kernel. The wheels of change turn slowly - kernel stability is
extremely important.

My estimate would be 6 weeks at a minimum. Note that I still do not have a real
fix for the warning. That could take a long time to find, particularly as I
cannot duplicate the condition on my box. Long-range debugging is a very slow
process.

One other thing to note. I have a mac80211 version of the rtl8187se driver that
almost works. It is able to receive and transmit short packets. When a packet
longer than about 64 bytes is sent, the firmware locks up. I sent my source to
Realtek to see if they could see what I'm doing wrong. Their report is that the
driver is now working, but not stable. Once that driver is finished, it wil;l;
be submitted to mainline, and the version in staging will be dropped.

Larry