Re: Oops in kernel 2.6.32 when unloading ipw2100 (device_pm_remove+0x16)

"Daniele C." <[email protected]> Tue, 10 Nov 2009 11:28:38 +0100
Newsgroups gmane.linux.drivers.ipw2100.devel
Message-ID <[email protected]>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Zhu Yi ha scritto:
> On Tue, 2009-11-10 at 08:08 +0800, Daniele C. wrote:
>>
>> reinette chatre ha scritto:
>>> On Mon, 2009-11-09 at 01:31 -0800, Daniele C. wrote:
>>>
>>>> starting with kernel 2.6.32 I can no more unload the ipw2100 module, I get the attached oops.
>>>>
>>>> Is this a known bug? Any patch around or possibly in kernel patches queue?
>>> This looks like duplicate of
>>> http://thread.gmane.org/gmane.linux.kernel/901971, which is fixed with
>>> patch http://thread.gmane.org/gmane.linux.kernel/901971/focus=8445
>>> Unfortunately this patch caused a regression, see
>>> http://thread.gmane.org/gmane.linux.kernel.wireless.general/42112 and it
>>> was reverted.
>>>
>>> Perhaps you can try out that patch directly until the issue is resolved?
>>>
>> Hi Reinette,
>>
>> thanks for your reply. None of those hunks can patch the latest kernel (2.6.32-rc6); after close inspection they all seem to have been merged, except the one for ipw2200.c perhaps (which anyway is not relevant to my ipw2100).
>>
When I said "seem to have been merged", I mean not by my patching but by some other patch because the vanilla mainline kernel already contains most of that patch.

>> I would say this is a totally different and separate bug; does anybody knows what is called at device_pm_remove+0x16 ? I cannot guess where the bug is, it vaguely looks like a bad/non-uniform free mechanism.
>>
>> I also wonder why nobody else experienced this up to now (maybe this ipw2100 hardware is getting rare nowadays).
> 
> Try this one [1], it is for 32-rc6. I only tested it on 2200. But it
> should also fix 2100. Revert the previous patch first if it is not (ie.
> for pristine kernel).
> 
'git diff' is empty, so I am sure the kernel was not touched by previous patching. I grabbed the correct URL (http://marc.info/?l=linux-wireless&m=125775901909164&w=2) and this is the result of patch -p1:

- -------
patching file drivers/net/wireless/ipw2x00/ipw2100.c
Hunk #1 FAILED at 6325.
Hunk #2 FAILED at 6386.
2 out of 2 hunks FAILED -- saving rejects to file drivers/net/wireless/ipw2x00/ipw2100.c.rej
patching file drivers/net/wireless/ipw2x00/ipw2200.c
Hunk #1 succeeded at 11824 with fuzz 2 (offset 1 line).
Hunk #2 succeeded at 11876 with fuzz 2 (offset 2 lines).
patching file drivers/net/wireless/ipw2x00/libipw.h
Reversed (or previously applied) patch detected!  Assume -R? [n] n
Apply anyway? [n] n
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/net/wireless/ipw2x00/libipw.h.rej
patching file drivers/net/wireless/ipw2x00/libipw_module.c
Reversed (or previously applied) patch detected!  Assume -R? [n] n
Apply anyway? [n] n
Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file drivers/net/wireless/ipw2x00/libipw_module.c.rej
- -------

So now 'git diff' says:

- -------
diff --git a/drivers/net/wireless/ipw2x00/ipw2200.c b/drivers/net/wireless/ipw2x00/ipw2200.c
index 9b0f2c0..3d2fd9d 100644
- --- a/drivers/net/wireless/ipw2x00/ipw2200.c
+++ b/drivers/net/wireless/ipw2x00/ipw2200.c
@@ -11824,6 +11824,7 @@ static int __devinit ipw_pci_probe(struct pci_dev *pdev,
                                  "device (error %d).\n", err);
                        unregister_ieee80211(priv->ieee);
                        unregister_netdev(priv->net_dev);
+                       unregister_ieee80211(priv->ieee);
                        goto out_remove_sysfs;
                }
        }
@@ -11875,6 +11876,7 @@ static void __devexit ipw_pci_remove(struct pci_dev *pdev)
 
        unregister_ieee80211(priv->ieee);
        unregister_netdev(priv->net_dev);
+       unregister_ieee80211(priv->ieee);
 
        if (priv->rxq) {
                ipw_rx_queue_free(priv, priv->rxq);
- -------

As I said before, this seems the only chunk of your patch left out in mainline kernel, but I doubt that modifying the ipw2200 will affect the ipw2100.

I have disassembled the code reported in my oops log (see http://tinyurl.com/y8jjd6z) and I can see this code (giving offset 1, 'ndisasm -e 1 code.bin'):

- --------
00000000  363431            ss xor al,0x31
00000003  3431              xor al,0x31
00000005  3131              xor [bx+di],si
00000007  363338            xor di,[ss:bx+si]
0000000A  3031              xor [bx+di],dh
0000000C  3834              cmp [si],dh
0000000E  3230              xor dh,[bx+si]
00000010  3235              xor dh,[di]
00000012  3138              xor [bx+si],di
00000014  37                aaa
00000015  3139              xor [bx+di],di
00000017  3332              xor si,[bp+si]
00000019  3333              xor si,[bp+di]
0000001B  363134            xor [ss:si],si
0000001E  3232              xor dh,[bp+si]
00000020  3130              xor [bx+si],si
00000022  3134              xor [si],si
00000024  3131              xor [bx+di],si
00000026  3832              cmp [bp+si],dh
00000028  3030              xor [bx+si],dh
0000002A  3030              xor [bx+si],dh
0000002C  3833              cmp [bp+di],dh
0000002E  3133              xor [bp+di],si
00000030  37                aaa
00000031  3139              xor [bx+di],di
00000033  353138            xor ax,0x3831
00000036  3432              xor al,0x32
00000038  3032              xor [bp+si],dh
0000003A  353138            xor ax,0x3831
0000003D  37                aaa
0000003E  3139              xor [bx+di],di
00000040  3332              xor si,[bp+si]
00000042  3332              xor si,[bp+si]
00000044  3234              xor dh,[si]
00000046  3331              xor si,[bx+di]
00000048  3431              xor al,0x31
0000004A  3231              xor dh,[bx+di]
0000004C  3031              xor [bx+di],dh
0000004E  3339              xor di,[bx+di]
00000050  37                aaa
00000051  353838            xor ax,0x3838
00000054  3134              xor [si],si
00000056  31363738          xor [0x3837],si
0000005A  3831              cmp [bx+di],dh
0000005C  3339              xor di,[bx+di]
0000005E  3833              cmp [bp+di],dh
00000060  3932              cmp [bp+si],si
00000062  3133              xor [bp+di],si
00000064  37                aaa
00000065  3831              cmp [bx+di],dh
00000067  3431              xor al,0x31
00000069  3337              xor si,[bx]
0000006B  3130              xor [bx+si],si
0000006D  3133              xor [bp+di],si
0000006F  37                aaa
00000070  3637              ss aaa
00000072  3838              cmp [bx+si],bh
00000074  3133              xor [bp+di],si
00000076  37                aaa
00000077  3637              ss aaa
00000079  3932              cmp [bp+si],si
0000007B  3138              xor [bx+si],di
0000007D  3432              xor al,0x32
0000007F  3032              xor [bp+si],dh
00000081  353138            xor ax,0x3831
00000084  37                aaa
00000085  3139              xor [bx+di],di
00000087  3339              xor di,[bx+di]
00000089  3132              xor [bp+si],si	; crash here
0000008B  3333              xor si,[bp+di]	; or possibly here
0000008D  3232              xor dh,[bp+si]
0000008F  3831              cmp [bx+di],dh
00000091  3431              xor al,0x31
00000093  3231              xor dh,[bx+di]
- --------

I haven't understood if it is at 0x89 or 0x8B (oops says it is as 0x89 but I am disassembling with an offset of +1  here to correctly align the code), and anyway this looks like weird assembly to me. Some anti-injection stack protection code?

Thanks,
- --
  Daniele C.

> 
> Thanks,
> -yi
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJK+UBWAAoJEON28As9epPAxasIAJgnQdZ7zmm02tfTodsp4/n/
evY8Hv5HLx871ukOtNhnwxKM+AMfpbTEn3EU9DjAHHfsotBZsnQRK5xsc4EbVfvc
w4IU6Zlmr2nqBBs7WLOYZlPMNlWgXbcLzNI8czxikZFwjZcqn2rQWw2j+b6frMkr
Bv6uN8s1s7W0BbRlGckNAMAnQwXQQXaIE7w6HtVED8mjMFa0mJIlZL7SgmGU831b
8fjnOoDlabHp/QwmDnbHD25mwJInyES8GxGF0M97H7N+TNIb+EIdvM8+5dGJHoEi
Wsbrx+r5TSf1S4/WO7W5fP4Ic7MGw3Gck6bc0AyOvlSNuVxY/EZ884bQONRyx6I=
=O3Lm
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july