* Re: Current status of rt2800usb and staging/rt2870
From: Dan Williams @ 2009-10-13 20:15 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Ivo van Doorn, Ozan Çağlayan, linux-wireless,
linux-kernel
In-Reply-To: <200910132121.25743.bzolnier@gmail.com>
On Tue, 2009-10-13 at 21:21 +0200, Bartlomiej Zolnierkiewicz wrote:
> On Tuesday 13 October 2009 20:17:47 Ivo van Doorn wrote:
> > On Tuesday 13 October 2009, Bartlomiej Zolnierkiewicz wrote:
> > > On Tuesday 13 October 2009 17:52:52 Ivo van Doorn wrote:
> > >
> > > > I am going to merge rt2800pci soon as well and after that I'll send a patch
> > >
> > > Great, I've been waiting for this for a long time.
> > >
> > > > to remove all Ralink drivers from the staging tree.
> > >
> > > Till new drivers obtain support for all hardware currently covered by
> > > the unified staging drivers the latter shouldn't be removed as they
> > > serve well their role as a temporary solution allowing real Linux users
> > > to user their real hardware and as a reference material for developers
> > > willing to work on adding the missing bits to new drivers.
> >
> > The rt2800pci and rt2800usb drivers cover support for rt2860/rt2870/rt3070 devices,
> > which are present as individual drivers in the staging tree. So far it only managed
>
> There are no longer individual drivers.
>
> Instead there is one shared source code and two device drivers:
>
> - rt2860 covering RT2860 and RT3090 devices
>
> - rt2870 covering RT2870 and RT3070 devices
>
> In comparison rt2800usb currently lacks RT3070 support and rt2800pci's
> RT3090 support is basic at best (not to mention that it didn't work for
> RT2860 last time that I tried)..
>
> > to confuse developers which wanted to work on Ralink support, so I haven't found
>
> I bet they are truly grateful for being shown "the one and only way"..
There *is* only one way: mac80211. If the driver is softmac, but does
not use mac82011, then it *is* the wrong way. We will not have multiple
802.11 stacks in the mainstream kernel. If a softmac driver uses
mac80211, hey, that's great! Lets add it!
If it doesn't, then that driver needs to be updated to use mac80211.
Period.
> > a benefit for having those drivers in the staging tree yet. But I am sure there are plenty
>
> I was able to use my Eee 901 successfully with them for a last year and I'm
> pretty sure that I'm not the only. I understand my sin now -- I should have
> had help in fixing the proper and clean code before using my hardware.. [*]
That's nice, and everyone appreciates the work that you've done. Nobody
can tell you what to work on, but it would be nice to get more people
working on the *mac80211* versions of the various drivers. Imagine how
much better rt2x00 would be if all the effort that had gone into cleanup
up the ralink vendor drivers had instead gone into making rt2x00 work on
the new hardware. Then you'd have cfg80211 support, background
scanning, etc all for free with no effort on your part.
Maybe it would have taken 6 months longer to get good support for your
hardware but at least the work would have a future. But now we're stuck
in a situation where either:
1) the vendor driver never gets converted to cfg80211/mac80211, and
stays in staging forever, or finally gets booted out of staging because
nobody is working on converting it to mac80211. mac80211/cfg80211 is a
hard requirement for being an accepted wireless driver. And drivers do
have a shelf-life in staging.
2) the vendor driver starts getting converted to use mac80211. But I
would argue that a better use of *anyone's* time is to make rt2x00
better, instead of porting the ralink vendor drivers to mac80211. It
would probably take less time to fix up rt2x00 for new hardware than to
port the ralink vendor drivers to mac80211.
> > of people who like the idea of having the original Ralink drivers inside the staging tree,
> > so they can continue debugging that, so I won't talk about the staging downsides further.
>
> Well, it would be much more productive if people concentrate on improving
> _their_ projects and looking at downsides of _their_ code instead of going
> around and looking at _obvious_ downsides of other people's projects.
>
>
> [*] [Slightly off-topic but it shows the same problem with the approach]
>
> I now also see why some distributions keep pushing some known non-working
> things on their users (Fedora maintainers -- I'm talking to you), the best
> example is PulseAudio -- it simply doesn't work reliably even on modern
> hardware and/or using all scheduler tricks (it seems that making Linux into
> full RT OS is a prerequisite for fixing latency issues observed)..
Pulseaudio works for many, many people. The most productive use of your
time here is to file a bug report with the specific details of your
audio chipset, let upstream diagnose whether it's a Pulseaudio-specific
problem, a codec driver problem, or an ALSA problem.
You can wait until the cows come home to deploy new technology, and then
of course you'll still have to fix up all the bugs because you waited
too long and nobody was testing it, or you can deploy new technology
that works for most people and fix those bugs much earlier. Release
early, release often. The tricky thing is how early.
Dan
^ permalink raw reply
* Re: Current status of rt2800usb and staging/rt2870
From: Ozan Çağlayan @ 2009-10-13 20:41 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: linux-wireless, linux-kernel
In-Reply-To: <200910131844.58983.bzolnier@gmail.com>
Bartlomiej Zolnierkiewicz wrote:
> Hi,
>
> On Tuesday 13 October 2009 13:24:48 Ozan Çağlayan wrote:
>
>> Hi,
>>
>> In 2.6.31, there are USB device IDs common between both drivers. Should
>> a distribution enable both drivers? What do you suggest? Are there any
>> *known issues* stuff for one of them?
>>
>
> My advice to distributions for such situations is to ship both but make
> one driver the default one.
By saying to make one driver the default one, you mean avoiding the
other from getting probed automatically by clearing the device id tables?
^ permalink raw reply
* Re: 2.6.32-rc4 ipw2200: oops on missing firmware
From: Ferenc Wagner @ 2009-10-13 20:22 UTC (permalink / raw)
To: linux-kernel; +Cc: ipw2100-devel, linux-wireless, Reinette Chatre
In-Reply-To: <200910131855.25878.elendil@planet.nl>
Frans Pop <elendil@planet.nl> writes:
> Adding relevant CCs.
Thanks. Meanwhile I checked that the ipw2200 module can indeed be
removed and reinserted into the running system without problems,
here's the relevant part of dmesg:
[ 5837.082811] ipw2200: Firmware error detected. Restarting.
[ 5840.507981] ipw2200: Firmware error detected. Restarting.
[ 5886.248174] ipw2200 0000:02:02.0: PCI INT A disabled
[ 5919.283775] ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, 1.2.2kmprq
[ 5919.283782] ipw2200: Copyright(c) 2003-2006 Intel Corporation
[ 5919.283879] ipw2200 0000:02:02.0: PCI INT A -> Link[LNKF] -> GSI 11 (level, low) -> IRQ 11
[ 5919.285697] ipw2200: Detected Intel PRO/Wireless 2200BG Network Connection
[ 5919.285771] ipw2200 0000:02:02.0: firmware: requesting ipw2200-bss.fw
[ 5919.466323] ipw2200: Detected geography ZZR (14 802.11bg channels, 0 802.11a channels)
[ 5919.477923] udev: renamed network interface eth0 to wlan
[ 5982.543067] ipw2200: Firmware error detected. Restarting.
[ 5985.850947] ipw2200: Firmware error detected. Restarting.
[ 5989.170633] ipw2200: Firmware error detected. Restarting.
[ 5992.479084] ipw2200: Firmware error detected. Restarting.
[ 5995.786495] ipw2200: Firmware error detected. Restarting.
[ 5999.099022] ipw2200: Firmware error detected. Restarting.
[ 6003.193188] QoS Error need to parse QOS_PARAMETER IE
[ 6029.106407] ipw2200: Firmware error detected. Restarting.
[ 6032.415272] ipw2200: Firmware error detected. Restarting.
Yes, I continuously get firmware errors, and occasionally the QoS
error. I'm using firmware version 3.1, but these are probably
irrelevant for this bug report.
> Original message follows.
> ==============
> Hi,
>
> See the screenshot at http://apt.niif.hu/ipw_oops.png. During bootup,
> initramfs-tools tried to load the ipw2200 module, but nobody fed it
> the necessary firmware, so request_firmware timed out and the module
> unload cleanup oopsed in device_pm_remove:
>
> void device_pm_remove(struct device *dev)
> {
> pr_debug("PM: Removing info for %s:%s\n",
> dev->bus ? dev->bus->name : "No Bus",
> kobject_name(&dev->kobj));
> mutex_lock(&dpm_list_mtx);
> list_del_init(&dev->power.entry);
> mutex_unlock(&dpm_list_mtx);
> pm_runtime_remove(dev);
> }
>
> 00000a0a <device_pm_remove>:
> a0a: 55 push %ebp
> a0b: 89 e5 mov %esp,%ebp
> a0d: 53 push %ebx
> a0e: 89 c3 mov %eax,%ebx
> a10: b8 08 00 00 00 mov $0x8,%eax
> a15: e8 fc ff ff ff call a16 <device_pm_remove+0xc>
> a1a: 8d 4b 5c lea 0x5c(%ebx),%ecx
> a1d: 8b 53 5c mov 0x5c(%ebx),%edx
> a20: 8b 43 60 mov 0x60(%ebx),%eax
> a23: 89 42 04 mov %eax,0x4(%edx)
> a26: 89 10 mov %edx,(%eax)
> a28: 89 4b 5c mov %ecx,0x5c(%ebx)
> a2b: 89 4b 60 mov %ecx,0x60(%ebx)
> a2e: b8 08 00 00 00 mov $0x8,%eax
> a33: e8 fc ff ff ff call a34 <device_pm_remove+0x2a>
> a38: 89 d8 mov %ebx,%eax
> a3a: e8 fc ff ff ff call a3b <device_pm_remove+0x31>
> a3f: 5b pop %ebx
> a40: 5d pop %ebp
> a41: c3 ret
>
> The offending IP translates to line a23, so the problem is edx being 0
> at that point. I'm not sure which struct device field has offset
> 0x5c, maybe power, but I'm lost at this point anyway.
>
> I don't know whether it's a new bug or not, never did such insane
> things previously. rmmod ipw2200 definitely worked under 2.6.31, and
> it's possible that it works under 2.6.32-rc4 too, I forgot to check
> that (but will do so tonight).
>
> --
> Regards,
> Feri.
^ permalink raw reply
* Re: Current status of rt2800usb and staging/rt2870
From: Bartlomiej Zolnierkiewicz @ 2009-10-13 20:42 UTC (permalink / raw)
To: Ivo van Doorn; +Cc: Ozan Çağlayan, linux-wireless, linux-kernel
In-Reply-To: <200910132200.48569.IvDoorn@gmail.com>
On Tuesday 13 October 2009 22:00:48 Ivo van Doorn wrote:
> > > The rt2800pci and rt2800usb drivers cover support for rt2860/rt2870/rt3070 devices,
> > > which are present as individual drivers in the staging tree. So far it only managed
> >
> > There are no longer individual drivers.
> >
> > Instead there is one shared source code and two device drivers:
> >
> > - rt2860 covering RT2860 and RT3090 devices
> >
> > - rt2870 covering RT2870 and RT3070 devices
>
> Cool, now you only need somebody to update those drivers to mac80211,
> and you can merge those drivers to the main drivers/net/wireless/ folder.
>
> Can't be more happy with this progress, since that means I can finally abandon
> rt2800pci and rt2800usb which have been nothing more then a pain.
I will be glad to take over the maintenance of those two drivers if this
is so burdensome for you..
^ permalink raw reply
* Re: Current status of rt2800usb and staging/rt2870
From: Bartlomiej Zolnierkiewicz @ 2009-10-13 20:44 UTC (permalink / raw)
To: Ozan Çağlayan; +Cc: linux-wireless, linux-kernel
In-Reply-To: <4AD4E60E.5030005@pardus.org.tr>
On Tuesday 13 October 2009 22:41:50 Ozan Çağlayan wrote:
> Bartlomiej Zolnierkiewicz wrote:
> > Hi,
> >
> > On Tuesday 13 October 2009 13:24:48 Ozan Çağlayan wrote:
> >
> >> Hi,
> >>
> >> In 2.6.31, there are USB device IDs common between both drivers. Should
> >> a distribution enable both drivers? What do you suggest? Are there any
> >> *known issues* stuff for one of them?
> >>
> >
> > My advice to distributions for such situations is to ship both but make
> > one driver the default one.
>
> By saying to make one driver the default one, you mean avoiding the
> other from getting probed automatically by clearing the device id tables?
Yes but rather using /etc/modprobe.d/blacklist.conf than clearing
id tables so it is easier to switch drivers..
^ permalink raw reply
* Re: NULL pointer deref at wext ioctl (Re: [PATCH] compat-2.6: adding ethtool.h to compat-2.6.31.h)
From: Luis R. Rodriguez @ 2009-10-13 21:04 UTC (permalink / raw)
To: Johannes Berg; +Cc: Hin-Tak Leung, John W. Linville, linux-wireless
In-Reply-To: <1255075519.3713.34.camel@johannes.local>
On Fri, Oct 9, 2009 at 1:05 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Thu, 2009-10-08 at 20:14 -0400, Luis R. Rodriguez wrote:
>
>> > There are some harmless warnings from using the old header, but
>> > otherwise it is working as it should:
>> > CC [M] /home/Hin-Tak/tmp-git/compat-wireless-2.6/net/wireless/sme.o
>> > /home/Hin-Tak/tmp-git/compat-wireless-2.6/net/wireless/sme.c: In
>> > function ‘__cfg80211_connect_result’:
>> > /home/Hin-Tak/tmp-git/compat-wireless-2.6/net/wireless/sme.c:370:
>> > warning: passing argument 4 of ‘wireless_send_event’ discards
>> > qualifiers from pointer target type
>> > include/net/iw_handler.h:443: note: expected ‘char *’ but argument is
>> > of type ‘const u8 *’
>
>> The last argument to wireless_send_event() was changed to be const on
>> 2.6.32, cant think of a way to avoid this warning.
>
> Yeah, it was never modified though so the warning is harmless.
OK so casting was enough to avoid these warnings, will use that for
older kernels.
#define wireless_send_event(a, b, c, d) wireless_send_event(a, b, c,
(char * ) d)
Luis
^ permalink raw reply
* Re: [PATCH 2/9] [compat-2.6 and compat-stable] Remove unused code
From: Hauke Mehrtens @ 2009-10-13 21:12 UTC (permalink / raw)
To: Hin-Tak Leung; +Cc: lrodriguez, linux-wireless
In-Reply-To: <3ace41890910121932r6f832fe8of70d9b2bdd3d2635@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3374 bytes --]
Hin-Tak Leung wrote:
> On Mon, Oct 12, 2009 at 10:19 PM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
>> LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,28) can not be true in
>> compat-2.6.28.h. The definitions are not needed in compat-wireless any
>> more. Removing this does not break compiling with mainline kernel 2.6.25
>> to 2.6.32
>
> Hmm, I am not questioning your decision for removing unused code, but
> if they are genuinely unused, why were they introduced in the first
> place?
I have added them in edcf845e4bd65d00132f02237bee3fd3daca318f but I can
not find any references to them in compat-wireless. For me it looks like
it was a mistake to introduce them. The commit comment does not say
anything about it (my bad) and I forgot why I added it.
> As a side comment, while it is unusual (compared to the usual <
> version_X), it is a possible scenario for compat-X.h to have codes
> that conditions on LINUX_VERSION_CODE >= version_X - and if memory
> serves the bits you are removing were added only recently; and they
> looks like what they are (i.e. public kernel symbols became
> private-static during 2.6.27<->2.6.28 or the other way round).
The condition #if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,28)) was
added recently because without it openSuse with kernel 2.6.27 will not
compile. OpenSuse backports the tracepoint part into their 2.6.27 kernel.
> I guess I am looking for a reason why they were added in the first
> place, if they serve no purpose.
>
>> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
>> ---
>> compat/compat-2.6.28.h | 24 ------------------------
>> 1 files changed, 0 insertions(+), 24 deletions(-)
>>
>> diff --git a/compat/compat-2.6.28.h b/compat/compat-2.6.28.h
>> index 90d080c..dd223c6 100644
>> --- a/compat/compat-2.6.28.h
>> +++ b/compat/compat-2.6.28.h
>> @@ -146,22 +146,6 @@ static inline void skb_queue_splice_tail_init(struct sk_buff_head *list,
>> }
>> } /* From include/linux/skbuff.h */
>>
>> -struct module;
>> -struct tracepoint;
>> -
>> -#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,28))
>> -struct tracepoint {
>> - const char *name; /* Tracepoint name */
>> - int state; /* State. */
>> - void **funcs;
>> -} __attribute__((aligned(32))); /*
>> - * Aligned on 32 bytes because it is
>> - * globally visible and gcc happily
>> - * align these on the structure size.
>> - * Keep in sync with vmlinux.lds.h.
>> - */
>> -#endif
>> -
>> #ifndef DECLARE_TRACE
>>
>> #define TP_PROTO(args...) args
>> @@ -181,17 +165,9 @@ struct tracepoint {
>> return -ENOSYS; \
>> }
>>
>> -#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,28))
>> -#define DEFINE_TRACE(name)
>> -#endif
>> #define EXPORT_TRACEPOINT_SYMBOL_GPL(name)
>> #define EXPORT_TRACEPOINT_SYMBOL(name)
>>
>> -#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,28))
>> -static inline void tracepoint_update_probe_range(struct tracepoint *begin,
>> - struct tracepoint *end)
>> -{ }
>> -#endif
>>
>> #endif
>>
>> --
>> 1.6.2.1
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 898 bytes --]
^ permalink raw reply
* Re: Current status of rt2800usb and staging/rt2870
From: Bartlomiej Zolnierkiewicz @ 2009-10-13 21:57 UTC (permalink / raw)
To: Dan Williams
Cc: Ivo van Doorn, Ozan Çağlayan, linux-wireless,
linux-kernel
In-Reply-To: <1255464940.10798.10.camel@localhost.localdomain>
On Tuesday 13 October 2009 22:15:40 Dan Williams wrote:
> On Tue, 2009-10-13 at 21:21 +0200, Bartlomiej Zolnierkiewicz wrote:
> > On Tuesday 13 October 2009 20:17:47 Ivo van Doorn wrote:
> > > On Tuesday 13 October 2009, Bartlomiej Zolnierkiewicz wrote:
> > > > On Tuesday 13 October 2009 17:52:52 Ivo van Doorn wrote:
> > > >
> > > > > I am going to merge rt2800pci soon as well and after that I'll send a patch
> > > >
> > > > Great, I've been waiting for this for a long time.
> > > >
> > > > > to remove all Ralink drivers from the staging tree.
> > > >
> > > > Till new drivers obtain support for all hardware currently covered by
> > > > the unified staging drivers the latter shouldn't be removed as they
> > > > serve well their role as a temporary solution allowing real Linux users
> > > > to user their real hardware and as a reference material for developers
> > > > willing to work on adding the missing bits to new drivers.
> > >
> > > The rt2800pci and rt2800usb drivers cover support for rt2860/rt2870/rt3070 devices,
> > > which are present as individual drivers in the staging tree. So far it only managed
> >
> > There are no longer individual drivers.
> >
> > Instead there is one shared source code and two device drivers:
> >
> > - rt2860 covering RT2860 and RT3090 devices
> >
> > - rt2870 covering RT2870 and RT3070 devices
> >
> > In comparison rt2800usb currently lacks RT3070 support and rt2800pci's
> > RT3090 support is basic at best (not to mention that it didn't work for
> > RT2860 last time that I tried)..
> >
> > > to confuse developers which wanted to work on Ralink support, so I haven't found
> >
> > I bet they are truly grateful for being shown "the one and only way"..
>
> There *is* only one way: mac80211. If the driver is softmac, but does
> not use mac82011, then it *is* the wrong way. We will not have multiple
> 802.11 stacks in the mainstream kernel. If a softmac driver uses
> mac80211, hey, that's great! Lets add it!
Nobody never ever suggested merging Ralink drivers as they are into
kernel proper.
> If it doesn't, then that driver needs to be updated to use mac80211.
> Period.
>
> > > a benefit for having those drivers in the staging tree yet. But I am sure there are plenty
> >
> > I was able to use my Eee 901 successfully with them for a last year and I'm
> > pretty sure that I'm not the only. I understand my sin now -- I should have
> > had help in fixing the proper and clean code before using my hardware.. [*]
>
> That's nice, and everyone appreciates the work that you've done. Nobody
> can tell you what to work on, but it would be nice to get more people
> working on the *mac80211* versions of the various drivers. Imagine how
> much better rt2x00 would be if all the effort that had gone into cleanup
> up the ralink vendor drivers had instead gone into making rt2x00 work on
> the new hardware. Then you'd have cfg80211 support, background
> scanning, etc all for free with no effort on your part.
No effort, right. Debugging things is the hardest part of any project..
> Maybe it would have taken 6 months longer to get good support for your
> hardware but at least the work would have a future. But now we're stuck
You miss one tiny and irrelevant detail. Until the work is finished
I cannot use the hardware and real testers/users are using the vendor
driver anyway for the simple fact that it exists and works.
> in a situation where either:
>
> 1) the vendor driver never gets converted to cfg80211/mac80211, and
> stays in staging forever, or finally gets booted out of staging because
> nobody is working on converting it to mac80211. mac80211/cfg80211 is a
> hard requirement for being an accepted wireless driver. And drivers do
> have a shelf-life in staging.
>
> 2) the vendor driver starts getting converted to use mac80211. But I
> would argue that a better use of *anyone's* time is to make rt2x00
> better, instead of porting the ralink vendor drivers to mac80211. It
> would probably take less time to fix up rt2x00 for new hardware than to
> port the ralink vendor drivers to mac80211.
Nobody is saying anything about porting the vendor drivers to mac80211.
3) After the vendor driver gets cleaned up to the point that people are
able to make any sense out of it the missing bits will get added to rt2x00.
Several months later (after all current users are happy with the improved
drivers) the old drivers will be removed from staging..
> > > of people who like the idea of having the original Ralink drivers inside the staging tree,
> > > so they can continue debugging that, so I won't talk about the staging downsides further.
> >
> > Well, it would be much more productive if people concentrate on improving
> > _their_ projects and looking at downsides of _their_ code instead of going
> > around and looking at _obvious_ downsides of other people's projects.
> >
> >
> > [*] [Slightly off-topic but it shows the same problem with the approach]
> >
> > I now also see why some distributions keep pushing some known non-working
> > things on their users (Fedora maintainers -- I'm talking to you), the best
> > example is PulseAudio -- it simply doesn't work reliably even on modern
> > hardware and/or using all scheduler tricks (it seems that making Linux into
> > full RT OS is a prerequisite for fixing latency issues observed)..
>
> Pulseaudio works for many, many people. The most productive use of your
Yeah, I trust you on both points..
> time here is to file a bug report with the specific details of your
> audio chipset, let upstream diagnose whether it's a Pulseaudio-specific
> problem, a codec driver problem, or an ALSA problem.
Right..
I see no point BTW -- time make proper bug-report is much bigger than
throwing in few local hacks and since my experience with upstream so far
was that my bug-reports end up in some black-hole I deal with issues in
the most pragmatic and productive for everybody way..
> You can wait until the cows come home to deploy new technology, and then
> of course you'll still have to fix up all the bugs because you waited
> too long and nobody was testing it, or you can deploy new technology
> that works for most people and fix those bugs much earlier. Release
> early, release often. The tricky thing is how early.
It was new technology in F8 days.. It was included in F9 (released on
13th May 2008) and the current rawhide is still broken (no chance it will
get fixed for F12).. Getting stereo sound to play skip-lessly on standard
AC97 or HDA cards on a freshly installed system is impossible..
Other distributions are really not that much better (to be honest with
Fedora it is the bleeding edge by definition) as their mode of operations
sometimes consists of copying features (regardless of the quality and
current state) from other distributions just for the sake of to not staying
behind eventually..
^ permalink raw reply
* Re: Current status of rt2800usb and staging/rt2870
From: Luis Correia @ 2009-10-13 22:21 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Dan Williams, Ivo van Doorn, Ozan Çağlayan,
linux-wireless, linux-kernel
In-Reply-To: <200910132357.57094.bzolnier@gmail.com>
On Tue, Oct 13, 2009 at 22:57, Bartlomiej Zolnierkiewicz
<bzolnier@gmail.com> wrote:
> On Tuesday 13 October 2009 22:15:40 Dan Williams wrote:
>> On Tue, 2009-10-13 at 21:21 +0200, Bartlomiej Zolnierkiewicz wrote:
>> > On Tuesday 13 October 2009 20:17:47 Ivo van Doorn wrote:
>> > > On Tuesday 13 October 2009, Bartlomiej Zolnierkiewicz wrote:
>> > > > On Tuesday 13 October 2009 17:52:52 Ivo van Doorn wrote:
>> > > >
>> > > > > I am going to merge rt2800pci soon as well and after that I'll send a patch
>> > > >
>> > > > Great, I've been waiting for this for a long time.
>> > > >
>> > > > > to remove all Ralink drivers from the staging tree.
>> > > >
>> > > > Till new drivers obtain support for all hardware currently covered by
>> > > > the unified staging drivers the latter shouldn't be removed as they
>> > > > serve well their role as a temporary solution allowing real Linux users
>> > > > to user their real hardware and as a reference material for developers
>> > > > willing to work on adding the missing bits to new drivers.
>> > >
>> > > The rt2800pci and rt2800usb drivers cover support for rt2860/rt2870/rt3070 devices,
>> > > which are present as individual drivers in the staging tree. So far it only managed
>> >
>> > There are no longer individual drivers.
>> >
>> > Instead there is one shared source code and two device drivers:
>> >
>> > - rt2860 covering RT2860 and RT3090 devices
>> >
>> > - rt2870 covering RT2870 and RT3070 devices
>> >
>> > In comparison rt2800usb currently lacks RT3070 support and rt2800pci's
>> > RT3090 support is basic at best (not to mention that it didn't work for
>> > RT2860 last time that I tried)..
>> >
>> > > to confuse developers which wanted to work on Ralink support, so I haven't found
>> >
>> > I bet they are truly grateful for being shown "the one and only way"..
>>
>> There *is* only one way: mac80211. If the driver is softmac, but does
>> not use mac82011, then it *is* the wrong way. We will not have multiple
>> 802.11 stacks in the mainstream kernel. If a softmac driver uses
>> mac80211, hey, that's great! Lets add it!
>
> Nobody never ever suggested merging Ralink drivers as they are into
> kernel proper.
>
>> If it doesn't, then that driver needs to be updated to use mac80211.
>> Period.
>>
>> > > a benefit for having those drivers in the staging tree yet. But I am sure there are plenty
>> >
>> > I was able to use my Eee 901 successfully with them for a last year and I'm
>> > pretty sure that I'm not the only. I understand my sin now -- I should have
>> > had help in fixing the proper and clean code before using my hardware.. [*]
>>
>> That's nice, and everyone appreciates the work that you've done. Nobody
>> can tell you what to work on, but it would be nice to get more people
>> working on the *mac80211* versions of the various drivers. Imagine how
>> much better rt2x00 would be if all the effort that had gone into cleanup
>> up the ralink vendor drivers had instead gone into making rt2x00 work on
>> the new hardware. Then you'd have cfg80211 support, background
>> scanning, etc all for free with no effort on your part.
>
> No effort, right. Debugging things is the hardest part of any project..
>
>> Maybe it would have taken 6 months longer to get good support for your
>> hardware but at least the work would have a future. But now we're stuck
>
> You miss one tiny and irrelevant detail. Until the work is finished
> I cannot use the hardware and real testers/users are using the vendor
> driver anyway for the simple fact that it exists and works.
>
>> in a situation where either:
>>
>> 1) the vendor driver never gets converted to cfg80211/mac80211, and
>> stays in staging forever, or finally gets booted out of staging because
>> nobody is working on converting it to mac80211. mac80211/cfg80211 is a
>> hard requirement for being an accepted wireless driver. And drivers do
>> have a shelf-life in staging.
>>
>> 2) the vendor driver starts getting converted to use mac80211. But I
>> would argue that a better use of *anyone's* time is to make rt2x00
>> better, instead of porting the ralink vendor drivers to mac80211. It
>> would probably take less time to fix up rt2x00 for new hardware than to
>> port the ralink vendor drivers to mac80211.
>
> Nobody is saying anything about porting the vendor drivers to mac80211.
>
> 3) After the vendor driver gets cleaned up to the point that people are
> able to make any sense out of it the missing bits will get added to rt2x00.
> Several months later (after all current users are happy with the improved
> drivers) the old drivers will be removed from staging..
>
>> > > of people who like the idea of having the original Ralink drivers inside the staging tree,
>> > > so they can continue debugging that, so I won't talk about the staging downsides further.
>> >
>> > Well, it would be much more productive if people concentrate on improving
>> > _their_ projects and looking at downsides of _their_ code instead of going
>> > around and looking at _obvious_ downsides of other people's projects.
>> >
>> >
>> > [*] [Slightly off-topic but it shows the same problem with the approach]
>> >
>> > I now also see why some distributions keep pushing some known non-working
>> > things on their users (Fedora maintainers -- I'm talking to you), the best
>> > example is PulseAudio -- it simply doesn't work reliably even on modern
>> > hardware and/or using all scheduler tricks (it seems that making Linux into
>> > full RT OS is a prerequisite for fixing latency issues observed)..
>>
>> Pulseaudio works for many, many people. The most productive use of your
>
> Yeah, I trust you on both points..
>
>> time here is to file a bug report with the specific details of your
>> audio chipset, let upstream diagnose whether it's a Pulseaudio-specific
>> problem, a codec driver problem, or an ALSA problem.
>
> Right..
>
> I see no point BTW -- time make proper bug-report is much bigger than
> throwing in few local hacks and since my experience with upstream so far
> was that my bug-reports end up in some black-hole I deal with issues in
> the most pragmatic and productive for everybody way..
>
>> You can wait until the cows come home to deploy new technology, and then
>> of course you'll still have to fix up all the bugs because you waited
>> too long and nobody was testing it, or you can deploy new technology
>> that works for most people and fix those bugs much earlier. Release
>> early, release often. The tricky thing is how early.
>
> It was new technology in F8 days.. It was included in F9 (released on
> 13th May 2008) and the current rawhide is still broken (no chance it will
> get fixed for F12).. Getting stereo sound to play skip-lessly on standard
> AC97 or HDA cards on a freshly installed system is impossible..
>
> Other distributions are really not that much better (to be honest with
> Fedora it is the bleeding edge by definition) as their mode of operations
> sometimes consists of copying features (regardless of the quality and
> current state) from other distributions just for the sake of to not staying
> behind eventually..
> --
> 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
>
I will make only a small comment on all this issue, from the point of
view of a project admin, which writes little to no code at all in
rt2x00.
Every once in a while, usually when Ralink releases new chipsets,
there is the question of whether or not our rt2x00 project will
support that new chipset.
>From being in the project since almost the beginning, and looking on
and off into the crap code, I do know how hard it is to port crap code
into rt2x00.
That been said, i also know that with the complexity brought in by the
new chipsets, it makes it even harder to port the code over.
But then there's the users, who bitch about everything and simply do
not understand what it is at stake.
And all this is becoming way too messy for us to handle.
Personally all I see around me is people bitching and complaining, and
no code being ported.
I've said this way too many times now, all code is welcome.
Since some days now, we have someone in the team which works for
Ralink, I'm hopefull that he can find some time to help us make the
driver better.
And now, i'm going back to my lovely hole, having added nothing to
this conversation.
Luis Correia,
rt2x00 project admin
^ permalink raw reply
* Re: Current status of rt2800usb and staging/rt2870
From: Dan Williams @ 2009-10-13 22:24 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Ivo van Doorn, Ozan Çağlayan, linux-wireless,
linux-kernel
In-Reply-To: <200910132357.57094.bzolnier@gmail.com>
On Tue, 2009-10-13 at 23:57 +0200, Bartlomiej Zolnierkiewicz wrote:
> On Tuesday 13 October 2009 22:15:40 Dan Williams wrote:
> > On Tue, 2009-10-13 at 21:21 +0200, Bartlomiej Zolnierkiewicz wrote:
> > > On Tuesday 13 October 2009 20:17:47 Ivo van Doorn wrote:
> > > > On Tuesday 13 October 2009, Bartlomiej Zolnierkiewicz wrote:
> > > > > On Tuesday 13 October 2009 17:52:52 Ivo van Doorn wrote:
> > > > >
> > > > > > I am going to merge rt2800pci soon as well and after that I'll send a patch
> > > > >
> > > > > Great, I've been waiting for this for a long time.
> > > > >
> > > > > > to remove all Ralink drivers from the staging tree.
> > > > >
> > > > > Till new drivers obtain support for all hardware currently covered by
> > > > > the unified staging drivers the latter shouldn't be removed as they
> > > > > serve well their role as a temporary solution allowing real Linux users
> > > > > to user their real hardware and as a reference material for developers
> > > > > willing to work on adding the missing bits to new drivers.
> > > >
> > > > The rt2800pci and rt2800usb drivers cover support for rt2860/rt2870/rt3070 devices,
> > > > which are present as individual drivers in the staging tree. So far it only managed
> > >
> > > There are no longer individual drivers.
> > >
> > > Instead there is one shared source code and two device drivers:
> > >
> > > - rt2860 covering RT2860 and RT3090 devices
> > >
> > > - rt2870 covering RT2870 and RT3070 devices
> > >
> > > In comparison rt2800usb currently lacks RT3070 support and rt2800pci's
> > > RT3090 support is basic at best (not to mention that it didn't work for
> > > RT2860 last time that I tried)..
> > >
> > > > to confuse developers which wanted to work on Ralink support, so I haven't found
> > >
> > > I bet they are truly grateful for being shown "the one and only way"..
> >
> > There *is* only one way: mac80211. If the driver is softmac, but does
> > not use mac82011, then it *is* the wrong way. We will not have multiple
> > 802.11 stacks in the mainstream kernel. If a softmac driver uses
> > mac80211, hey, that's great! Lets add it!
>
> Nobody never ever suggested merging Ralink drivers as they are into
> kernel proper.
>
> > If it doesn't, then that driver needs to be updated to use mac80211.
> > Period.
> >
> > > > a benefit for having those drivers in the staging tree yet. But I am sure there are plenty
> > >
> > > I was able to use my Eee 901 successfully with them for a last year and I'm
> > > pretty sure that I'm not the only. I understand my sin now -- I should have
> > > had help in fixing the proper and clean code before using my hardware.. [*]
> >
> > That's nice, and everyone appreciates the work that you've done. Nobody
> > can tell you what to work on, but it would be nice to get more people
> > working on the *mac80211* versions of the various drivers. Imagine how
> > much better rt2x00 would be if all the effort that had gone into cleanup
> > up the ralink vendor drivers had instead gone into making rt2x00 work on
> > the new hardware. Then you'd have cfg80211 support, background
> > scanning, etc all for free with no effort on your part.
>
> No effort, right. Debugging things is the hardest part of any project..
>
> > Maybe it would have taken 6 months longer to get good support for your
> > hardware but at least the work would have a future. But now we're stuck
>
> You miss one tiny and irrelevant detail. Until the work is finished
> I cannot use the hardware and real testers/users are using the vendor
> driver anyway for the simple fact that it exists and works.
>
> > in a situation where either:
> >
> > 1) the vendor driver never gets converted to cfg80211/mac80211, and
> > stays in staging forever, or finally gets booted out of staging because
> > nobody is working on converting it to mac80211. mac80211/cfg80211 is a
> > hard requirement for being an accepted wireless driver. And drivers do
> > have a shelf-life in staging.
> >
> > 2) the vendor driver starts getting converted to use mac80211. But I
> > would argue that a better use of *anyone's* time is to make rt2x00
> > better, instead of porting the ralink vendor drivers to mac80211. It
> > would probably take less time to fix up rt2x00 for new hardware than to
> > port the ralink vendor drivers to mac80211.
>
> Nobody is saying anything about porting the vendor drivers to mac80211.
>
> 3) After the vendor driver gets cleaned up to the point that people are
> able to make any sense out of it the missing bits will get added to rt2x00.
> Several months later (after all current users are happy with the improved
> drivers) the old drivers will be removed from staging..
>
> > > > of people who like the idea of having the original Ralink drivers inside the staging tree,
> > > > so they can continue debugging that, so I won't talk about the staging downsides further.
> > >
> > > Well, it would be much more productive if people concentrate on improving
> > > _their_ projects and looking at downsides of _their_ code instead of going
> > > around and looking at _obvious_ downsides of other people's projects.
> > >
> > >
> > > [*] [Slightly off-topic but it shows the same problem with the approach]
> > >
> > > I now also see why some distributions keep pushing some known non-working
> > > things on their users (Fedora maintainers -- I'm talking to you), the best
> > > example is PulseAudio -- it simply doesn't work reliably even on modern
> > > hardware and/or using all scheduler tricks (it seems that making Linux into
> > > full RT OS is a prerequisite for fixing latency issues observed)..
> >
> > Pulseaudio works for many, many people. The most productive use of your
>
> Yeah, I trust you on both points..
>
> > time here is to file a bug report with the specific details of your
> > audio chipset, let upstream diagnose whether it's a Pulseaudio-specific
> > problem, a codec driver problem, or an ALSA problem.
>
> Right..
>
> I see no point BTW -- time make proper bug-report is much bigger than
> throwing in few local hacks and since my experience with upstream so far
> was that my bug-reports end up in some black-hole I deal with issues in
> the most pragmatic and productive for everybody way..
>
> > You can wait until the cows come home to deploy new technology, and then
> > of course you'll still have to fix up all the bugs because you waited
> > too long and nobody was testing it, or you can deploy new technology
> > that works for most people and fix those bugs much earlier. Release
> > early, release often. The tricky thing is how early.
>
> It was new technology in F8 days.. It was included in F9 (released on
> 13th May 2008) and the current rawhide is still broken (no chance it will
> get fixed for F12).. Getting stereo sound to play skip-lessly on standard
> AC97 or HDA cards on a freshly installed system is impossible..
Really? That's not my experience with F11 or F12 on any of 5 different
laptops from 5 different vendors. HP 2530p, Thinkpad T42, Dell D410,
Fujitsu Lifebook P7230, Apple iBook G3/800. Sound just works, and I can
switch between USB speakers, internal, headphone jack without manually
screwing around with module parameters for the alsa default device and
reloading them just to redirect sound where I want it to go. I can
listen to Pandora via flash all day and that doesn't skip (except when
the 3G dies, of course).
The point here is, often stuff works for some and not for others. That
doesn't mean it's "broken". It's broken for you, and that should get
fixed, but the whole system is by no means a loss and its pretty stupid
to generalize things like "play skip-lessly on standard AC97/HDA cards
is impossible" when it clearly isn't.
Dan
^ permalink raw reply
* Re: [PATCH 1/2] mac80211: add ieee80211_rx_ni()
From: Julian Calaby @ 2009-10-13 22:33 UTC (permalink / raw)
To: Kalle Valo; +Cc: linville, johannes, linux-wireless
In-Reply-To: <20091013173313.13021.80289.stgit@tikku>
On Wed, Oct 14, 2009 at 03:33, Kalle Valo <kalle.valo@iki.fi> wrote:
> From: Kalle Valo <kalle.valo@nokia.com>
>
> ieee80211_rx() must be called with bottom halves disabled. To simplify
> driver development implement ieee80211_rx_ni() which disables BH. This
> function must be used when in process context.
>
> Signed-off-by: Kalle Valo <kalle.valo@nokia.com>
> ---
>
> include/net/mac80211.h | 32 ++++++++++++++++++++++++++------
> 1 files changed, 26 insertions(+), 6 deletions(-)
>
> diff --git a/include/net/mac80211.h b/include/net/mac80211.h
> index c75b960..c42c4a8 100644
> --- a/include/net/mac80211.h
> +++ b/include/net/mac80211.h
> @@ -1665,11 +1665,11 @@ void ieee80211_restart_hw(struct ieee80211_hw *hw);
> * header if %RX_FLAG_RADIOTAP is set in the @status flags.
> *
> * This function may not be called in IRQ context. Calls to this function
> - * for a single hardware must be synchronized against each other. Calls
> - * to this function and ieee80211_rx_irqsafe() may not be mixed for a
> - * single hardware.
> + * for a single hardware must be synchronized against each other. Calls to
> + * this function, ieee80211_rx_ni() and ieee80211_rx_irqsafe() may not be
> + * mixed for a single hardware.
[snip]
> - * Calls to this function and ieee80211_rx() may not be mixed for a
> - * single hardware.
> + * Calls to this function, ieee80211_rx() or ieee80211_rx_ni() may not
> + * be mixed for a single hardware.
You missed out ieee80211_rx_irqsafe() here.
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
.Plan: http://sites.google.com/site/juliancalaby/
^ permalink raw reply
* Stable compat-wireless 2.6.32-rc4 released
From: Luis R. Rodriguez @ 2009-10-13 22:42 UTC (permalink / raw)
To: linux-wireless; +Cc: linux-kernel, John W. Linville, Tim Gardner, Greg KH
As the kernel moves along so does the automatic stable backports for
the wireless subsystem [1]. We are now on 2.6.32-rc4. Besides getting
the same fixes from rc1..rc4 some backport changes were made as well,
most importantly that of relying on your own kernel's iw_handler.h.
I've tested this release with 2.6.28.
Please report any issues you see.
[1] http://wireless.kernel.org/en/users/Download/stable
PS. If you maintain a distribution and rely on stable compat-wireless
releases please let me know so I can CC you when further updates are
made.
Luis
^ permalink raw reply
* Re: Current status of rt2800usb and staging/rt2870
From: Bartlomiej Zolnierkiewicz @ 2009-10-13 22:42 UTC (permalink / raw)
To: Dan Williams
Cc: Ivo van Doorn, Ozan Çağlayan, linux-wireless,
linux-kernel
In-Reply-To: <1255472698.11695.75.camel@localhost.localdomain>
On Wednesday 14 October 2009 00:24:58 Dan Williams wrote:
> On Tue, 2009-10-13 at 23:57 +0200, Bartlomiej Zolnierkiewicz wrote:
> > On Tuesday 13 October 2009 22:15:40 Dan Williams wrote:
> > > On Tue, 2009-10-13 at 21:21 +0200, Bartlomiej Zolnierkiewicz wrote:
> > > > On Tuesday 13 October 2009 20:17:47 Ivo van Doorn wrote:
> > > > > On Tuesday 13 October 2009, Bartlomiej Zolnierkiewicz wrote:
> > > > > > On Tuesday 13 October 2009 17:52:52 Ivo van Doorn wrote:
> > > > > >
> > > > > > > I am going to merge rt2800pci soon as well and after that I'll send a patch
> > > > > >
> > > > > > Great, I've been waiting for this for a long time.
> > > > > >
> > > > > > > to remove all Ralink drivers from the staging tree.
> > > > > >
> > > > > > Till new drivers obtain support for all hardware currently covered by
> > > > > > the unified staging drivers the latter shouldn't be removed as they
> > > > > > serve well their role as a temporary solution allowing real Linux users
> > > > > > to user their real hardware and as a reference material for developers
> > > > > > willing to work on adding the missing bits to new drivers.
> > > > >
> > > > > The rt2800pci and rt2800usb drivers cover support for rt2860/rt2870/rt3070 devices,
> > > > > which are present as individual drivers in the staging tree. So far it only managed
> > > >
> > > > There are no longer individual drivers.
> > > >
> > > > Instead there is one shared source code and two device drivers:
> > > >
> > > > - rt2860 covering RT2860 and RT3090 devices
> > > >
> > > > - rt2870 covering RT2870 and RT3070 devices
> > > >
> > > > In comparison rt2800usb currently lacks RT3070 support and rt2800pci's
> > > > RT3090 support is basic at best (not to mention that it didn't work for
> > > > RT2860 last time that I tried)..
> > > >
> > > > > to confuse developers which wanted to work on Ralink support, so I haven't found
> > > >
> > > > I bet they are truly grateful for being shown "the one and only way"..
> > >
> > > There *is* only one way: mac80211. If the driver is softmac, but does
> > > not use mac82011, then it *is* the wrong way. We will not have multiple
> > > 802.11 stacks in the mainstream kernel. If a softmac driver uses
> > > mac80211, hey, that's great! Lets add it!
> >
> > Nobody never ever suggested merging Ralink drivers as they are into
> > kernel proper.
> >
> > > If it doesn't, then that driver needs to be updated to use mac80211.
> > > Period.
> > >
> > > > > a benefit for having those drivers in the staging tree yet. But I am sure there are plenty
> > > >
> > > > I was able to use my Eee 901 successfully with them for a last year and I'm
> > > > pretty sure that I'm not the only. I understand my sin now -- I should have
> > > > had help in fixing the proper and clean code before using my hardware.. [*]
> > >
> > > That's nice, and everyone appreciates the work that you've done. Nobody
> > > can tell you what to work on, but it would be nice to get more people
> > > working on the *mac80211* versions of the various drivers. Imagine how
> > > much better rt2x00 would be if all the effort that had gone into cleanup
> > > up the ralink vendor drivers had instead gone into making rt2x00 work on
> > > the new hardware. Then you'd have cfg80211 support, background
> > > scanning, etc all for free with no effort on your part.
> >
> > No effort, right. Debugging things is the hardest part of any project..
> >
> > > Maybe it would have taken 6 months longer to get good support for your
> > > hardware but at least the work would have a future. But now we're stuck
> >
> > You miss one tiny and irrelevant detail. Until the work is finished
> > I cannot use the hardware and real testers/users are using the vendor
> > driver anyway for the simple fact that it exists and works.
> >
> > > in a situation where either:
> > >
> > > 1) the vendor driver never gets converted to cfg80211/mac80211, and
> > > stays in staging forever, or finally gets booted out of staging because
> > > nobody is working on converting it to mac80211. mac80211/cfg80211 is a
> > > hard requirement for being an accepted wireless driver. And drivers do
> > > have a shelf-life in staging.
> > >
> > > 2) the vendor driver starts getting converted to use mac80211. But I
> > > would argue that a better use of *anyone's* time is to make rt2x00
> > > better, instead of porting the ralink vendor drivers to mac80211. It
> > > would probably take less time to fix up rt2x00 for new hardware than to
> > > port the ralink vendor drivers to mac80211.
> >
> > Nobody is saying anything about porting the vendor drivers to mac80211.
> >
> > 3) After the vendor driver gets cleaned up to the point that people are
> > able to make any sense out of it the missing bits will get added to rt2x00.
> > Several months later (after all current users are happy with the improved
> > drivers) the old drivers will be removed from staging..
> >
> > > > > of people who like the idea of having the original Ralink drivers inside the staging tree,
> > > > > so they can continue debugging that, so I won't talk about the staging downsides further.
> > > >
> > > > Well, it would be much more productive if people concentrate on improving
> > > > _their_ projects and looking at downsides of _their_ code instead of going
> > > > around and looking at _obvious_ downsides of other people's projects.
> > > >
> > > >
> > > > [*] [Slightly off-topic but it shows the same problem with the approach]
> > > >
> > > > I now also see why some distributions keep pushing some known non-working
> > > > things on their users (Fedora maintainers -- I'm talking to you), the best
> > > > example is PulseAudio -- it simply doesn't work reliably even on modern
> > > > hardware and/or using all scheduler tricks (it seems that making Linux into
> > > > full RT OS is a prerequisite for fixing latency issues observed)..
> > >
> > > Pulseaudio works for many, many people. The most productive use of your
> >
> > Yeah, I trust you on both points..
> >
> > > time here is to file a bug report with the specific details of your
> > > audio chipset, let upstream diagnose whether it's a Pulseaudio-specific
> > > problem, a codec driver problem, or an ALSA problem.
> >
> > Right..
> >
> > I see no point BTW -- time make proper bug-report is much bigger than
> > throwing in few local hacks and since my experience with upstream so far
> > was that my bug-reports end up in some black-hole I deal with issues in
> > the most pragmatic and productive for everybody way..
> >
> > > You can wait until the cows come home to deploy new technology, and then
> > > of course you'll still have to fix up all the bugs because you waited
> > > too long and nobody was testing it, or you can deploy new technology
> > > that works for most people and fix those bugs much earlier. Release
> > > early, release often. The tricky thing is how early.
> >
> > It was new technology in F8 days.. It was included in F9 (released on
> > 13th May 2008) and the current rawhide is still broken (no chance it will
> > get fixed for F12).. Getting stereo sound to play skip-lessly on standard
> > AC97 or HDA cards on a freshly installed system is impossible..
>
> Really? That's not my experience with F11 or F12 on any of 5 different
> laptops from 5 different vendors. HP 2530p, Thinkpad T42, Dell D410,
> Fujitsu Lifebook P7230, Apple iBook G3/800. Sound just works, and I can
> switch between USB speakers, internal, headphone jack without manually
> screwing around with module parameters for the alsa default device and
> reloading them just to redirect sound where I want it to go. I can
> listen to Pandora via flash all day and that doesn't skip (except when
> the 3G dies, of course).
>
> The point here is, often stuff works for some and not for others. That
> doesn't mean it's "broken". It's broken for you, and that should get
> fixed, but the whole system is by no means a loss and its pretty stupid
> to generalize things like "play skip-lessly on standard AC97/HDA cards
> is impossible" when it clearly isn't.
Interesting, do you mean that you are able to get skipless mp3 playback
under i.e. audacious (using the default pulseaudio output plugin) under
heavy load (i.e. kernel build) with internal speakers (or headphones)?
If so must by my luck then -- F11 on old Acer laptop (Intel 8x0 in ICH4M)
and fedora-rawhide on new Asus K50AB one (Intel HDA in AMD/ATI SB710)..
^ permalink raw reply
* Re: [PATCH 2/9] [compat-2.6 and compat-stable] Remove unused code
From: Hin-Tak Leung @ 2009-10-14 0:12 UTC (permalink / raw)
To: Hauke Mehrtens; +Cc: lrodriguez, linux-wireless
In-Reply-To: <4AD4ED23.7010200@hauke-m.de>
On Tue, Oct 13, 2009 at 10:12 PM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
> The condition #if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,28)) was
> added recently because without it openSuse with kernel 2.6.27 will not
> compile. OpenSuse backports the tracepoint part into their 2.6.27 kernel.
I remember that thread now. It is probably wrong as a matter of policy
to incorporate patches for distro kernels with backport bits through.
- I am not saying you shouldn't be helpful and provide them - after
all, more users == better testing, and no doubt the investigation
itself throws more insights on the detailed mechanisms - but it is
just that compat-wireless probably should not try to support arbitrary
and substantial changes from a vanilla kernel. I know Suse is popular
so it is important to support Suse users, but I am wondering if
distro-specific changes should be separate or at least, clearly
documented.
^ permalink raw reply
* Re: [PATCH 2/9] [compat-2.6 and compat-stable] Remove unused code
From: Luis R. Rodriguez @ 2009-10-14 0:18 UTC (permalink / raw)
To: Hin-Tak Leung; +Cc: Hauke Mehrtens, linux-wireless, Greg KH
In-Reply-To: <3ace41890910131712v700ebfe4vc1cd234f24abee9@mail.gmail.com>
On Tue, Oct 13, 2009 at 5:12 PM, Hin-Tak Leung <hintak.leung@gmail.com> wrote:
> On Tue, Oct 13, 2009 at 10:12 PM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
>
>> The condition #if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,28)) was
>> added recently because without it openSuse with kernel 2.6.27 will not
>> compile. OpenSuse backports the tracepoint part into their 2.6.27 kernel.
>
> I remember that thread now. It is probably wrong as a matter of policy
> to incorporate patches for distro kernels with backport bits through.
> - I am not saying you shouldn't be helpful and provide them - after
> all, more users == better testing, and no doubt the investigation
> itself throws more insights on the detailed mechanisms - but it is
> just that compat-wireless probably should not try to support arbitrary
> and substantial changes from a vanilla kernel. I know Suse is popular
> so it is important to support Suse users, but I am wondering if
> distro-specific changes should be separate or at least, clearly
> documented.
Not sure why opensuse added round_jiffies_up() to their 2.6.27
kernels, greg may know better, but since its only once change I'm
willing to live with what we did to resolve for it.
Luis
^ permalink raw reply
* Re: Stable compat-wireless 2.6.32-rc4 released
From: Tim Gardner @ 2009-10-14 0:25 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, linux-kernel, John W. Linville, Greg KH
In-Reply-To: <43e72e890910131542k376a87c5rc30feb6491a06867@mail.gmail.com>
Luis R. Rodriguez wrote:
> As the kernel moves along so does the automatic stable backports for
> the wireless subsystem [1]. We are now on 2.6.32-rc4. Besides getting
> the same fixes from rc1..rc4 some backport changes were made as well,
> most importantly that of relying on your own kernel's iw_handler.h.
> I've tested this release with 2.6.28.
>
> Please report any issues you see.
>
> [1] http://wireless.kernel.org/en/users/Download/stable
>
> PS. If you maintain a distribution and rely on stable compat-wireless
> releases please let me know so I can CC you when further updates are
> made.
>
> Luis
>
Speaking as a distro, what advantage does the stable wireless backport
offer for the currently released kernel if we are already consumers of
stable updates?
rtg
--
Tim Gardner tim.gardner@canonical.com
^ permalink raw reply
* compat-wireless 2.6.32-rc4 failed to compile
From: Anielkis Herrera Gonzalez @ 2009-10-14 0:24 UTC (permalink / raw)
To: linux-wireless
[-- Attachment #1: Type: text/plain, Size: 1087 bytes --]
# uname -r
2.6.32-rc4
and it failed in:
CC
[M] /var/tmp/portage/net-wireless/compat-wireless-2.6.32_rc4/work/compat-wireless-2.6.32-rc4/drivers/net/wireless/ipw2x00/ipw2100.o
/var/tmp/portage/net-wireless/compat-wireless-2.6.32_rc4/work/compat-wireless-2.6.32-rc4/drivers/net/wireless/ipw2x00/ipw2100.c:1: warning: SSE instruction set disabled, using 387 arithmetics
/var/tmp/portage/net-wireless/compat-wireless-2.6.32_rc4/work/compat-wireless-2.6.32-rc4/drivers/net/wireless/ipw2x00/ipw2100.c: In function 'ipw2100_alloc_device':
/var/tmp/portage/net-wireless/compat-wireless-2.6.32_rc4/work/compat-wireless-2.6.32-rc4/drivers/net/wireless/ipw2x00/ipw2100.c:6060: error: 'struct iw_public_data' has no member named 'ieee80211'
--
________________________________________________________
Ing. Anielkis Herrera González
Arquitecto Principal de Nova
Linux User #377809
Universidad de las Ciencias Informáticas
Cuba
________________________________________________________
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2139 bytes --]
^ permalink raw reply
* [PATCH] mac80211: fix SME warning by removing stale BSS upon assoc failure
From: Luis R. Rodriguez @ 2009-10-14 0:50 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis R. Rodriguez, ic.felix, Johannes Berg
If you try to authenticate with an AP we will keep track of the
AP's BSS and expect to eventually either give up on the AP or complete
an association cycle with it. If an AP rejects our association though
mac80211 currently insists on telling cfg80211 a BSS authenticated
correctly, this is wrong as it leaves a bogus BSS lingering around.
When this happens you can get from userspace stale APs as follows:
mcgrof@tesla ~ $ iw dev wlan0 link
Authenticated with <BSS-MAC-address-01> (on wlan0)
Authenticated with <BSS-MAC-address-02> (on wlan0)
Not connected.
We fix this by telling cfg80211 it needs to deauthenticate from the
BSS if an association is rejected by an AP on mac80211.
>From the looks of it this was just a typo.
This fixes the cfg80211 SME warning for me:
http://kerneloops.org/guilty.php?guilty=__cfg80211_disconnected&version=2.6.32-rc&start=2097152&end=2129919&class=warn
wlan0: deauthenticating from <BSS-mac-address-03> by local choice (reason=3)
------------[ cut here ]------------
WARNING: at net/wireless/sme.c:620 __cfg80211_disconnected+0x20c/0x220 [cfg80211]()
Hardware name: 7660A14
deauth failed: -67
Modules linked in: ath5k mac80211 ath cfg80211 <etc>
Pid: 2930, comm: wpa_supplicant Tainted: G W 2.6.32-rc4-wl #12
Call Trace:
[<fc0da43c>] ? __cfg80211_disconnected+0x20c/0x220 [cfg80211]
[<fc0da43c>] ? __cfg80211_disconnected+0x20c/0x220 [cfg80211]
[<c0142cfc>] warn_slowpath_common+0x6c/0xc0
[<fc0da43c>] ? __cfg80211_disconnected+0x20c/0x220 [cfg80211]
[<c0142d96>] warn_slowpath_fmt+0x26/0x30
[<fc0da43c>] __cfg80211_disconnected+0x20c/0x220 [cfg80211]
[<fc0d7201>] ? nl80211_send_deauth+0x21/0x30 [cfg80211]
[<fc0d83c2>] __cfg80211_send_deauth+0x1b2/0x250 [cfg80211]
[<c0493d2d>] ? __alloc_skb+0x4d/0x130
[<fc78804a>] ieee80211_send_deauth_disassoc+0x11a/0x170 [mac80211]
[<fc789587>] ieee80211_mgd_deauth+0xf7/0x110 [mac80211]
[<fc78f396>] ieee80211_deauth+0x16/0x20 [mac80211]
[<fc0d7616>] __cfg80211_mlme_deauth+0xd6/0x110 [cfg80211]
[<fc0daada>] __cfg80211_disconnect+0x15a/0x1b0 [cfg80211]
[<fc0dd5a5>] cfg80211_wext_siwmlme+0x75/0x80 [cfg80211]
[<c054ef4c>] ioctl_standard_call+0x16c/0x360
[<c049dd1d>] ? __dev_get_by_name+0x7d/0xa0
[<c049dd1d>] ? __dev_get_by_name+0x7d/0xa0
[<c054ea28>] wext_handle_ioctl+0x188/0x190
[<fc0dd530>] ? cfg80211_wext_siwmlme+0x0/0x80 [cfg80211]
[<c049e887>] dev_ioctl+0x467/0x530
[<c048ca50>] ? sock_ioctl+0x0/0x260
[<c048cb3d>] sock_ioctl+0xed/0x260
[<c048ca50>] ? sock_ioctl+0x0/0x260
[<c01fd1e8>] vfs_ioctl+0x28/0x90
[<c01fd39a>] do_vfs_ioctl+0x6a/0x5f0
[<c010a8cc>] ? restore_i387_xstate+0x10c/0x200
[<c02d715f>] ? security_file_permission+0xf/0x20
[<c01ef3c4>] ? rw_verify_area+0x54/0xd0
[<c01efbfd>] ? vfs_read+0x17d/0x190
[<c0102332>] ? restore_sigcontext+0xc2/0xe0
[<c01fd983>] sys_ioctl+0x63/0x70
[<c010301c>] sysenter_do_call+0x12/0x28
---[ end trace e43f356f9c17e54c ]---
Cc: ic.felix@gmail.com
Cc: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 33a696f..a884672 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -1463,11 +1463,11 @@ ieee80211_rx_mgmt_assoc_resp(struct ieee80211_sub_if_data *sdata,
if (status_code != WLAN_STATUS_SUCCESS) {
printk(KERN_DEBUG "%s: AP denied association (code=%d)\n",
sdata->dev->name, status_code);
list_del(&wk->list);
kfree(wk);
- return RX_MGMT_CFG80211_ASSOC;
+ return RX_MGMT_CFG80211_DEAUTH;
}
if ((aid & (BIT(15) | BIT(14))) != (BIT(15) | BIT(14)))
printk(KERN_DEBUG "%s: invalid aid value %d; bits 15:14 not "
"set\n", sdata->dev->name, aid);
--
1.6.0.4
^ permalink raw reply related
* Re: Stable compat-wireless 2.6.32-rc4 released
From: Luis R. Rodriguez @ 2009-10-14 0:50 UTC (permalink / raw)
To: tim.gardner; +Cc: linux-wireless, linux-kernel, John W. Linville, Greg KH
In-Reply-To: <4AD51A7C.9060207@canonical.com>
On Tue, Oct 13, 2009 at 5:25 PM, Tim Gardner <tim.gardner@canonical.com> wrote:
> Luis R. Rodriguez wrote:
>>
>> As the kernel moves along so does the automatic stable backports for
>> the wireless subsystem [1]. We are now on 2.6.32-rc4. Besides getting
>> the same fixes from rc1..rc4 some backport changes were made as well,
>> most importantly that of relying on your own kernel's iw_handler.h.
>> I've tested this release with 2.6.28.
>>
>> Please report any issues you see.
>>
>> [1] http://wireless.kernel.org/en/users/Download/stable
>>
>> PS. If you maintain a distribution and rely on stable compat-wireless
>> releases please let me know so I can CC you when further updates are
>> made.
>>
>> Luis
>>
>
> Speaking as a distro, what advantage does the stable wireless backport offer
> for the currently released kernel if we are already consumers of stable
> updates?
Well if you are a distro stuck on the 2.6.31 kernel the stable
compat-wireless-2.6.32 gets you 2.6.32 wireless bits on 2.6.31 and
that means any features/drivers/large fixes/enhancements that didn't
make it to 2.6.31.
Luis
^ permalink raw reply
* Re: compat-wireless 2.6.32-rc4 failed to compile
From: Luis R. Rodriguez @ 2009-10-14 0:51 UTC (permalink / raw)
To: aherrerag; +Cc: linux-wireless
In-Reply-To: <1255479847.6242.0.camel@shadow>
On Tue, Oct 13, 2009 at 5:24 PM, Anielkis Herrera Gonzalez
<aherrerag@uci.cu> wrote:
> # uname -r
> 2.6.32-rc4
Remind me why you are trying to compile
compat-wireless-stable-2.6.32-rc4 if you already are running
2.6.32-rc4?
Luis
^ permalink raw reply
* Re: Current status of rt2800usb and staging/rt2870
From: Mike Galbraith @ 2009-10-14 1:52 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Ivo van Doorn, Ozan Çağlayan, linux-wireless,
linux-kernel
In-Reply-To: <200910132121.25743.bzolnier@gmail.com>
On Tue, 2009-10-13 at 21:21 +0200, Bartlomiej Zolnierkiewicz wrote:
> On Tuesday 13 October 2009 20:17:47 Ivo van Doorn wrote:
> > On Tuesday 13 October 2009, Bartlomiej Zolnierkiewicz wrote:
> > > On Tuesday 13 October 2009 17:52:52 Ivo van Doorn wrote:
> > >
> > > > I am going to merge rt2800pci soon as well and after that I'll send a patch
> > >
> > > Great, I've been waiting for this for a long time.
> > >
> > > > to remove all Ralink drivers from the staging tree.
> > >
> > > Till new drivers obtain support for all hardware currently covered by
> > > the unified staging drivers the latter shouldn't be removed as they
> > > serve well their role as a temporary solution allowing real Linux users
> > > to user their real hardware and as a reference material for developers
> > > willing to work on adding the missing bits to new drivers.
> >
> > The rt2800pci and rt2800usb drivers cover support for rt2860/rt2870/rt3070 devices,
> > which are present as individual drivers in the staging tree. So far it only managed
>
> There are no longer individual drivers.
>
> Instead there is one shared source code and two device drivers:
>
> - rt2860 covering RT2860 and RT3090 devices
>
> - rt2870 covering RT2870 and RT3070 devices
>
> In comparison rt2800usb currently lacks RT3070 support and rt2800pci's
> RT3090 support is basic at best (not to mention that it didn't work for
> RT2860 last time that I tried)..
(or RT2870 here)
^ permalink raw reply
* Re: [PATCH 2/9] [compat-2.6 and compat-stable] Remove unused code
From: Greg KH @ 2009-10-14 4:10 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Hin-Tak Leung, Hauke Mehrtens, linux-wireless
In-Reply-To: <43e72e890910131718x68a4a80ehc66a4daf2e299c46@mail.gmail.com>
On Tue, Oct 13, 2009 at 05:18:04PM -0700, Luis R. Rodriguez wrote:
> On Tue, Oct 13, 2009 at 5:12 PM, Hin-Tak Leung <hintak.leung@gmail.com> wrote:
> > On Tue, Oct 13, 2009 at 10:12 PM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
> >
> >> The condition #if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,28)) was
> >> added recently because without it openSuse with kernel 2.6.27 will not
> >> compile. OpenSuse backports the tracepoint part into their 2.6.27 kernel.
> >
> > I remember that thread now. It is probably wrong as a matter of policy
> > to incorporate patches for distro kernels with backport bits through.
> > - I am not saying you shouldn't be helpful and provide them - after
> > all, more users == better testing, and no doubt the investigation
> > itself throws more insights on the detailed mechanisms - but it is
> > just that compat-wireless probably should not try to support arbitrary
> > and substantial changes from a vanilla kernel. I know Suse is popular
> > so it is important to support Suse users, but I am wondering if
> > distro-specific changes should be separate or at least, clearly
> > documented.
>
> Not sure why opensuse added round_jiffies_up() to their 2.6.27
> kernels, greg may know better, but since its only once change I'm
> willing to live with what we did to resolve for it.
We added that to the SLE 11 kernel as it was requred for a bunch of
block layer backports to resolve a number of issues that we needed to
do.
Hope this helps explain things,
greg k-h
^ permalink raw reply
* Re: Moving drivers into staging (was Re: [GIT PULL] SCSI fixes for 2.6.32-rc3)
From: Greg KH @ 2009-10-14 4:45 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Ingo Molnar, James Bottomley, Linus Torvalds, Theodore Tso,
Andrew Morton, linux-scsi, linux-kernel, Jing Huang, netdev,
linux-wireless
In-Reply-To: <43e72e890910131108m789110b4hc35e25601ad67bb7@mail.gmail.com>
On Tue, Oct 13, 2009 at 11:08:15AM -0700, Luis R. Rodriguez wrote:
> On Mon, Oct 12, 2009 at 4:24 PM, Greg KH <gregkh@suse.de> wrote:
> > On Mon, Oct 12, 2009 at 05:42:44PM +0200, Ingo Molnar wrote:
> >> Hm, i think i even gave drivers/staging/ its name?
> >
> > Yes you did, and I appreciate it :)
> >
> >> > [...] It seems that I'm the only one that has the ability to drop
> >> > drivers out of the kernel tree, which is a funny situation :)
> >>
> >> You are the only one who has the ability to send a warning shot towards
> >> drivers _without hurting users_, and by moving it into the focus of a
> >> team of cleanup oriented developers.
> >>
> >> I think that's an important distinction ;-)
> >
> > Good point.
> >
> >> > In thinking about this a lot more, I don't really mind it. ??If people
> >> > want to push stuff out of "real" places in the kernel, into
> >> > drivers/staging/ and give the original authors and maintainers notice
> >> > about what is going on, _and_ provide a TODO file for what needs to
> >> > happen to get the code back into the main portion of the kernel tree,
> >> > then I'll be happy to help out with this and manage it.
> >> >
> >> > I think a 6-9 month window (basically 3 kernel releases) should be
> >> > sufficient time to have a driver that has been in drivers/staging/ be
> >> > cleaned up enough to move back into the main kernel tree. ??If not, it
> >> > could be easily dropped.
> >> >
> >> > Any objections to this?
> >>
> >> Sounds excellent to me!
> >
> > Great, I'll await the patches to move stuff to drivers/staging/ now.
> >
> > Wireless developers, warm up your editors :)
>
> OK -- prism54 seems like a good candidate, instead of removing it
> completely as I originally outlined on the feature removal schedule.
> Do we have a file to give notices to move drivers to staging because
> they are old as with the feature removal schedule? The more visible
> these things become the better it is for users.
We've found that the feature removal file is also ignored :)
How about when it was scheduled to be removed, we put it in staging and
I'll add it to my announcements about the staging tree every release?
Unless you can think of a better way?
thanks,
greg k-h
^ permalink raw reply
* Re: Moving drivers into staging (was Re: [GIT PULL] SCSI fixes for 2.6.32-rc3)
From: Joe Perches @ 2009-10-14 5:19 UTC (permalink / raw)
To: Greg KH
Cc: Luis R. Rodriguez, Ingo Molnar, James Bottomley, Linus Torvalds,
Theodore Tso, Andrew Morton, linux-scsi, linux-kernel, Jing Huang,
netdev, linux-wireless
In-Reply-To: <20091014044519.GA19199@suse.de>
On Tue, 2009-10-13 at 21:45 -0700, Greg KH wrote:
> How about when it was scheduled to be removed, we put it in staging and
> I'll add it to my announcements about the staging tree every release?
> Unless you can think of a better way?
staging/to_be_removed_unless_fixed_by/v.x.y ?
^ permalink raw reply
* Re: Stable compat-wireless 2.6.32-rc4 released
From: Kunal Gangakhedkar @ 2009-10-14 6:01 UTC (permalink / raw)
To: tim.gardner; +Cc: Luis R. Rodriguez, linux-wireless
In-Reply-To: <43e72e890910131750s4d2cdb20o76d721087d9b3aaf@mail.gmail.com>
On Wednesday 14 Oct 2009 6:20:33 am Luis R. Rodriguez wrote:
> On Tue, Oct 13, 2009 at 5:25 PM, Tim Gardner <tim.gardner@canonical.com>
wrote:
> > Speaking as a distro, what advantage does the stable wireless backport
> > offer for the currently released kernel if we are already consumers of
> > stable updates?
>
> Well if you are a distro stuck on the 2.6.31 kernel the stable
> compat-wireless-2.6.32 gets you 2.6.32 wireless bits on 2.6.31 and
> that means any features/drivers/large fixes/enhancements that didn't
> make it to 2.6.31.
>
Isn't this the whole purpose of linux-backports-modules in ubuntu as well?
Kunal
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox