Greetings,
$subject appears (at glance) to happen because threads have already
exited when we get to BUG_ON(), I haven't pursued it though. Using
rt3070sta instead of rt2870sta works a treat with same box/adapter.
(the 2009_0521_RT2870_Linux_STA_V2.1.2.0 tree patches and rpm'd up for
opensuse-11.1 with kernels 27->29 doesn't BUG.. for 30 onward, I'm using
the in kernel staging drivers)
Box is el-cheapo (Aldi supermarket:) Q6600
lsusb: Bus 001 Device 003: ID 13d3:3247 IMC Networks 802.11 n/g/b Wireless LAN Adapter
Other than the BUG on shutdown, the thing works fine.
[ 962.934582] Terminate the TimerQThr pid=4557!
[ 962.934586] Terminate the MLMEThr pid=4554!
[ 962.934588] Terminate the RTUSBCmdThr pid=4556!
[ 962.940928] ---> RTMPFreeTxRxRingMemory
[ 962.944807] <--- ReleaseAdapter
drivers/staging/rt2870/../rt2860/sta_ioctl.c
1079 RT28XX_MLME_HANDLER(pAdapter);
drivers/staging/rt2870/rt2870.h
499 #define RT28XX_MLME_HANDLER(pAd) RTUSBMlmeUp(pAd)
586 #ifndef RT30xx
587 #define RTUSBMlmeUp(pAd) \
588 { \
589 POS_COOKIE pObj = (POS_COOKIE) pAd->OS_Cookie; \
590 BUG_ON(pObj->MLMEThr_task == NULL); \
591 CHECK_PID_LEGALITY(task_pid(pObj->MLMEThr_task)) \
592 up(&(pAd->mlme_semaphore)); \
593 }
[ 962.962117] ------------[ cut here ]------------
[ 962.966079] kernel BUG at drivers/staging/rt2870/../rt2860/sta_ioctl.c:1079!
[ 962.968800] invalid opcode: 0000 [#1] SMP
[ 962.968800] last sysfs file: /sys/devices/pci0000:00/0000:00:1a.7/usb1/1-5/net/wlan0/type
[ 962.985994] CPU 0
[ 962.985994] Modules linked in: xt_tcpudp xt_pkttype xt_limit snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device nfsd lockd nfs_acl auth_rpcgss sunrpc exportfs ip6t_REJECT nf_conntrack_ipv6 ip6table_raw xt_NOTRACK ipt_REJECT xt_state iptable_raw iptable_filter ip6table_mangle nf_conntrack_netbios_ns nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_tables ip6table_filter cpufreq_conservative ip6_tables cpufreq_ondemand cpufreq_userspace x_tables cpufreq_powersave acpi_cpufreq ipv6 microcode fuse loop dm_mod snd_hda_codec_realtek snd_hda_intel firewire_ohci snd_hda_codec firewire_core snd_hwdep crc_itu_t snd_pcm snd_timer snd usb_storage ohci1394 soundcore rtc_cmos i2c_i801 rt2870sta(C) sr_mod usb_libusual rtc_core snd_page_alloc ieee1394 i2c_core thermal e1000e cdrom intel_agp button processor rtc_lib sg usbhid hid ehci_hcd uhci_hcd sd_mod usbcore edd fan ext3 mbcache jbd ahci libata scsi_mod
[ 963.064503] Pid: 4752, comm: wpa_supplicant Tainted: G C 2.6.31-wireless-smp #78 MS-7502
[ 963.076503] RIP: 0010:[<ffffffffa0227043>] [<ffffffffa0227043>] rt_ioctl_siwscan+0x1ad/0x1d6 [rt2870sta]
[ 963.084502] RSP: 0018:ffff8800bf293bf8 EFLAGS: 00010246
[ 963.088502] RAX: 0000000000000000 RBX: ffffc900127c7000 RCX: 0000000000000000
[ 963.096503] RDX: 0000000000000508 RSI: 0000000000000508 RDI: ffffffffa01f6bca
[ 963.100505] RBP: ffff8800bf293c08 R08: 0000000000000000 R09: ffff8800bf293d48
[ 963.112503] R10: ffffffffa0226e96 R11: 0000000000000246 R12: 000000010002876c
[ 963.112503] R13: ffff8800bdcfca00 R14: ffffffff812c0730 R15: 0000000000008b18
[ 963.124502] FS: 00007fc25d6e36f0(0000) GS:ffff8800014e1000(0000) knlGS:0000000000000000
[ 963.124502] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 963.124502] CR2: 00007fc25d72a000 CR3: 00000000be091000 CR4: 00000000000006f0
[ 963.124502] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 963.124502] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 963.124502] Process wpa_supplicant (pid: 4752, threadinfo ffff8800bf292000, task ffff880037848660)
[ 963.124502] Stack:
[ 963.124502] 00000000fffffff4 ffff8800bf293de8 ffff8800bf293ca8 ffffffff8126a17e
[ 963.124502] <0> ffff8800bf293c98 ffff8800bf293d48 ffff8800378b6000 ffffffffa0226e96
[ 963.124502] <0> 0000000000000000 0000000000000000 0000000000001290 ffffffff00000000
[ 963.192503] Call Trace:
[ 963.196502] [<ffffffff8126a17e>] ioctl_standard_iw_point+0x198/0x227
[ 963.204503] [<ffffffffa0226e96>] ? rt_ioctl_siwscan+0x0/0x1d6 [rt2870sta]
[ 963.208503] [<ffffffff8126a2a2>] ioctl_standard_call+0x95/0xb4
[ 963.216505] [<ffffffff8126a3f7>] wext_ioctl_dispatch+0x9a/0x172
[ 963.220503] [<ffffffff81269f6d>] ? ioctl_private_call+0x0/0x79
[ 963.228503] [<ffffffff8126a20d>] ? ioctl_standard_call+0x0/0xb4
[ 963.234729] [<ffffffff8126a5ba>] wext_handle_ioctl+0x39/0x6f
[ 963.240503] [<ffffffff810ca59b>] ? core_sys_select+0x23d/0x270
[ 963.244503] [<ffffffff811f73ae>] dev_ioctl+0x60e/0x637
[ 963.252502] [<ffffffff811e6096>] sock_ioctl+0x217/0x226
[ 963.256502] [<ffffffff810c8614>] vfs_ioctl+0x2a/0x78
[ 963.256502] [<ffffffff810c8b75>] do_vfs_ioctl+0x498/0x4d9
[ 963.268502] [<ffffffff810c8c0b>] sys_ioctl+0x55/0x77
[ 963.268502] [<ffffffff8100ba6b>] system_call_fastpath+0x16/0x1b
[ 963.276503] Code: 00 00 00 00 00 00 4c 89 a3 90 19 00 00 ba 08 05 00 00 be 05 00 00 00 48 89 df e8 90 fa fc ff 48 8b 03 48 8b 40 08 48 85 c0 75 04 <0f> 0b eb fe 48 8b 80 00 02 00 00 48 85 c0 74 06 83 78 30 00 78
[ 963.292503] RIP [<ffffffffa0227043>] rt_ioctl_siwscan+0x1ad/0x1d6 [rt2870sta]
[ 963.304502] RSP <ffff8800bf293bf8>
[ 963.310285] ---[ end trace 292b4b823f542e3f ]---
On Thu, 2009-07-30 at 11:22 +0200, Mike Galbraith wrote:
> drivers/staging/rt2870/../rt2860/sta_ioctl.c
Sorry, but that '/staging/' thing in there means we cannot support this.
If you must, take your query to the staging list,
[email protected] (according to MAINTAINERS).
johannes
On Thu, 2009-07-30 at 11:29 +0200, Johannes Berg wrote:
> On Thu, 2009-07-30 at 11:22 +0200, Mike Galbraith wrote:
>
> > drivers/staging/rt2870/../rt2860/sta_ioctl.c
>
> Sorry, but that '/staging/' thing in there means we cannot support this.
> If you must, take your query to the staging list,
> [email protected] (according to MAINTAINERS).
Forwarded, thanks.
....hm. Does "If you must" mean reports aren't welcome?
-Mike
On Thu, 2009-07-30 at 11:44 +0200, Mike Galbraith wrote:
> On Thu, 2009-07-30 at 11:29 +0200, Johannes Berg wrote:
> > On Thu, 2009-07-30 at 11:22 +0200, Mike Galbraith wrote:
> >
> > > drivers/staging/rt2870/../rt2860/sta_ioctl.c
> >
> > Sorry, but that '/staging/' thing in there means we cannot support this.
> > If you must, take your query to the staging list,
> > [email protected] (according to MAINTAINERS).
>
> Forwarded, thanks.
>
> ....hm. Does "If you must" mean reports aren't welcome?
To be honest, I don't know. I'd rather see people use the rt2x00 code
instead of spending time cleaning up that mess (the code you've pasted
was pretty bad!). But you may or may not find somebody who cares about
that, just rather unlikely on this list.
johannes
On Thu, 2009-07-30 at 11:55 +0200, Johannes Berg wrote:
> On Thu, 2009-07-30 at 11:44 +0200, Mike Galbraith wrote:
> > On Thu, 2009-07-30 at 11:29 +0200, Johannes Berg wrote:
> > > On Thu, 2009-07-30 at 11:22 +0200, Mike Galbraith wrote:
> > >
> > > > drivers/staging/rt2870/../rt2860/sta_ioctl.c
> > >
> > > Sorry, but that '/staging/' thing in there means we cannot support this.
> > > If you must, take your query to the staging list,
> > > [email protected] (according to MAINTAINERS).
> >
> > Forwarded, thanks.
> >
> > ....hm. Does "If you must" mean reports aren't welcome?
>
> To be honest, I don't know. I'd rather see people use the rt2x00 code
> instead of spending time cleaning up that mess (the code you've pasted
> was pretty bad!). But you may or may not find somebody who cares about
> that, just rather unlikely on this list.
Understood (and yeah, the source is.. not pretty). Sorry for the noise.
WRT rt2x00 with this adapter, I tried it, was a nogo. If I find time,
I'll reconfigure/report.
-Mike (outta here;)
Hi Mike,
On Thu, Jul 30, 2009 at 10:55, Johannes Berg<[email protected]> wrote:
> On Thu, 2009-07-30 at 11:44 +0200, Mike Galbraith wrote:
>> On Thu, 2009-07-30 at 11:29 +0200, Johannes Berg wrote:
>> > On Thu, 2009-07-30 at 11:22 +0200, Mike Galbraith wrote:
>> >
>> > > drivers/staging/rt2870/../rt2860/sta_ioctl.c
>> >
>> > Sorry, but that '/staging/' thing in there means we cannot support this.
>> > If you must, take your query to the staging list,
>> > [email protected] (according to MAINTAINERS).
>>
>> Forwarded, thanks.
>>
>> ....hm. ?Does "If you must" mean reports aren't welcome?
>
> To be honest, I don't know. I'd rather see people use the rt2x00 code
> instead of spending time cleaning up that mess (the code you've pasted
> was pretty bad!). But you may or may not find somebody who cares about
> that, just rather unlikely on this list.
What is appreciated is people with time to compare both code paths,
and report some inconsistancies, specially about card initialization
and general handling.
To be hones, we, the rt2x00 team, find Ralink's code to be very
difficult to follow, and combersome most of the times.
But any help is welcome!
>
> johannes
>
Luis Correia
rt2x00 project admin
On Thu, 2009-07-30 at 12:05 +0200, Mike Galbraith wrote:
> On Thu, 2009-07-30 at 11:55 +0200, Johannes Berg wrote:
> > On Thu, 2009-07-30 at 11:44 +0200, Mike Galbraith wrote:
> > > On Thu, 2009-07-30 at 11:29 +0200, Johannes Berg wrote:
> > > > On Thu, 2009-07-30 at 11:22 +0200, Mike Galbraith wrote:
> > > >
> > > > > drivers/staging/rt2870/../rt2860/sta_ioctl.c
> > > >
> > > > Sorry, but that '/staging/' thing in there means we cannot support this.
> > > > If you must, take your query to the staging list,
> > > > [email protected] (according to MAINTAINERS).
> > >
> > > Forwarded, thanks.
> > >
> > > ....hm. Does "If you must" mean reports aren't welcome?
> >
> > To be honest, I don't know. I'd rather see people use the rt2x00 code
> > instead of spending time cleaning up that mess (the code you've pasted
> > was pretty bad!). But you may or may not find somebody who cares about
> > that, just rather unlikely on this list.
>
> Understood (and yeah, the source is.. not pretty). Sorry for the noise.
>
> WRT rt2x00 with this adapter, I tried it, was a nogo. If I find time,
> I'll reconfigure/report.
This is nogo with rt2x00 driver fwiw. Maybe some simple configuration
thing, but I'm having no luck getting the bugger to work.
[ 12.942335] phy0: Selected rate control algorithm 'minstrel'
[ 12.942440] Registered led device: rt2800usb-phy0::radio
[ 12.955279] Registered led device: rt2800usb-phy0::assoc
[ 12.968003] Registered led device: rt2800usb-phy0::quality
[ 12.981183] usbcore: registered new interface driver rt2800usb
[ 33.032056] rt2800usb 1-5:1.0: firmware: requesting rt2870.bin
[ 33.161552] input: rt2800usb as /devices/pci0000:00/0000:00:1a.7/usb1/1-5/1-5:1.0/input/input4
[ 33.347130] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 34.513078] eth0: no IPv6 routers present
[ 35.935289] wlan0: authenticate with AP 00:1a:4f:9a:d0:12
[ 35.937306] wlan0: authenticated
[ 35.937309] wlan0: associate with AP 00:1a:4f:9a:d0:12
[ 35.942551] wlan0: RX AssocResp from 00:1a:4f:9a:d0:12 (capab=0x411 status=0 aid=1)
[ 35.942555] wlan0: associated
[ 35.950948] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 37.314470] mtrr: base(0xd0000000) is not aligned on a size(0xff00000) boundary
[ 39.937271] wlan0: deauthenticated (Reason: 1)
[ 40.936521] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 1
[ 40.939152] wlan0 direct probe responded
[ 40.939155] wlan0: authenticate with AP 00:1a:4f:9a:d0:12
[ 40.941145] wlan0: authenticated
[ 40.941148] wlan0: associate with AP 00:1a:4f:9a:d0:12
[ 40.945904] wlan0: RX ReassocResp from 00:1a:4f:9a:d0:12 (capab=0x411 status=0 aid=1)
[ 40.945909] wlan0: associated
[ 44.947499] wlan0: deauthenticated (Reason: 1)
[ 45.944034] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 1
[ 45.946623] wlan0 direct probe responded
[ 45.946627] wlan0: authenticate with AP 00:1a:4f:9a:d0:12
[ 45.948744] wlan0: authenticated
[ 45.948747] wlan0: associate with AP 00:1a:4f:9a:d0:12
[ 45.953996] wlan0: RX ReassocResp from 00:1a:4f:9a:d0:12 (capab=0x411 status=0 aid=1)
[ 45.953999] wlan0: associated
[ 46.376015] wlan0: no IPv6 routers present
[ 49.947986] wlan0: deauthenticated (Reason: 1)
[ 50.944545] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 1
[ 50.947230] wlan0 direct probe responded
[ 50.947234] wlan0: authenticate with AP 00:1a:4f:9a:d0:12
[ 50.949219] wlan0: authenticated
[ 50.949222] wlan0: associate with AP 00:1a:4f:9a:d0:12
[ 50.954473] wlan0: RX ReassocResp from 00:1a:4f:9a:d0:12 (capab=0x411 status=0 aid=1)
[ 50.954477] wlan0: associated
[ 54.958220] wlan0: deauthenticated (Reason: 1)
[ 55.956527] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 1
[ 55.959137] wlan0 direct probe responded
[ 55.959140] wlan0: authenticate with AP 00:1a:4f:9a:d0:12
[ 55.961123] wlan0: authenticated
[ 55.961126] wlan0: associate with AP 00:1a:4f:9a:d0:12
[ 55.966502] wlan0: RX ReassocResp from 00:1a:4f:9a:d0:12 (capab=0x411 status=0 aid=1)
[ 55.966505] wlan0: associated
[ 59.968460] wlan0: deauthenticated (Reason: 1)
[ 60.968032] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 1
[ 60.970625] wlan0 direct probe responded
[ 60.970628] wlan0: authenticate with AP 00:1a:4f:9a:d0:12
[ 60.972741] wlan0: authenticated
[ 60.972743] wlan0: associate with AP 00:1a:4f:9a:d0:12
[ 60.978499] wlan0: RX ReassocResp from 00:1a:4f:9a:d0:12 (capab=0x411 status=0 aid=1)
[ 60.978502] wlan0: associated
[ 64.978212] wlan0: deauthenticated (Reason: 1)
[ 65.976524] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 1
[ 65.979117] wlan0 direct probe responded
[ 65.979119] wlan0: authenticate with AP 00:1a:4f:9a:d0:12
[ 65.981120] wlan0: authenticated
[ 65.981124] wlan0: associate with AP 00:1a:4f:9a:d0:12
[ 65.986501] wlan0: RX ReassocResp from 00:1a:4f:9a:d0:12 (capab=0x411 status=0 aid=1)
[ 65.986505] wlan0: associated
[ 69.988830] wlan0: deauthenticated (Reason: 1)
[ 70.988546] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 1
[ 70.991121] wlan0 direct probe responded
[ 70.991124] wlan0: authenticate with AP 00:1a:4f:9a:d0:12
[ 70.993237] wlan0: authenticated
[ 70.993239] wlan0: associate with AP 00:1a:4f:9a:d0:12
[ 70.998494] wlan0: RX ReassocResp from 00:1a:4f:9a:d0:12 (capab=0x411 status=0 aid=1)
[ 70.998498] wlan0: associated
[ 74.998070] wlan0: deauthenticated (Reason: 1)
[ 75.996510] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 1
[ 75.999123] wlan0 direct probe responded
[ 75.999127] wlan0: authenticate with AP 00:1a:4f:9a:d0:12
[ 76.001239] wlan0: authenticated
[ 76.001242] wlan0: associate with AP 00:1a:4f:9a:d0:12
[ 76.006745] wlan0: RX ReassocResp from 00:1a:4f:9a:d0:12 (capab=0x411 status=0 aid=1)
[ 76.006749] wlan0: associated
[ 80.007943] wlan0: deauthenticated (Reason: 1)
[ 81.008508] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 1
[ 81.011115] wlan0 direct probe responded
[ 81.011118] wlan0: authenticate with AP 00:1a:4f:9a:d0:12
[ 81.013111] wlan0: authenticated
[ 81.013115] wlan0: associate with AP 00:1a:4f:9a:d0:12
[ 81.018494] wlan0: RX ReassocResp from 00:1a:4f:9a:d0:12 (capab=0x411 status=0 aid=1)
[ 81.018498] wlan0: associated
[ 85.017825] wlan0: deauthenticated (Reason: 1)
[ 86.016508] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 1
[ 86.019115] wlan0 direct probe responded
[ 86.019118] wlan0: authenticate with AP 00:1a:4f:9a:d0:12
[ 86.021230] wlan0: authenticated
[ 86.021233] wlan0: associate with AP 00:1a:4f:9a:d0:12
[ 86.026610] wlan0: RX ReassocResp from 00:1a:4f:9a:d0:12 (capab=0x411 status=0 aid=1)
[ 86.026613] wlan0: associated
[ 96.027614] wlan0: disassociating by local choice (reason=3)
[ 96.030483] wlan0: deauthenticated (Reason: 6)
[ 97.485736] wlan0: authenticate with AP 00:1a:4f:9a:d0:12
[ 97.487617] wlan0: authenticated
[ 97.487620] wlan0: associate with AP 00:1a:4f:9a:d0:12
[ 97.492871] wlan0: RX AssocResp from 00:1a:4f:9a:d0:12 (capab=0x411 status=0 aid=1)
[ 97.492875] wlan0: associated
[ 101.487940] wlan0: deauthenticated (Reason: 1)
[ 102.484011] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 1
[ 102.486625] wlan0 direct probe responded
[ 102.486629] wlan0: authenticate with AP 00:1a:4f:9a:d0:12
[ 102.488742] wlan0: authenticated
[ 102.488746] wlan0: associate with AP 00:1a:4f:9a:d0:12
[ 102.493993] wlan0: RX ReassocResp from 00:1a:4f:9a:d0:12 (capab=0x411 status=0 aid=1)
[ 102.493996] wlan0: associated
[ 112.496478] wlan0: disassociating by local choice (reason=3)
[ 112.499359] wlan0: deauthenticated (Reason: 6)
[ 123.951239] wlan0: authenticate with AP 00:1a:4f:9a:d0:12
[ 123.953248] wlan0: authenticated
[ 123.953252] wlan0: associate with AP 00:1a:4f:9a:d0:12
[ 123.958499] wlan0: RX AssocResp from 00:1a:4f:9a:d0:12 (capab=0x411 status=0 aid=1)
[ 123.958503] wlan0: associated
[ 127.957566] wlan0: deauthenticated (Reason: 1)
[ 128.956012] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 1
[ 128.958616] wlan0 direct probe responded
[ 128.958619] wlan0: authenticate with AP 00:1a:4f:9a:d0:12
[ 128.960743] wlan0: authenticated
[ 128.960746] wlan0: associate with AP 00:1a:4f:9a:d0:12
[ 128.966121] wlan0: RX ReassocResp from 00:1a:4f:9a:d0:12 (capab=0x411 status=0 aid=1)
[ 128.966125] wlan0: associated
[ 132.967815] wlan0: deauthenticated (Reason: 1)
[ 133.964011] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 1
[ 133.966613] wlan0 direct probe responded
[ 133.966616] wlan0: authenticate with AP 00:1a:4f:9a:d0:12
[ 133.968740] wlan0: authenticated
[ 133.968744] wlan0: associate with AP 00:1a:4f:9a:d0:12
[ 133.973868] wlan0: RX ReassocResp from 00:1a:4f:9a:d0:12 (capab=0x411 status=0 aid=1)
[ 133.973871] wlan0: associated
[ 137.967813] wlan0: deauthenticated (Reason: 1)
[ 138.964014] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 1
[ 138.966613] wlan0 direct probe responded
[ 138.966616] wlan0: authenticate with AP 00:1a:4f:9a:d0:12
[ 138.968738] wlan0: authenticated
[ 138.968741] wlan0: associate with AP 00:1a:4f:9a:d0:12
[ 138.973996] wlan0: RX ReassocResp from 00:1a:4f:9a:d0:12 (capab=0x411 status=0 aid=1)
[ 138.973999] wlan0: associated
[ 142.967685] wlan0: deauthenticated (Reason: 1)
[ 143.964009] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 1
[ 143.966609] wlan0 direct probe responded
[ 143.966612] wlan0: authenticate with AP 00:1a:4f:9a:d0:12
[ 143.968736] wlan0: authenticated
[ 143.968740] wlan0: associate with AP 00:1a:4f:9a:d0:12
[ 143.973988] wlan0: RX ReassocResp from 00:1a:4f:9a:d0:12 (capab=0x411 status=0 aid=1)
[ 143.973991] wlan0: associated
[ 147.967736] wlan0: deauthenticated (Reason: 1)
[ 148.964016] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 1
[ 148.966607] wlan0 direct probe responded
[ 148.966609] wlan0: authenticate with AP 00:1a:4f:9a:d0:12
[ 148.968734] wlan0: authenticated
[ 148.968736] wlan0: associate with AP 00:1a:4f:9a:d0:12
[ 148.973983] wlan0: RX ReassocResp from 00:1a:4f:9a:d0:12 (capab=0x411 status=0 aid=1)
[ 148.973985] wlan0: associated
[ 152.967813] wlan0: deauthenticated (Reason: 1)
[ 153.964009] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 1
[ 154.164015] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 2
[ 154.364015] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 3
[ 154.564009] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 timed out
[ 181.899242] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 1
[ 182.096012] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 2
[ 182.296011] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 3
[ 182.496011] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 timed out
[ 200.602027] usbcore: deregistering interface driver rt2800usb
Hi,
On Thursday 30 July 2009 12:06:00 Luis Correia wrote:
> Hi Mike,
>
> On Thu, Jul 30, 2009 at 10:55, Johannes Berg<[email protected]> wrote:
> > On Thu, 2009-07-30 at 11:44 +0200, Mike Galbraith wrote:
> >> On Thu, 2009-07-30 at 11:29 +0200, Johannes Berg wrote:
> >> > On Thu, 2009-07-30 at 11:22 +0200, Mike Galbraith wrote:
> >> >
> >> > > drivers/staging/rt2870/../rt2860/sta_ioctl.c
> >> >
> >> > Sorry, but that '/staging/' thing in there means we cannot support this.
> >> > If you must, take your query to the staging list,
> >> > [email protected] (according to MAINTAINERS).
> >>
> >> Forwarded, thanks.
> >>
> >> ....hm. Does "If you must" mean reports aren't welcome?
> >
> > To be honest, I don't know. I'd rather see people use the rt2x00 code
> > instead of spending time cleaning up that mess (the code you've pasted
> > was pretty bad!). But you may or may not find somebody who cares about
> > that, just rather unlikely on this list.
rt2800pci which I would need for my Asus Eee 901 is not even ready for
the upstream inclusion (after a year or so since Ralink's driver has been
released).
The sad reality is that some vendors have discovered "the loophole" in
the current kernel development model and are using it. Pretending that
the GPL-ed-but-fugly _working_ drivers do not exist is not an answer!
[ Especially not in the long-term (I think thank the support for the newest
generation of Ralink chipsets will probably also be based on more-or-less
the same code base). ]
Users are pragmatic beasts and don't care about "proper" code. They are
just using what works "good enough" for them (i.e. if distribution ships
a slightly inferior solution to the official one nobody will bother with
the official one, now lets think about the incomplete official one..).
No, I don't have a good answer for the problem. However I think that we
should be looking for the real, long-term solution instead of pretending
that the issue doesn't exist.
> What is appreciated is people with time to compare both code paths,
> and report some inconsistancies, specially about card initialization
> and general handling.
You are talking about people who:
* are familiar with wireless networking and wireless drivers
* have ability to work with the ugly/complicated code
* have good code reading/review skills
* have a quite some free time in their hands
Well, good luck..
> To be hones, we, the rt2x00 team, find Ralink's code to be very
> difficult to follow, and combersome most of the times.
I completely agree but it _works_, rt2x00 does _not_.
> But any help is welcome!
I think that cleaning of vendor drivers is an indirect form of help to
rt2x00 team (by making the mess easier to read and comprehend) and not a
competition to rt2x00 project. rt2x00 code is of very high quality and
I'm impressed by the work done by you, Ivo and the rest of the team.
However I think that you will never able to out do the _vendor_ when it
comes to the support for their new devices and I find the idea of finding
highly skilled volunteers helping with the most difficult, tedious and
thankless parts of the work a bit over-optimistic.
I planned, and actually did write, a lengthy reply for this thread, when I completed the reply
I reconsidred and opted for this shorter reply. Every 2 or 3 months this discussion is started
again and I am f***ing tired of it, so excuse me but I am not going to throw myself into
this completely pointless discussion
What you are suggesting in your mail is something the rt2x00 project did for 5 years, we stopped
with that 4 months ago because it wasn't working out. Apparently you have more experience in this
matter so I hope you will find a way to make that solution work out.
If you want to maintain the legacy drivers then do it, start a new project and start maintaining
the code. I can forward you all the users with complains about the "good enough" drivers. It is
good to know that you apparently have the resources to maintain the old drivers.
Most people who are helping with the rt2800pci/usb drivers lack the required time to boost the driver
into such a state it can be widely adopted. But every time it amazes me that the people who want
to develop and have the time to do it, all want to jump on the old Ralink code... Apparently there
is some appeal to maintaining crap rather then helping to ship out proper drivers to the users.
But I'll shut up now, as I said this discussion is held every few months, so perhaps that when
the discussion is started again in a couple of months I am more interested in a lengthy reply.
Ivo
On Thu, 2009-07-30 at 18:52 +0200, Ivo van Doorn wrote:
> I planned, and actually did write, a lengthy reply for this thread, when I completed the reply
> I reconsidred and opted for this shorter reply. Every 2 or 3 months this discussion is started
> again and I am f***ing tired of it, so excuse me but I am not going to throw myself into
> this completely pointless discussion
>
> What you are suggesting in your mail is something the rt2x00 project did for 5 years, we stopped
> with that 4 months ago because it wasn't working out. Apparently you have more experience in this
> matter so I hope you will find a way to make that solution work out.
>
> If you want to maintain the legacy drivers then do it, start a new project and start maintaining
> the code. I can forward you all the users with complains about the "good enough" drivers. It is
> good to know that you apparently have the resources to maintain the old drivers.
> Most people who are helping with the rt2800pci/usb drivers lack the required time to boost the driver
> into such a state it can be widely adopted. But every time it amazes me that the people who want
> to develop and have the time to do it, all want to jump on the old Ralink code... Apparently there
> is some appeal to maintaining crap rather then helping to ship out proper drivers to the users.
>
> But I'll shut up now, as I said this discussion is held every few months, so perhaps that when
> the discussion is started again in a couple of months I am more interested in a lengthy reply.
Hohum. Please remove me from CC for any further discussion.
-Mike
On Thu, 2009-07-30 at 18:52 +0200, Ivo van Doorn wrote:
> [some text expressing his frustration]
This is exactly why I was against staging all the time. Now suddenly
"The Crap" seems like a viable alternative. WAKE UP PEOPLE. The code is
not useful. Just look at the code that Mike pasted into his email. That
alone should be enough to send cold shivers down your spine!
What staging has achieved here is giving the crap vendor code a
blessing, receiving it welcomingly and forgivingly instead of saying
"well screw you, go ahead and ship this to your users but don't ever say
you support Linux well" ... now even some hackers and just just "dumb
users" think that the crap in staging could possibly at some point
become useful code!
It won't. EVER. No matter _how_ much you clean it up, it will NEVER fit
into the code scheme that everything else wireless has adopted.
And, Bartlomiej, don't give me the straw-man argument of user support,
if all you cared about were users you could well have _distros_ ship the
crap. They don't want to, of course, support this, for good reason! As
long as the vendors don't wake up, and some people see The Crap as a
viable alternative, good hardware support will never become a reality.
Look what you've done, really! You've frustrated the only person (Ivo)
who cares about giving these devices _proper_ support to a point where
he's no longer really interested in it because he's always measured
against The Crap right away. And that's perfectly understandable!
Effectively, you're saying that while he may have done good work, you
don't care about it because it's not perfect. Mike at least was willing
to try rt2x00 and work with it.
And now you're coming out of the woods and claiming that The Crap
works?! When the thread started with how it crashed? Get real.
In the end, while the letters you typed into your email claim to say the
opposite, the message of your email is that nobody should care about
rt2x00 and that the vendor driver should remain the status quo. Well, in
that case, get lost, crawl into the staging list and at least don't
bother us with The Crap.
Such attitude is part of the problem, the other big part is that vendors
can now claim their hardware "has mainline Linux support (in the staging
area)" and nobody will be the wiser.
So how about you help work on it, or think about a solution instead?
johannes
On Thu, Jul 30, 2009 at 07:11:02PM +0200, Johannes Berg wrote:
> On Thu, 2009-07-30 at 18:52 +0200, Ivo van Doorn wrote:
>
> > [some text expressing his frustration]
>
> This is exactly why I was against staging all the time. Now suddenly
> "The Crap" seems like a viable alternative. WAKE UP PEOPLE. The code is
> not useful. Just look at the code that Mike pasted into his email. That
> alone should be enough to send cold shivers down your spine!
Hm, "useful" is in the eye of the beholder.
There is no driver in the mainline kernel tree for this device, so a
"normal" user has no chance of getting it working, right? That's why
-staging is working, there is a semi-working driver, and most
importantly, people willing to help out getting it working better.
The combination of the two is what works here.
So please, I understand your frustration on a lack of people helping out
with out-of-tree wireless drivers that don't quite work properly, but
please, that has NOTHING to do with the staging drivers.
Meanwhile, I'm off on the driver-devel list helping Mike fix this
problem, which seems simple enough to solve...
> What staging has achieved here is giving the crap vendor code a
> blessing, receiving it welcomingly and forgivingly instead of saying
> "well screw you, go ahead and ship this to your users but don't ever say
> you support Linux well" ... now even some hackers and just just "dumb
> users" think that the crap in staging could possibly at some point
> become useful code!
Odd, I don't seem to be giving anyone such a "blessing", you are reading
way too much into this. The fact is this vendor does code drops and
runs away all the time, despite the code being in the staging tree or
not. Without it in the staging tree users would be worse off, not
better, there is no pressure able to be applied here at all, so please
stop thinking that.
> It won't. EVER. No matter _how_ much you clean it up, it will NEVER fit
> into the code scheme that everything else wireless has adopted.
never say never, it will happen, just give us time :)
In the meanwhile, people like Bart and others are doing real work on
getting the staging code into shape and working for real users. Who are
you to tell them to not do such work?
thanks,
greg "i love crap" k-h
On Thu, 2009-07-30 at 10:26 -0700, Greg KH wrote:
> On Thu, Jul 30, 2009 at 07:11:02PM +0200, Johannes Berg wrote:
> > On Thu, 2009-07-30 at 18:52 +0200, Ivo van Doorn wrote:
> >
> > > [some text expressing his frustration]
> >
> > This is exactly why I was against staging all the time. Now suddenly
> > "The Crap" seems like a viable alternative. WAKE UP PEOPLE. The code is
> > not useful. Just look at the code that Mike pasted into his email. That
> > alone should be enough to send cold shivers down your spine!
>
> Hm, "useful" is in the eye of the beholder.
>
> There is no driver in the mainline kernel tree for this device, so a
> "normal" user has no chance of getting it working, right? That's why
> -staging is working, there is a semi-working driver, and most
> importantly, people willing to help out getting it working better.
>
> The combination of the two is what works here.
>
> So please, I understand your frustration on a lack of people helping out
> with out-of-tree wireless drivers that don't quite work properly, but
> please, that has NOTHING to do with the staging drivers.
>
> Meanwhile, I'm off on the driver-devel list helping Mike fix this
> problem, which seems simple enough to solve...
Except that the energy you're now investing in fixing this could have
gone into rt2x00, and we would come out ahead in the end. Instead, the
energy is sapped away by something that will *never* be mainlined.
Dan
> > What staging has achieved here is giving the crap vendor code a
> > blessing, receiving it welcomingly and forgivingly instead of saying
> > "well screw you, go ahead and ship this to your users but don't ever say
> > you support Linux well" ... now even some hackers and just just "dumb
> > users" think that the crap in staging could possibly at some point
> > become useful code!
>
> Odd, I don't seem to be giving anyone such a "blessing", you are reading
> way too much into this. The fact is this vendor does code drops and
> runs away all the time, despite the code being in the staging tree or
> not. Without it in the staging tree users would be worse off, not
> better, there is no pressure able to be applied here at all, so please
> stop thinking that.
>
> > It won't. EVER. No matter _how_ much you clean it up, it will NEVER fit
> > into the code scheme that everything else wireless has adopted.
>
> never say never, it will happen, just give us time :)
>
> In the meanwhile, people like Bart and others are doing real work on
> getting the staging code into shape and working for real users. Who are
> you to tell them to not do such work?
>
> thanks,
>
> greg "i love crap" k-h
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jul 30, 2009 at 02:04:43PM -0400, Dan Williams wrote:
> On Thu, 2009-07-30 at 10:26 -0700, Greg KH wrote:
> > On Thu, Jul 30, 2009 at 07:11:02PM +0200, Johannes Berg wrote:
> > > On Thu, 2009-07-30 at 18:52 +0200, Ivo van Doorn wrote:
> > >
> > > > [some text expressing his frustration]
> > >
> > > This is exactly why I was against staging all the time. Now suddenly
> > > "The Crap" seems like a viable alternative. WAKE UP PEOPLE. The code is
> > > not useful. Just look at the code that Mike pasted into his email. That
> > > alone should be enough to send cold shivers down your spine!
> >
> > Hm, "useful" is in the eye of the beholder.
> >
> > There is no driver in the mainline kernel tree for this device, so a
> > "normal" user has no chance of getting it working, right? That's why
> > -staging is working, there is a semi-working driver, and most
> > importantly, people willing to help out getting it working better.
> >
> > The combination of the two is what works here.
> >
> > So please, I understand your frustration on a lack of people helping out
> > with out-of-tree wireless drivers that don't quite work properly, but
> > please, that has NOTHING to do with the staging drivers.
> >
> > Meanwhile, I'm off on the driver-devel list helping Mike fix this
> > problem, which seems simple enough to solve...
>
> Except that the energy you're now investing in fixing this could have
> gone into rt2x00, and we would come out ahead in the end. Instead, the
> energy is sapped away by something that will *never* be mainlined.
On the contrary, I would have never spent any time working on rt2x00 :)
And are you trying to tell people _what_ to work on here? That's a
slippery slope...
thanks,
greg k-h