Bug 540589

it's much easier if you just attach the jpegs directly btw.

unless it affects more users/machines, I set this to !ship_stopper

This device is serviced by a staging driver, which are known to be of questionable quality. They're included in the upstream kernel in that condition with the understanding that they are for testing and cleaning up. There have been a number of fixes upstream but I'm not sure if the driver will work even in that condition.

Jiri, I'm going to attach two patches. The first will be the cumulative changes to the rt2860 driver upstream. The second will be my fixes to the driver to remove build warnings. Would you mind taking a quick look at the second?

James, no guarantees this will get the driver working for you, but it's worth a try.

Created attachment 327189 [details]
rt2860: Cumulative updates

 This patch contains the cumulative updates to the rt2860 driver in
 mainline.

Created attachment 327190 [details]
rt2860: use skb_set_tail_pointer

 This patch fixes the direct manipulation of skb->tail by the rt2860 driver.

Shouldn't also skb_tail_pointer be used whenever skb->tail is dereferenced? I see 2 cases of skb->tail dereferencing in rt_linux.c (and 1 in macro definition in rt_linux.h, but that is never used).

Yep. Of course. I must admit I was limiting my scope to gcc giving int-pointer conversion errors.

Created attachment 327447 [details]
rt2860: use skb_set_tail_pointer

This version addresses the use of ->tail in rt_linux.h. I didn't see the other ->tail occurrences you mentioned, though.

I was looking at the openSUSE-11.2 branch. Looking again, the other dereferences are fixed by the patch in comment 4 (which is not yet applied).

The last patch looks good.

Will you commit the patches to openSUSE-11.2?

Yep. I just wanted another set of eyes. Thanks!

Hi James, the updated kernel won't fix your installation issues (for obvious reasons). If you boot with brokenmodules=rt2860 and then continue the installation, you can install a KOTD kernel that contains the patched rt2860 driver. Alternatively, the next update will have these fixes automatically.

Please report back on whether it fixes your issue.

Update released for: kernel-debug, kernel-debug-base, kernel-debug-base-debuginfo, kernel-debug-debuginfo, kernel-debug-debugsource, kernel-debug-devel, kernel-debug-devel-debuginfo, kernel-default, kernel-default-base, kernel-default-base-debuginfo, kernel-default-debuginfo, kernel-default-debugsource, kernel-default-devel, kernel-default-devel-debuginfo, kernel-desktop, kernel-desktop-base, kernel-desktop-base-debuginfo, kernel-desktop-debuginfo, kernel-desktop-debugsource, kernel-desktop-devel, kernel-desktop-devel-debuginfo, kernel-pae, kernel-pae-base, kernel-pae-base-debuginfo, kernel-pae-debuginfo, kernel-pae-debugsource, kernel-pae-devel, kernel-pae-devel-debuginfo, kernel-source, kernel-source-vanilla, kernel-syms, kernel-trace, kernel-trace-base, kernel-trace-base-debuginfo, kernel-trace-debuginfo, kernel-trace-debugsource, kernel-trace-devel, kernel-trace-devel-debuginfo, kernel-vanilla, kernel-vanilla-base, kernel-vanilla-base-debuginfo, kernel-vanilla-debuginfo, kernel-vanilla-debugsource, kernel-vanilla-devel, kernel-vanilla-devel-debuginfo, kernel-xen, kernel-xen-base, kernel-xen-base-debuginfo, kernel-xen-debuginfo, kernel-xen-debugsource, kernel-xen-devel, kernel-xen-devel-debuginfo, preload-kmp-default, preload-kmp-desktop
Products:
openSUSE 11.2 (debug, i586, x86_64)

Jeff, something bad went wrong with this patch when it was applied to the
kernel tree, we have lots of oops reports now.  See the kernel oops in bug #568307 for a detailed description of the problem.

*** Bug 568307 has been marked as a duplicate of this bug. ***

*** Bug 568446 has been marked as a duplicate of this bug. ***

Jiri, can you take another look at the patch from comment #8? I think I may have misunderstood what was going on there.

If I go back and re-read, I think instead of e.g.:
--- a/drivers/staging/rt2860/rt_linux.c
+++ b/drivers/staging/rt2860/rt_linux.c
@@ -598,8 +598,9 @@ PNDIS_PACKET ClonePacket(
        // set the correct dataptr and data len
        pClonedPkt->dev = pRxPkt->dev;
        pClonedPkt->data = pData;
+       pClonedPkt->head = pClonedPkt->data;
        pClonedPkt->len = DataSize;
-       pClonedPkt->tail = pClonedPkt->data + pClonedPkt->len;
+       skb_set_tail_pointer(pClonedPkt, pClonedPkt->len);
                ASSERT(DataSize < 1530);
        }
        return pClonedPkt;

... I should have pClonedPkt->head = pClonedPkt->data - pClonedPkt->len;

The crash documented in bnc#568307 is due to skb->data < skb->head, which would happen when, after the packet is cloned, an skb_push is done on it since skb->data would underflow by the amount pushed into the buffer.

Created attachment 336523 [details]
rt2860-use-skb_set_tail_pointer using pData's head

This patch uses the ->head that "pData" is derived from earlier in the call chain. I think this is right.

*** Bug 570557 has been marked as a duplicate of this bug. ***

(In reply to comment #16)
> ... I should have pClonedPkt->head = pClonedPkt->data - pClonedPkt->len;

Hm, yes, after some thinking I tend to agree. However, the driver is such a mess I'm not sure about anything anymore :-(

(In reply to comment #17)
> This patch uses the ->head that "pData" is derived from earlier in the call
> chain. I think this is right.

I'm not sure this is correct. RTPKT_TO_OSPKT(pRxPkt) and RTPKT_TO_OSPKT(pRxBlk->pRxPacket) is the same, because RTPKT_TO_OSPKT is just a cast to (struct sk_buff *) and
  pRxPkt = RTPKT_TO_OSPKT(pRxBlk->pRxPacket);
This makes the statement
  RTPKT_TO_OSPKT(pRxPkt)->head = RTPKT_TO_OSPKT(pRxBlk->pRxPacket)->head;
noop.

Unless I'm lost in the similarly looking identifiers. Which is quite possible.

I think we should try Jeff's approach, build a test kernel and ask some of the reporters of the panic to test.

(In reply to comment #19)
> (In reply to comment #16)
> > ... I should have pClonedPkt->head = pClonedPkt->data - pClonedPkt->len;
> 
> Hm, yes, after some thinking I tend to agree. However, the driver is such a
> mess I'm not sure about anything anymore :-(

I don't think that is correct. Isn't ->data + ->len == ->tail?

> (In reply to comment #17)
> > This patch uses the ->head that "pData" is derived from earlier in the call
> > chain. I think this is right.
> 
> I'm not sure this is correct. RTPKT_TO_OSPKT(pRxPkt) and
> RTPKT_TO_OSPKT(pRxBlk->pRxPacket) is the same, because RTPKT_TO_OSPKT is just a
> cast to (struct sk_buff *) and
>   pRxPkt = RTPKT_TO_OSPKT(pRxBlk->pRxPacket);
> This makes the statement
>   RTPKT_TO_OSPKT(pRxPkt)->head = RTPKT_TO_OSPKT(pRxBlk->pRxPacket)->head;
> noop.
> 
> Unless I'm lost in the similarly looking identifiers. Which is quite possible.

You are right, got lost in the ugliness. So, I think not touching ->head and ->tail in these cases is fine then because...

What they seem to be doing is a bad version of skb_pull(skb, pData - pRxPkt->data) because from the oops in attachment 334984 [details]:

STARxDoneInterruptHandle() does pRxBlk->pData = pRxPacket->data
STARxDoneInterruptHandle() does pHeader = (PHEADER_802_11) (pData+RXWI_SIZE) ;
STAHandleRxDataFrame() does pRxBlk->pData = (UCHAR *)pHeader;

And then these various functions that the patch fixes up are doing a bad version of skb_pull() to get the skb ->data to the pHeader location.

Does that make sense to other people?

Could someone with the hardware please install and test this Kernel? Setting NEEDINFO on James but anyone with the hardware can test it.

http://beta.suse.com/private/bphilips//540589/kernel-desktop-2.6.31.11-bnc540589.0.i586.rpm

This kernel boots on my machine, but the desktop kernel always did boot. I only observed this particular issue on the pae kernel during alpha/beta.

Of course, the RT2860 driver is still broken here since the last update, but that's another bug: #548265.

(In reply to comment #20)
> > (In reply to comment #16)
> > > ... I should have pClonedPkt->head = pClonedPkt->data - pClonedPkt->len;
> I don't think that is correct. Isn't ->data + ->len == ->tail?

Sure. I don't know what I was looking at. We should subtract the 802.11 headers length, not the data length. But after looking at a broader context...

> What they seem to be doing is a bad version of skb_pull(skb, pData -
> pRxPkt->data) because from the oops in attachment 334984 [details]:
> 
> STARxDoneInterruptHandle() does pRxBlk->pData = pRxPacket->data
> STARxDoneInterruptHandle() does pHeader = (PHEADER_802_11) (pData+RXWI_SIZE) ;
> STAHandleRxDataFrame() does pRxBlk->pData = (UCHAR *)pHeader;
> 
> And then these various functions that the patch fixes up are doing a bad
> version of skb_pull() to get the skb ->data to the pHeader location.

To pData, not pHeader, I would say. Yes, it indeed looks like skb_pull.

That means, just removing the ->head assignments from the Jeff's patch should fix the problem. Do you agree?

(In reply to comment #23)
> (In reply to comment #20)
> > > (In reply to comment #16)
> > > > ... I should have pClonedPkt->head = pClonedPkt->data - pClonedPkt->len;
> > I don't think that is correct. Isn't ->data + ->len == ->tail?
> 
> Sure. I don't know what I was looking at. We should subtract the 802.11 headers
> length, not the data length. But after looking at a broader context...
> 
> > What they seem to be doing is a bad version of skb_pull(skb, pData -
> > pRxPkt->data) because from the oops in attachment 334984 [details] [details]:
> > 
> > STARxDoneInterruptHandle() does pRxBlk->pData = pRxPacket->data
> > STARxDoneInterruptHandle() does pHeader = (PHEADER_802_11) (pData+RXWI_SIZE) ;
> > STAHandleRxDataFrame() does pRxBlk->pData = (UCHAR *)pHeader;
> > 
> > And then these various functions that the patch fixes up are doing a bad
> > version of skb_pull() to get the skb ->data to the pHeader location.
> 
> To pData, not pHeader, I would say. Yes, it indeed looks like skb_pull.
> 
> That means, just removing the ->head assignments from the Jeff's patch should
> fix the problem. Do you agree?

Yes, I agree, the head assignment doesn't look needed. I will build another pae Kernel with that change for testing soon.

It would really be nice to find someone that both get it to bit and see if the driver actually works.

Hi guys,

any chance of a preload-kmp-desktop package to be included with the next test kernel for this problem so i can test this on my 64bit machine with my rt2860sta wifi card. just can't afford with my normally system to be doing anything else but install by numbers or ill screw it up.

(In reply to comment #21)
> Could someone with the hardware please install and test this Kernel? Setting
> NEEDINFO on James but anyone with the hardware can test it.
> 
> http://beta.suse.com/private/bphilips//540589/kernel-desktop-2.6.31.11-bnc540589.0.i586.rpm

I have tested this kernel on my MSI Wind U-100 by connecting to a WLAN and disconnecting again a couple of times and was not able to reproduce the kernel panic any more.

*** Bug 548265 has been marked as a duplicate of this bug. ***

Not 100% sure as bugs are marked duplicated fast today.

I installed a KOTD kernel and the RT2860 driver again kills the system here in an eeepc901.

Reverting back to the latest (2.6.31.8) with the rt2860.ko file from .5 and it works. So it looks like the 2.6.31.11 of today is still affected.

I placed the .5 rt2860.ko file in .11 and all was OK.

(In reply to comment #24)
> Yes, I agree, the head assignment doesn't look needed. I will build another pae
> Kernel with that change for testing soon.
> 
> It would really be nice to find someone that both get it to bit and see if the
> driver actually works.

Kernel is building now. I will post soon when the new -pae Kernel is ready for testing. Thanks.

Created attachment 337495 [details]
rt2860-use-skb_set_tail_pointer without setting head

Patch checked into openSUSE-11.2

Kernel's for testing. Please give me feedback if you get a chance to test this out. Thanks!

http://beta.suse.com/private/bphilips/540589/kernel-pae-2.6.31.11-bnc540589.0.i586.rpm

http://beta.suse.com/private/bphilips/540589/kernel-desktop-2.6.31.11-bnc540589.0.i586.rpm

(In reply to comment #31)
> Kernel's for testing. Please give me feedback if you get a chance to test this
> out. Thanks!
> 
> http://beta.suse.com/private/bphilips/540589/kernel-pae-2.6.31.11-bnc540589.0.i586.rpm
> 
> http://beta.suse.com/private/bphilips/540589/kernel-desktop-2.6.31.11-bnc540589.0.i586.rpm

OK, I've tried the desktop kernel, and I found no kernel crah so far, however, only open SSIDs work, I was unable to connect to a WPA enterprise SSID. Here are some dmesg outputs:


##############################################################
Module load by killswitch:

pci 0000:01:00.0: reg 10 32bit mmio: [0x000000-0x00ffff]
pci 0000:01:00.0: PME# supported from D0 D3hot
pci 0000:01:00.0: PME# disabled
rt2860sta: module is from the staging directory, the quality is unknown, you have been warned.
rt2860 0000:01:00.0: enabling device (0000 -> 0002)
rt2860 0000:01:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
=== pAd = f8c33000, size = 585464 ===
<-- RTMPAllocAdapterBlock, Status=0
rt2860 0000:01:00.0: setting latency timer to 64
RX DESC dc97a000  size = 2048
<-- RTMPAllocTxRxRingMemory, Status=0
I/F(wlan0) Key1Str is Invalid key length! KeyLen = 0!
I/F(wlan0) Key2Str is Invalid key length! KeyLen = 0!
I/F(wlan0) Key3Str is Invalid key length! KeyLen = 0!
I/F(wlan0) Key4Str is Invalid key length! KeyLen = 0!
1. Phy Mode = 9
2. Phy Mode = 9
RTMPSetPhyMode: channel is out of range, use first channel=1
3. Phy Mode = 9
MCS Set = ff ff 00 00 01
<==== RTMPInitialize, Status=0
0x1300 = 00064300

##############################################################
Connection to open SSID:

===>rt_ioctl_giwscan. 6(6) BSS returned, data->length = 893
===>rt_ioctl_giwscan. 6(6) BSS returned, data->length = 893
===>rt_ioctl_giwscan. 6(6) BSS returned, data->length = 893
==>rt_ioctl_siwfreq::SIOCSIWFREQ[cmd=0x8b04] (Channel=1)
Rcv Wcid(1) AddBAReq
Start Seq = 00000733
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
Slow work thread pool: Starting up
Slow work thread pool: Ready
FS-Cache: Loaded
FS-Cache: Netfs 'nfs' registered for caching

##############################################################
During the connection (multiple sessions accumulated here):

===>rt_ioctl_giwscan. 7(7) BSS returned, data->length = 1060

===>rt_ioctl_giwscan. 5(5) BSS returned, data->length = 726
===>rt_ioctl_giwscan. 5(5) BSS returned, data->length = 726
==>rt_ioctl_siwfreq::SIOCSIWFREQ[cmd=0x8b04] (Channel=1)
Rcv Wcid(1) AddBAReq
Start Seq = 0000073d
===>rt_ioctl_giwscan. 6(6) BSS returned, data->length = 893

===>rt_ioctl_giwscan. 6(6) BSS returned, data->length = 893
===>rt_ioctl_giwscan. 6(6) BSS returned, data->length = 893
===>rt_ioctl_giwscan. 7(7) BSS returned, data->length = 1060
===>rt_ioctl_giwscan. 5(5) BSS returned, data->length = 726
===>rt_ioctl_giwscan. 4(4) BSS returned, data->length = 563
===>rt_ioctl_giwscan. 5(5) BSS returned, data->length = 726
===>rt_ioctl_giwscan. 6(6) BSS returned, data->length = 897
===>rt_ioctl_giwscan. 6(6) BSS returned, data->length = 893
===>rt_ioctl_giwscan. 6(6) BSS returned, data->length = 893
===>rt_ioctl_giwscan. 4(4) BSS returned, data->length = 563
===>rt_ioctl_giwscan. 6(6) BSS returned, data->length = 893

##############################################################
Disconnecting by killswitch (no crash!!!!):

ERROR!!! BBP read R66=0xffffffff fail
ERROR!!! BBP read R1=0xffffffff fail
ERROR!!! BBP write R1=0xffffffff fail
ERROR!!! H2M_MAILBOX still hold by MCU. command fail
ERROR!!! RTMPCancelTimer failed, Timer hasn't been initialize!
ERROR!!! H2M_MAILBOX still hold by MCU. command fail
ERROR!!! H2M_MAILBOX still hold by MCU. command fail
ERROR!!! BBP read R1=0xffffffff fail
ERROR!!! BBP write R1=0xffffffff fail
ERROR!!! H2M_MAILBOX still hold by MCU. command fail

##############################################################
Turning on again by killswitch:

pci 0000:01:00.0: reg 10 32bit mmio: [0x000000-0x00ffff]
pci 0000:01:00.0: PME# supported from D0 D3hot
pci 0000:01:00.0: PME# disabled
rt2860 0000:01:00.0: enabling device (0000 -> 0002)
rt2860 0000:01:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
=== pAd = f8dc1000, size = 585464 ===
<-- RTMPAllocAdapterBlock, Status=0
rt2860 0000:01:00.0: setting latency timer to 64
RX DESC d88bb000  size = 2048
<-- RTMPAllocTxRxRingMemory, Status=0
I/F(wlan0) Key1Str is Invalid key length! KeyLen = 0!
I/F(wlan0) Key2Str is Invalid key length! KeyLen = 0!
I/F(wlan0) Key3Str is Invalid key length! KeyLen = 0!
I/F(wlan0) Key4Str is Invalid key length! KeyLen = 0!
1. Phy Mode = 9
2. Phy Mode = 9
RTMPSetPhyMode: channel is out of range, use first channel=1
3. Phy Mode = 9
MCS Set = ff ff 00 00 01
<==== RTMPInitialize, Status=0
0x1300 = 00064300

##############################################################
Connecting to WPA-Enterprise unsuccessful :((((

===>rt_ioctl_giwscan. 7(7) BSS returned, data->length = 1060
===>rt_ioctl_giwscan. 7(7) BSS returned, data->length = 1060
===>rt_ioctl_giwscan. 7(7) BSS returned, data->length = 1060
==>rt_ioctl_siwfreq::SIOCSIWFREQ[cmd=0x8b04] (Channel=1)
===>rt_ioctl_giwscan. 7(7) BSS returned, data->length = 1060
==>rt_ioctl_siwfreq::SIOCSIWFREQ[cmd=0x8b04] (Channel=1)
===>rt_ioctl_giwscan. 7(7) BSS returned, data->length = 1060
==>rt_ioctl_siwfreq::SIOCSIWFREQ[cmd=0x8b04] (Channel=1)
===>rt_ioctl_giwscan. 6(6) BSS returned, data->length = 893
===>rt_ioctl_giwscan. 6(6) BSS returned, data->length = 893
==>rt_ioctl_siwfreq::SIOCSIWFREQ[cmd=0x8b04] (Channel=1)
===>rt_ioctl_giwscan. 6(6) BSS returned, data->length = 893
==>rt_ioctl_siwfreq::SIOCSIWFREQ[cmd=0x8b04] (Channel=1)
===>rt_ioctl_giwscan. 6(6) BSS returned, data->length = 893
===>rt_ioctl_giwscan. 6(6) BSS returned, data->length = 893
==>rt_ioctl_siwfreq::SIOCSIWFREQ[cmd=0x8b04] (Channel=6)
===>rt_ioctl_giwscan. 5(5) BSS returned, data->length = 730
==>rt_ioctl_siwfreq::SIOCSIWFREQ[cmd=0x8b04] (Channel=6)
===>rt_ioctl_giwscan. 6(6) BSS returned, data->length = 897
==>rt_ioctl_siwfreq::SIOCSIWFREQ[cmd=0x8b04] (Channel=6)
===>rt_ioctl_giwscan. 5(5) BSS returned, data->length = 730
==>rt_ioctl_siwfreq::SIOCSIWFREQ[cmd=0x8b04] (Channel=1)
===>rt_ioctl_giwscan. 4(4) BSS returned, data->length = 563
==>rt_ioctl_siwfreq::SIOCSIWFREQ[cmd=0x8b04] (Channel=1)
===>rt_ioctl_giwscan. 6(6) BSS returned, data->length = 893
===>rt_ioctl_giwscan. 6(6) BSS returned, data->length = 893

During unsuccessful WPA connection attempts wpa_supplicant says things like these:

kisgep:~ # cat /var/log/wpa_supplicant.log
CTRL-EVENT-SCAN-RESULTS
Trying to associate with 00:1d:70:92:ec:40 (SSID='eduroam' freq=2412 MHz)
Association request to the driver failed
Authentication with 00:1d:70:92:ec:40 timed out.
CTRL-EVENT-SCAN-RESULTS
Trying to associate with 00:1d:70:92:ec:40 (SSID='eduroam' freq=2412 MHz)
Association request to the driver failed
Authentication with 00:1d:70:92:ec:40 timed out.
CTRL-EVENT-SCAN-RESULTS
CTRL-EVENT-SCAN-RESULTS
Trying to associate with 00:1d:70:92:fd:40 (SSID='eduroam' freq=2437 MHz)
Association request to the driver failed
Authentication with 00:1d:70:92:fd:40 timed out.
CTRL-EVENT-SCAN-RESULTS
Trying to associate with 00:1d:70:92:fd:40 (SSID='eduroam' freq=2437 MHz)
Association request to the driver failed




However, I observed one successful WPA connection (out of approx. 10 attempts), so, it seems to prectically unusable with WPA. Open networks seems to be usable.

BTW, Asus has it's own linux distribution(?) for EeePC machines (AFAIK). What driver do they use?

Hi guys, I don't see any improvements in this kernel.
It works and does not crash but wireless doesn not works so well.

For me there's no differences between the follow kernels:
kernel-desktop-2.6.31.5-0.1.1.i586
kernel-desktop-2.6.32-41.3.i586
kernel-desktop-2.6.31.11-bnc540589.0.i586

I have to try serveral times before getting the connection works.
From wpa log:
Trying to associate with SSID '$MYSSID'
Association request to the driver failed
Authentication with 00:00:00:00:00:00 timed out.

bad mac addres..

Acer 2930z
wlan:
23: PCI 600.0: 0282 WLAN controller
  [Created at pci.318]
  UDI: /org/freedesktop/Hal/devices/pci_1814_781
  Unique ID: y9sn.1kY4T26Xa85
  Parent ID: Z7uZ.C0MkgLA2c85
  SysFS ID: /devices/pci0000:00/0000:00:1c.3/0000:06:00.0
  SysFS BusID: 0000:06:00.0
  Hardware Class: network
  Model: "RaLink RT2860"
  Vendor: pci 0x1814 "RaLink"
  Device: pci 0x0781 "RT2860"
  SubVendor: pci 0x105b "Foxconn International, Inc."
  SubDevice: pci 0xe002
  Driver: "rt2860"
  Driver Modules: "rt2860sta"
  Device File: wlan0
  Features: WLAN
  Memory Range: 0x95700000-0x9570ffff (rw,non-prefetchable)
  IRQ: 19 (no events)
  HW Address: 00:24:2c:0d:21:27
  Link detected: yes
  WLAN channels: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
  WLAN frequencies: 2.412 2.417 2.422 2.427 2.432 2.437 2.442 2.447 2.452 2.457 2.462 2.467 2.472 2.484
  WLAN encryption modes: WEP40 WEP104 TKIP CCMP
  WLAN authentication modes: open sharedkey wpa-psk wpa-eap
  Module Alias: "pci:v00001814d00000781sv0000105Bsd0000E002bc02sc80i00"
  Driver Info #0:
    Driver Status: rt2860sta is active
    Driver Activation Cmd: "modprobe rt2860sta"
  Config Status: cfg=no, avail=yes, need=no, active=unknown
  Attached to: #10 (PCI bridge)


This driver is a bit old, what about 2.2 ? Any chance to get it, maybe as kmp package ?

(In reply to comment #34)
> Hi guys, I don't see any improvements in this kernel.
> It works and does not crash but wireless doesn not works so well.

Are you kidding, that's a major improvement :)

Anything after this needs to be addressed in different bugs, as that is
an intermittent driver issue.
 
> This driver is a bit old, what about 2.2 ? Any chance to get it, maybe as kmp
> package ?

What do you mean "2.2"?  What are you referring to here?

I mean version-2.2.0 of the driver.
I rebuilded src downloaded from:
http://download.opensuse.org/repositories/home:/NicoK:/drivers/openSUSE_11.2/src/

But does not works. It hangs. So maybe the same fix is needed for that version too.

So before reporting bug against an old version, I'd rather try the latest one.

(In reply to comment #34)
> It works and does not crash but wireless doesn not works so well.

Thanks for testing. I think this solves this bug then and the patch is checked in for the next openSUSE 11.2 update.

If people are having problems with rt2860 driver besides crashing then please file a new bug after testing Kernel v2.6.33 from KOTD[1]. Please include hwinfo information and the result of testing v2.6.33 on the bug.

[1] http://ftp.suse.com/pub/projects/kernel/kotd/v2.6.33/

just for the record because I also ran into trouble with this today:
current 2.6.31.12-2 from Buildservice Kernel project works fine at least for me. However Ralink has released a new driver version on their website

Also for the record about the newest driver version (released 01-29-2010 V2.3.0.0)
From the release notes:
[2.3.0.0]

	1. Support PSP XLINK in ad-hoc mode.

	2. Support Linux Kernel 2.6.31/2.6.32.

So any older versions (1.8.1.1 in the current kernels) aren't supported it seems...

Update released for: kernel-debug, kernel-debug-base, kernel-debug-base-debuginfo, kernel-debug-debuginfo, kernel-debug-debugsource, kernel-debug-devel, kernel-debug-devel-debuginfo, kernel-default, kernel-default-base, kernel-default-base-debuginfo, kernel-default-debuginfo, kernel-default-debugsource, kernel-default-devel, kernel-default-devel-debuginfo, kernel-desktop, kernel-desktop-base, kernel-desktop-base-debuginfo, kernel-desktop-debuginfo, kernel-desktop-debugsource, kernel-desktop-devel, kernel-desktop-devel-debuginfo, kernel-pae, kernel-pae-base, kernel-pae-base-debuginfo, kernel-pae-debuginfo, kernel-pae-debugsource, kernel-pae-devel, kernel-pae-devel-debuginfo, kernel-source, kernel-source-vanilla, kernel-syms, kernel-trace, kernel-trace-base, kernel-trace-base-debuginfo, kernel-trace-debuginfo, kernel-trace-debugsource, kernel-trace-devel, kernel-trace-devel-debuginfo, kernel-vanilla, kernel-vanilla-base, kernel-vanilla-base-debuginfo, kernel-vanilla-debuginfo, kernel-vanilla-debugsource, kernel-vanilla-devel, kernel-vanilla-devel-debuginfo, kernel-xen, kernel-xen-base, kernel-xen-base-debuginfo, kernel-xen-debuginfo, kernel-xen-debugsource, kernel-xen-devel, kernel-xen-devel-debuginfo, preload-kmp-default, preload-kmp-desktop
Products:
openSUSE 11.2 (debug, i586, x86_64)