* iwlwifi connection troubles, maybe aggregation related
From: Andrew Lutomirski @ 2009-11-03 23:38 UTC (permalink / raw)
To: linux-wireless, ilw
Hi all-
My laptop (Intel 5350) has trouble using the wireless networks here.
I'm at MIT, which has a bunch of Cisco 1250 AP's (dual-band, MIMO,
etc). Running Windows, everything works perfectly. On Linux
(2.6.31-rc5, but I've seen problems with other, older kernels as
well), it sometimes works, but I frequently find the network almost
completely unusable. I can associate and ping just fine, but, as soon
as I try to send any significant amount of data, I can no longer
transmit. I can still receive both broadcast and unicast frames, but
the network doesn't see anything I send. An older laptop (presumably
with 4965,
This seems to be correlated with a line like:
iwlagn 0000:03:00.0: iwl_tx_agg_start on ra = 00:21:d8:49:4a:52 tid = 0
appearing in dmesg.
Running "iw dev wlan0 disconnect" will make the connection start
working until I try to send data again (presumably because either NM
or wpa_supplicant will reassociate).
Turning on or off power management and fiddling with
no_sleep_autoadjust makes no difference. Setting tx_agg_tid_enable to
zero in debugfs while the connection was working seemed to make it a
little more reliable (it lasted long enough to do "git pull" but not
much longer).
After running "iw dev wlan0 disconnect" a few times, I start to get
errors like this:
[18078.209635] iwlagn 0000:03:00.0: SENSITIVITY_CMD failed
[18078.313461] iwlagn 0000:03:00.0: No space for Tx
[18078.313467] iwlagn 0000:03:00.0: Error sending SENSITIVITY_CMD:
enqueue_hcmd failed: -28
[18078.313470] iwlagn 0000:03:00.0: SENSITIVITY_CMD failed
[18078.522409] iwlagn 0000:03:00.0: No space for Tx
[18078.522414] iwlagn 0000:03:00.0: Error sending SENSITIVITY_CMD:
enqueue_hcmd failed: -28
The driver doesn't recover until I do "echo 1 >
/sys/kernel/debug/ieee80211/phy0/reset" Oddly enough, after resetting
just now, I couldn't trigger the failure again, even though it was
100% reproducible before resetting.
Thanks,
Andy
^ permalink raw reply
* Re: [announce] new rt2800 drivers for Ralink wireless & project tree
From: Alan Cox @ 2009-11-03 23:48 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Ivo van Doorn, linux-wireless, linux-kernel, netdev, Randy Dunlap,
Luis Correia, John W. Linville, Ingo Molnar, Johannes Berg,
Jarek Poplawski, Pekka Enberg, David Miller
In-Reply-To: <200911032334.40547.bzolnier@gmail.com>
> > Yeah I know that. But like I said, I still needed to get around to do that,
> > and I am very happy you were interested in fixing it.
>
> Lets make one thing clear: YOU SHOULD BE THE ONE FIXING IT.
Really - you have a service and support contract with Ivo.. no i thought
not.
^ permalink raw reply
* Re: [PATCH] ar9170usb: add mode-switching for AVM Fritz!WLAN USB N devices in cdrom mode
From: Oliver Neukum @ 2009-11-03 23:55 UTC (permalink / raw)
To: Alan Stern
Cc: Dan Williams, Matthew Dharm, Frank Schaefer, linux-wireless,
linux-usb
In-Reply-To: <Pine.LNX.4.44L0.0911031745010.21065-100000@netrider.rowland.org>
Am Dienstag, 3. November 2009 23:47:55 schrieb Alan Stern:
> On Tue, 3 Nov 2009, Oliver Neukum wrote:
> > > I'm with Matt Dharm and Josua Dietze on this. Jobs that can be handled
> > > in userspace _should_ be handled there.
> >
> > There is the inconvenient problem of hibernation. And, if more systems
> > start cutting power to USB in STR, the problem of STR. I am inclined
> > to declare that hibernation is a problem of those pesky misdesigns.
> > But dare we say that also about STR?
>
> If power is turned off, there's nothing we can do about it. Once that
> happens, it doesn't make much difference whether the mode switch occurs
> in usb-storage or from a userspace program. The old device instance
> will go away and a new one will appear.
That is what happens and what must happen if we switch mode in user space.
In kernel space, the kernel could repeat the mode switch.
Regards
Oliver
^ permalink raw reply
* Re: [announce] new rt2800 drivers for Ralink wireless & project tree
From: Bartlomiej Zolnierkiewicz @ 2009-11-03 23:52 UTC (permalink / raw)
To: Alan Cox
Cc: Ivo van Doorn, linux-wireless, linux-kernel, netdev, Randy Dunlap,
Luis Correia, John W. Linville, Ingo Molnar, Johannes Berg,
Jarek Poplawski, Pekka Enberg, David Miller
In-Reply-To: <20091103234835.3042f7b5@lxorguk.ukuu.org.uk>
On Wednesday 04 November 2009 00:48:35 Alan Cox wrote:
> > > Yeah I know that. But like I said, I still needed to get around to do that,
> > > and I am very happy you were interested in fixing it.
> >
> > Lets make one thing clear: YOU SHOULD BE THE ONE FIXING IT.
>
> Really - you have a service and support contract with Ivo.. no i thought
> not.
Just today I got PM from somebody complaining to me about non-working
pata_pdc2026x_old (pdc202xx_old works fine for him) simply because
I fixed some bug there some time ago....
Problems are publicly know -- do you want bz# from Debian, SuSE or Red Hat?
Wait.. unfortunately I also don't have support contract with you..
--
Bartlomiej Zolnierkiewicz
^ permalink raw reply
* Re: [announce] new rt2800 drivers for Ralink wireless & project tree
From: Bartlomiej Zolnierkiewicz @ 2009-11-03 23:46 UTC (permalink / raw)
To: Gertjan van Wingerde
Cc: Ivo van Doorn, linux-wireless, linux-kernel, netdev, Randy Dunlap,
Luis Correia, John W. Linville, Ingo Molnar, Johannes Berg,
Jarek Poplawski, Pekka Enberg, David Miller
In-Reply-To: <14add3d10911031509l328e7674kb625b70250ff30fb@mail.gmail.com>
On Wednesday 04 November 2009 00:09:02 Gertjan van Wingerde wrote:
> On Tue, Nov 3, 2009 at 11:34 PM, Bartlomiej Zolnierkiewicz
> <bzolnier@gmail.com> wrote:
> > On Tuesday 03 November 2009 23:01:32 Ivo van Doorn wrote:
> >> > > > The following patch series (against wireless-next) addresses issues raised
> >> > > > during code review and subsequently rejected by rt2x00/wireless/networking
> >> > > > maintainers.
> >> > >
> >> > > Really stop reading only the half of emails, try reading it entirely (or at least don't
> >> > > stop at the second word in a sentence). It really starts the bug me to repeat
> >> > > myself over and over again because you refuse to read.
> >> > >
> >> > > Your comments during code review were ACCEPTED with the only remark that
> >> > > it shouldn't be done right here and now.
> >> >
> >> > Please stop this bullshit. We have some standards for the upstream code
> >> > and by being maintainer you have to live up to this standards and make sure
> >> > that they are respected instead of watering them down yourself..
> >> >
> >> > You were not interested even in fixing the headers duplication (it turned
> >> > out debugging scripts needed only 25 lines of code to be able to work with
> >> > fixed headers -- 25 LOC in bash scripts used only for debugging instead
> >> > of 1800 LOC of kernel code).
> >>
> >> Yeah I know that. But like I said, I still needed to get around to do that,
> >> and I am very happy you were interested in fixing it.
> >
> > Lets make one thing clear: YOU SHOULD BE THE ONE FIXING IT.
> >
> > I'm not in slightest interested in wasting my time on such
> > things and educating some maintainers about basics.
> >
> > [ Code duplication is bad, mmm'okay? Just say no, mmm'okay? ]
> >
>
> Bart,
>
> Are you really interested in working with us (the rt2x00 project) in
> getting the rt2800{pci,usb}
> drivers in a better shape, or do you just want to continue your
> ramblings on how bad you
> think the rt2x00 maintainers, wireless maintainer, and networking
> maintainer are in your view?
>
> Just continuing these discussions doesn't help a bit as Ivo, John, and
> David said they disagreed
> with you on this topic.
I tried explain many times that it is not about what is in MAINTAINERS
file or what somebody says.
> If you just want to continue with a hostile take-over of the rt2800
> maintainership, then please
> let us know that, so that we stop spending time on useless
I fail to see why you see it as a hostile takeover.
I just did what should have been done in the first place (+ I'm going
to push drivers further in this direction in my tree) and I was always
pretty clear that once staging drivers become sufficiently cleaned up
I would start re-basing my efforts on in kernel drivers.
I will be glad to cooperate with you or anyone else from rt2x00 project.
However I will not spin in some stupid bureaucracy when I see that things
can be done more effectively.
> discussions, and let John Linville
> decide how he wants to handle this situation. It would be a shame of
> the good patches and work
> you did, but if that's the case, than that's it.
John can just pull my tree in right now since it is based on his tree
and it would be an immediate improvement over what its in his tree.
It is up to him, or Ivo can also pull my patches into his tree.
You can also decide to throw up my patches completely or re-do them
for some silly reasons. I won't be making much noise about it since
I'll be already on some next patches..
> Otherwise, please focus on the technical contents of the patches and
> work with us to get
> these drivers in a better shape.
This is what I'm focused on, if you have any technical arguments w.r.t.
my patches I'm willing to listen and address them in sensible time
(if they are valid). I would also be happy to work with people with any
patches that they are working on currently.
Thanks.
--
Bartlomiej Zolnierkiewicz
^ permalink raw reply
* Re: [announce] new rt2800 drivers for Ralink wireless & project tree
From: Alan Cox @ 2009-11-04 0:40 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Ivo van Doorn, linux-wireless, linux-kernel, netdev, Randy Dunlap,
Luis Correia, John W. Linville, Ingo Molnar, Johannes Berg,
Jarek Poplawski, Pekka Enberg, David Miller
In-Reply-To: <200911040052.28323.bzolnier@gmail.com>
On Wed, 4 Nov 2009 00:52:28 +0100
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
> On Wednesday 04 November 2009 00:48:35 Alan Cox wrote:
> > > > Yeah I know that. But like I said, I still needed to get around to do that,
> > > > and I am very happy you were interested in fixing it.
> > >
> > > Lets make one thing clear: YOU SHOULD BE THE ONE FIXING IT.
> >
> > Really - you have a service and support contract with Ivo.. no i thought
> > not.
>
> Just today I got PM from somebody complaining to me about non-working
> pata_pdc2026x_old (pdc202xx_old works fine for him) simply because
> I fixed some bug there some time ago....
And didn't bother committing a patch to both sets of code bec
^ permalink raw reply
* Re: [announce] new rt2800 drivers for Ralink wireless & project tree
From: Bartlomiej Zolnierkiewicz @ 2009-11-04 0:48 UTC (permalink / raw)
To: Alan Cox
Cc: Ivo van Doorn, linux-wireless, linux-kernel, netdev, Randy Dunlap,
Luis Correia, John W. Linville, Ingo Molnar, Johannes Berg,
Jarek Poplawski, Pekka Enberg, David Miller
In-Reply-To: <20091104004015.23c4c1a3@lxorguk.ukuu.org.uk>
On Wednesday 04 November 2009 01:40:15 Alan Cox wrote:
> On Wed, 4 Nov 2009 00:52:28 +0100
> Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
>
> > On Wednesday 04 November 2009 00:48:35 Alan Cox wrote:
> > > > > Yeah I know that. But like I said, I still needed to get around to do that,
> > > > > and I am very happy you were interested in fixing it.
> > > >
> > > > Lets make one thing clear: YOU SHOULD BE THE ONE FIXING IT.
> > >
> > > Really - you have a service and support contract with Ivo.. no i thought
> > > not.
> >
> > Just today I got PM from somebody complaining to me about non-working
> > pata_pdc2026x_old (pdc202xx_old works fine for him) simply because
> > I fixed some bug there some time ago....
>
> And didn't bother committing a patch to both sets of code bec
You misread my mail.
Because I also fixed bug in the PATA code though I was IDE Maintainer.
Also:
Did you have a service & support contract with me when you were complaining
about IDE to me? [ and I would strongly suggest you not to go there.. ]
Or reversing the initial question:
Does Ivo have a contract with me to contribute to rt2x00 project?
So please stop idiotic arguments.
--
Bartlomiej Zolnierkiewicz
^ permalink raw reply
* compat-wireless and minstrel
From: Adam Wozniak @ 2009-11-04 1:13 UTC (permalink / raw)
To: linux-wireless; +Cc: nbd, derek
I have two systems under test, both Dell laptops (a Latitude D630 and an
Inspiron 600m) both running Ubuntu 9.10 with the latest updates, and
bleeding edge compat-wireless-2009-11-02. I'm using identical AR9170
based D-Link DWA-160 USB 802.11adapters. I'm using nuttcp to measure
throughput. I'm running in ad-hoc mode. Both machines have the same
ar9170 files in /lib/firmware. The machines are sitting about 5 feet
apart in my office.
I'm having occasional problems where throughput drops through the floor
(0.5Mbps - 1.5Mbps). When I cat
/sys/kernel/debug/ieee80211/*/stations/*/rc_stats, one of the machines
lists the full set of rates, but the other only lists 1M and 54M. After
a period of time, that machine drops 54M and lists only one rate
(1Mbps), and the throughput listed by nuttcp drops accordingly. I
assume that, for whatever reason, the rates drop off the list and
minstrel uses the only one left available to it.
If I modify include/net/mac80211.h and force the inline function
rate_supported to always return 1, this fixes the problem. However, I
think this is a band aid around some other issue.
Any clues or ideas what the real issue might be here?
^ permalink raw reply
* Re: [announce] new rt2800 drivers for Ralink wireless & project tree
From: Julian Calaby @ 2009-11-04 1:33 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Gertjan van Wingerde, Ivo van Doorn, linux-wireless, linux-kernel,
netdev, Randy Dunlap, Luis Correia, John W. Linville, Ingo Molnar,
Johannes Berg, Jarek Poplawski, Pekka Enberg, David Miller
In-Reply-To: <200911040046.54247.bzolnier@gmail.com>
On Wed, Nov 4, 2009 at 10:46, Bartlomiej Zolnierkiewicz
<bzolnier@gmail.com> wrote:
>> If you just want to continue with a hostile take-over of the rt2800
>> maintainership, then please
>> let us know that, so that we stop spending time on useless
>
> I fail to see why you see it as a hostile takeover.
Updating MAINTAINERS to replace the current developers with yourself
can be considered to be a hostile act.
If you want this for your own personal tree, then keep the patch
private - don't include it in pull requests, patch listings etc.
And if you genuinely want the maintainership of the rt28xx drivers,
then updating MAINTAINERS should be done as an afterthought after
clearly proving that you are capable of maintaining the driver and
working with the maintainers of the rt2x00 and wireless subsystems.
> I will be glad to cooperate with you or anyone else from rt2x00 project.
> However I will not spin in some stupid bureaucracy when I see that things
> can be done more effectively.
It's not "stupid bureaucracy" it's *how* *it's* *done*.
If I was going to submit a patch to the Marvell TOPDOG driver to add
support for another related chipset, I'd be going out of my way to
make sure that *everyone* involved was 100% happy so that the patch
can get out to the people who matter: the users.
Everyone has to do this, from big corporations like Intel, to you and
me. For example, I recall the Intel IWL developers being smacked down
a few months ago by John and David over exactly what constitutes a
post-merge window "bugfix".
The rules apply to everyone, just because you don't like them doesn't
mean you can ignore them.
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
.Plan: http://sites.google.com/site/juliancalaby/
^ permalink raw reply
* Re: iwlwifi connection troubles, maybe aggregation related
From: Greg Oliver @ 2009-11-04 1:47 UTC (permalink / raw)
To: Andrew Lutomirski; +Cc: linux-wireless, ilw
In-Reply-To: <cb0375e10911031538n62fe7473x4dd41329b9264b5c@mail.gmail.com>
On Tue, Nov 3, 2009 at 5:38 PM, Andrew Lutomirski <luto@mit.edu> wrote:
> Hi all-
>
> My laptop (Intel 5350) has trouble using the wireless networks here.
> I'm at MIT, which has a bunch of Cisco 1250 AP's (dual-band, MIMO,
> etc). Running Windows, everything works perfectly. On Linux
> (2.6.31-rc5, but I've seen problems with other, older kernels as
> well), it sometimes works, but I frequently find the network almost
> completely unusable. I can associate and ping just fine, but, as soon
> as I try to send any significant amount of data, I can no longer
> transmit. I can still receive both broadcast and unicast frames, but
> the network doesn't see anything I send. An older laptop (presumably
> with 4965,
>
> This seems to be correlated with a line like:
>
> iwlagn 0000:03:00.0: iwl_tx_agg_start on ra = 00:21:d8:49:4a:52 tid = 0
>
> appearing in dmesg.
>
> Running "iw dev wlan0 disconnect" will make the connection start
> working until I try to send data again (presumably because either NM
> or wpa_supplicant will reassociate).
>
> Turning on or off power management and fiddling with
> no_sleep_autoadjust makes no difference. Setting tx_agg_tid_enable to
> zero in debugfs while the connection was working seemed to make it a
> little more reliable (it lasted long enough to do "git pull" but not
> much longer).
>
> After running "iw dev wlan0 disconnect" a few times, I start to get
> errors like this:
>
> [18078.209635] iwlagn 0000:03:00.0: SENSITIVITY_CMD failed
> [18078.313461] iwlagn 0000:03:00.0: No space for Tx
> [18078.313467] iwlagn 0000:03:00.0: Error sending SENSITIVITY_CMD:
> enqueue_hcmd failed: -28
> [18078.313470] iwlagn 0000:03:00.0: SENSITIVITY_CMD failed
> [18078.522409] iwlagn 0000:03:00.0: No space for Tx
> [18078.522414] iwlagn 0000:03:00.0: Error sending SENSITIVITY_CMD:
> enqueue_hcmd failed: -28
>
> The driver doesn't recover until I do "echo 1 >
> /sys/kernel/debug/ieee80211/phy0/reset" Oddly enough, after resetting
> just now, I couldn't trigger the failure again, even though it was
> 100% reproducible before resetting.
I too have been battling this issue with a 5300 for quite some time..
I *thought* it was fixed with the 2.6.32 compat-wireless series
(excluding the -rc4 which kernel oops'ed), only to find out that it
was because I was farther away from the AP, and negotiating lower
rates...
My card seems to work just fine through MCS13, about 60% at MCS14, and
almost always fails at 15.. The intel folks were very helpful in
trying to fix it, but it was never actually resolved. I've been
battling it so long though, though, I was just prepared to wait for
the magic fix to just show up one day :)
My machine (like yours), once reliably connected will preform 100%
until I reboot or unload the module.. It may take 10 insmods to get a
reliable connection though..
I guess what I'm saying is that I can help debug the issue as well...
It would be very nice to have this go away... I have an icon on my
desktop to reload the wireless subsystem if that tells you how many
times I have to do it until it loads up reliably...
-Greg
^ permalink raw reply
* Re: [announce] new rt2800 drivers for Ralink wireless & project tree
From: Bartlomiej Zolnierkiewicz @ 2009-11-04 2:28 UTC (permalink / raw)
To: Julian Calaby
Cc: Gertjan van Wingerde, Ivo van Doorn, linux-wireless, linux-kernel,
netdev, Randy Dunlap, Luis Correia, John W. Linville, Ingo Molnar,
Johannes Berg, Jarek Poplawski, Pekka Enberg, David Miller
In-Reply-To: <646765f40911031733u1641c0dr5d4eec30031e7cea@mail.gmail.com>
On Wednesday 04 November 2009 02:33:52 Julian Calaby wrote:
> On Wed, Nov 4, 2009 at 10:46, Bartlomiej Zolnierkiewicz
> <bzolnier@gmail.com> wrote:
> >> If you just want to continue with a hostile take-over of the rt2800
> >> maintainership, then please
> >> let us know that, so that we stop spending time on useless
> >
> > I fail to see why you see it as a hostile takeover.
>
> Updating MAINTAINERS to replace the current developers with yourself
> can be considered to be a hostile act.
>
> If you want this for your own personal tree, then keep the patch
> private - don't include it in pull requests, patch listings etc.
This is not pull request etc. but since the change in question has been
stirring needless controversies and distracting people from reading patches
it has been dropped for now.
--
Bartlomiej Zolnierkiewicz
^ permalink raw reply
* Re: [PATCH] ar9170usb: add mode-switching for AVM Fritz!WLAN USB N devices in cdrom mode
From: Alan Stern @ 2009-11-04 3:57 UTC (permalink / raw)
To: Oliver Neukum
Cc: Dan Williams, Matthew Dharm, Frank Schaefer, linux-wireless,
linux-usb
In-Reply-To: <200911040055.01441.oliver@neukum.org>
On Wed, 4 Nov 2009, Oliver Neukum wrote:
> > If power is turned off, there's nothing we can do about it. Once that
> > happens, it doesn't make much difference whether the mode switch occurs
> > in usb-storage or from a userspace program. The old device instance
> > will go away and a new one will appear.
>
> That is what happens and what must happen if we switch mode in user space.
> In kernel space, the kernel could repeat the mode switch.
How? Doesn't the mode switch cause a change in the configuration,
interface, or endpoint descriptors? The end result would be the same
-- the old device instance would go away and a new one would appear.
Alan Stern
^ permalink raw reply
* Help regarding wireless driver programming
From: vikram g @ 2009-11-04 4:47 UTC (permalink / raw)
To: linux-wireless
Hi all,
I am a graduate student who wants to work on a
project which uses one wireless card to connect to more than one
network using time multiplexing at the same time. Yes, it is very
similar to virtualwifi by microsoft. But I want to accomplish it on
linux.
About me :
Bads :
1) I am not very good at systems programming.
2) The only things I have done are some kinds of socket programming and have some knowledge of packet sniffing techniques related to networks.
3) I am not very knowledgeable about wireless device drivers or device driver layer for wireless networks.
etc.
Can you please help me finding me a place to start. I have gone through the only material on linuxwireless.org (about mac80211 and cfg80211 slides), but as I said I am not very
knowledgeable I did not understand much of it. Also I went very quickly
skimmed through the source code for ath9k and iwlwifi slides. But it
seems that the functionality I am looking for is not present in those
layers. All the things I am looking for are 1) To know where the kernel
connects to a wireless network by its SSID. 2) where it receives packets from the network layer that
is IP protocol (by where I mean where in the source code is it
implemented) so that I can capture them before it is passed to the 2nd
layer of the OSI model.
I do not know actually if this project is going to be
successfull given my less knowledge. Also it would be great if I get
any feedback from any of you.
I really really appreciate the
time of all you guys. I know I am a beginner and I do not know if this
mailing list is not for beginners. Please forgive me if this mailing
list is not for guys like me and let me know about the same.
Thanks,
Vikram Gade
Masters student in CS, University of New Mexico, Albuquerque, New Mexico
PS: Please forgive me for any incorrect or bad English that may have crept in
^ permalink raw reply
* [RFC] usb: Check results of dma_map_single
From: Larry Finger @ 2009-11-04 5:48 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-wireless, linux-usb
At http://marc.info/?l=linux-wireless&m=125695331205062&w=2, a problem
with DMA buffer processing was corrected for the libertas driver. Because
routine usb_fill_bulk_urb() does not check that DMA is possible when
dma_map_single() is called, this condition was not detected until the buffer
was unmapped. By this time memory corruption had occurred.
The situation is fixed by testing the returned DMA address. If not a legal
address, a WARN_ON(1) is executed to provide traceback and the error is
returned.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
Index: linux-2.6/drivers/usb/core/hcd.c
===================================================================
--- linux-2.6.orig/drivers/usb/core/hcd.c
+++ linux-2.6/drivers/usb/core/hcd.c
@@ -1281,6 +1281,13 @@ static int map_urb_for_dma(struct usb_hc
urb->setup_packet,
sizeof(struct usb_ctrlrequest),
DMA_TO_DEVICE);
+ ret = dma_mapping_error(hcd->self.controller,
+ urb->setup_dma);
+ /* warn if DMA mapping failed */
+ if (ret) {
+ WARN_ON(1);
+ return ret;
+ }
else if (hcd->driver->flags & HCD_LOCAL_MEM)
ret = hcd_alloc_coherent(
urb->dev->bus, mem_flags,
@@ -1299,6 +1306,13 @@ static int map_urb_for_dma(struct usb_hc
urb->transfer_buffer,
urb->transfer_buffer_length,
dir);
+ ret = dma_mapping_error(hcd->self.controller,
+ urb->transfer_dma);
+ /* warn if DMA mapping failed */
+ if (ret) {
+ WARN_ON(1);
+ return ret;
+ }
else if (hcd->driver->flags & HCD_LOCAL_MEM) {
ret = hcd_alloc_coherent(
urb->dev->bus, mem_flags,
^ permalink raw reply
* Re: Possible fix for rtl8187: kernel oops when leds enabled
From: Richard Farina @ 2009-11-04 5:50 UTC (permalink / raw)
To: Larry Finger
Cc: wireless, Hin-Tak Leung, Herton Ronaldo Krzesinski, John Linville
In-Reply-To: <4AF0BB45.5000402@lwfinger.net>
Larry Finger wrote:
> Rick,
>
> Does this patch fix your problem? I tried to bisect this problem as it
> looked like a regression; however, the problem was sometimes a little
> flakey. On one boot of a given kernel, it might run for 3-400 cycles
> without failing, then fail immediately after rebooting. I suspect that
> the random contents of some memory location would control that.
>
>
Larry,
As you mentioned, this bug was not 100% reliable to reproduce in the
first place for either of us, I merely had a much much higher chance of
panick for some unknown reason. That said, I have plugged and unplugged
the device a few dozen times while bringing the interface up and down
and making the led blink and I'm thrilled to say it no longer kernel
panicks on my system. I'm left with a usable wifi card with a cool
flashing led, many thanks for fixing this.
John,
imho this patch should go upstream asap, next dot release if at all
possible. This fixes a significant issue in that the kernel panicked on
my system nearly 100% of the time on unplug if the led was enabled.
Either way it is up to the maintainers but consider this my vote of
confidence.
Acked-By: Rick Farina
Tested-By: Rick Farina
Thanks,
Rick Farina
> This patch was inspired by the code in p54usb, which does not have the
> problem.
>
>
> Index: wireless-testing/drivers/net/wireless/rtl818x/rtl8187_leds.c
> ===================================================================
> --- wireless-testing.orig/drivers/net/wireless/rtl818x/rtl8187_leds.c
> +++ wireless-testing/drivers/net/wireless/rtl818x/rtl8187_leds.c
> @@ -210,10 +210,10 @@ void rtl8187_leds_exit(struct ieee80211_
>
> /* turn the LED off before exiting */
> ieee80211_queue_delayed_work(dev, &priv->led_off, 0);
> - cancel_delayed_work_sync(&priv->led_off);
> - cancel_delayed_work_sync(&priv->led_on);
> rtl8187_unregister_led(&priv->led_rx);
> rtl8187_unregister_led(&priv->led_tx);
> + cancel_delayed_work_sync(&priv->led_off);
> + cancel_delayed_work_sync(&priv->led_on);
> }
> #endif /* def CONFIG_RTL8187_LED */
>
> Thanks for testing,
>
> Larry
>
>
>
>
>
>
>
>
^ permalink raw reply
* [PATCH] rtl8187: Fix kernel oops when device is removed when LEDS enabled (Bugzilla #14539)
From: Larry Finger @ 2009-11-04 6:00 UTC (permalink / raw)
To: John W Linville
Cc: Herton Ronaldo Krzesinski, Hin-Tak Leung, sidhayn, linux-wireless
As reported by Rick Farina (sidhayn@gmail.com), removing the RTL8187 USB
stick, or unloading the driver rtl8187 using rmmod will cause a kernel oops.
There are at least two forms of the failure, (1) BUG: Scheduling while atomic,
and (2) a fatal kernel page fault. This problem is reported in Bugzilla #14539.
This problem does not occur for kernel 2.6.31, but does for 2.6.32-rc2, thus
it is technically a regression; however, bisection did not locate any faulty
patch. The fix was found by comparing the faulty code in rtl8187 with p54usb.
My interpretation is that the handling of work queues in mac80211 changed
enough to the LEDs to be unregistered before tasks on the work queues are
cancelled. Previously, these actions could be done in either order.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Reported-and-tested by: Rick Farina <sidhayn@gmail.com>
---
John,
This is 2.6.32 material. Sorry to take so long to get a patch, but it was
difficult for me to locate the problem. Fortunately, I had the postings of the
two flame wars to amuse me while all the kernel compilations were happening.
Larry
---
Index: wireless-testing/drivers/net/wireless/rtl818x/rtl8187_leds.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/rtl818x/rtl8187_leds.c
+++ wireless-testing/drivers/net/wireless/rtl818x/rtl8187_leds.c
@@ -210,10 +210,10 @@ void rtl8187_leds_exit(struct ieee80211_
/* turn the LED off before exiting */
ieee80211_queue_delayed_work(dev, &priv->led_off, 0);
- cancel_delayed_work_sync(&priv->led_off);
- cancel_delayed_work_sync(&priv->led_on);
rtl8187_unregister_led(&priv->led_rx);
rtl8187_unregister_led(&priv->led_tx);
+ cancel_delayed_work_sync(&priv->led_off);
+ cancel_delayed_work_sync(&priv->led_on);
}
#endif /* def CONFIG_RTL8187_LED */
^ permalink raw reply
* Re: Please consider reverting 7d930bc33653d5592dc386a76a38f39c2e962344
From: Andrew Morton @ 2009-11-04 6:34 UTC (permalink / raw)
To: Johannes Berg
Cc: Marcel Holtmann, Dmitry Torokhov, David Miller, torvalds,
linville, linux-kernel, linux-wireless
In-Reply-To: <1257234299.28469.25.camel@johannes.local>
On Tue, 03 Nov 2009 08:44:59 +0100 Johannes Berg <johannes@sipsolutions.net> wrote:
> On Tue, 2009-11-03 at 16:16 +0900, Marcel Holtmann wrote:
>
> > and can we please stop jumping the gun here and going past the subsystem
> > maintainers. I think this happens a little bit too much lately.
>
> I'll rant a bit too -- I've been very annoyed by this many times.
Problem is, subsystem maintainers are very unreliable.
Right now I'm sitting on 17 patches which I think should be in 2.6.32,
which I need to plead with subsystem maintainers to take a look at.
They've already seen the patches (usually at least twice) and they've
just blown them off. This is typical.
And then there are the 100 to 200 non-critical patches which I'm always
sitting on, similarly ignored. And I'm increasingly just ignoring
stuff nowadays because this situation is so bad.
And then there are all the bug reports which flow in one ear and out
the other.
Now, some subsystem maintainer are good, and some aren't. I'm probably
the only person who could write the detailed list for each column.
Unfortunately, people who have better lives than me are best off
assuming that a subsystem maintainer is unreliable. If the problem is
severe enough, bypassing the maintainer is a sensible default.
^ permalink raw reply
* Re: [announce] new rt2800 drivers for Ralink wireless & project tree
From: Ingo Molnar @ 2009-11-04 8:37 UTC (permalink / raw)
To: Ivo van Doorn
Cc: Bartlomiej Zolnierkiewicz, linux-wireless, linux-kernel, netdev,
Randy Dunlap, Luis Correia, John W. Linville, Johannes Berg,
Jarek Poplawski, Pekka Enberg, David Miller
In-Reply-To: <200911032200.04516.IvDoorn@gmail.com>
* Ivo van Doorn <ivdoorn@gmail.com> wrote:
> > MAINTAINERS: add rt2800 entry
>
> I see you decided to take over the maintainership? Doesn't that need
> the current maintainer to move away, or was this part of the "going
> over other peoples head" plan?
>
> [...]
>
> These are too much (and too big) patches for me to review at once,
> I'll look at them later.
Frankly, having read through the recent discussions related to the
rt2800pci/usb drivers, the subtle (and largely undeserved) group
violence and abuse you are inflicting on Bart is stomach-turning.
The non-working rt2800pci driver has been pending in your private tree
for how long, 1.5 _years_?
Look at the diffstat of Bart's driver:
15 files changed, 4036 insertions(+), 7158 deletions(-)
He reduced your 5.2 KLOC non-working driver into a 1.8 KLOC _working_
driver.
And _still_ your complaint about Bart's series is that he updated the
MAINTAINERS entry and added an entry for rt2800? Heck _sure_ he should
update it, he is the one doing the hard work of trying to bring it to
users, trying to clean up a messy driver space, trying to turn crap into
gold.
The thing is, if you dont have the time or interest to listen to and act
upon review feedback, be constructive about it and fix (obvious)
structural problems in your rt2800 code, you should just step aside and
let Bart maintain what he is apparently more capable of maintaining than
you are.
What you are doing here is a thinly veiled land-grab: you did a minimal
token driver for rt2800 that doesnt work, kept it in your private tree
for _1.5 years_, and the moment someone _else_ came along and did
something better and more functional in drivers/staging/, you discovered
your sudden interest for it and moved the crappy driver upstream at
lightning's speed (it is already in net-next AFAICS, despite negative
test and review feedback) - ignoring and throwing away all the work that
Bart has done.
Such behavior wouldnt fly in _any_ other Linux subsystem, but apparently
there is one set of rules for upstream kernel maintainers and then
there's another, different set of rules for upstream wireless driver
maintainers.
Really, you should listen to contrary opinion and _you_ should work
_hard_ to integrate Bart socially and open up your close circle of
wireless insiders instead of fighting his 'outsider' contributions every
which way. We dont care if people are rough, express displeasure and
show strong opinion about crappy code - but the moment you are
_excluding_ capable people and playing petty office politics (like you
are very clearly doing it with Bart here) everyone loses.
Guys, show some minimal amount of honesty, openness and critical
thinking please ...
Ingo
^ permalink raw reply
* Re: Please consider reverting 7d930bc33653d5592dc386a76a38f39c2e962344
From: David Miller @ 2009-11-04 8:41 UTC (permalink / raw)
To: akpm
Cc: johannes, marcel, dmitry.torokhov, torvalds, linville,
linux-kernel, linux-wireless
In-Reply-To: <20091103223433.23765578.akpm@linux-foundation.org>
From: Andrew Morton <akpm@linux-foundation.org>
Date: Tue, 3 Nov 2009 22:34:33 -0800
> Problem is, subsystem maintainers are very unreliable.
This is common, but not universal Andrew.
Or, if it is, what patches from you have I been sitting on? :-)
^ permalink raw reply
* Re: iwlwifi connection troubles, maybe aggregation related
From: Johannes Berg @ 2009-11-04 9:30 UTC (permalink / raw)
To: Andrew Lutomirski; +Cc: linux-wireless, ilw
In-Reply-To: <cb0375e10911031538n62fe7473x4dd41329b9264b5c@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1151 bytes --]
On Tue, 2009-11-03 at 18:38 -0500, Andrew Lutomirski wrote:
> iwlagn 0000:03:00.0: iwl_tx_agg_start on ra = 00:21:d8:49:4a:52 tid = 0
> Turning on or off power management and fiddling with
> no_sleep_autoadjust makes no difference. Setting tx_agg_tid_enable to
> zero in debugfs while the connection was working seemed to make it a
> little more reliable (it lasted long enough to do "git pull" but not
> much longer).
>
> After running "iw dev wlan0 disconnect" a few times, I start to get
> errors like this:
>
> [18078.209635] iwlagn 0000:03:00.0: SENSITIVITY_CMD failed
> [18078.313461] iwlagn 0000:03:00.0: No space for Tx
> [18078.313467] iwlagn 0000:03:00.0: Error sending SENSITIVITY_CMD:
> enqueue_hcmd failed: -28
> [18078.313470] iwlagn 0000:03:00.0: SENSITIVITY_CMD failed
> [18078.522409] iwlagn 0000:03:00.0: No space for Tx
> [18078.522414] iwlagn 0000:03:00.0: Error sending SENSITIVITY_CMD:
> enqueue_hcmd failed: -28
Sounds like the firmware messes up ...
Maybe as a first workaround you could modprobe iwlagn with
11n_disable=1. But I don't know at this point what the problem could be.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] ar9170usb: add mode-switching for AVM Fritz!WLAN USB N devices in cdrom mode
From: Oliver Neukum @ 2009-11-04 9:11 UTC (permalink / raw)
To: Alan Stern
Cc: Dan Williams, Matthew Dharm, Frank Schaefer, linux-wireless,
linux-usb
In-Reply-To: <Pine.LNX.4.44L0.0911032255190.25039-100000@netrider.rowland.org>
Am Mittwoch, 4. November 2009 04:57:59 schrieb Alan Stern:
> On Wed, 4 Nov 2009, Oliver Neukum wrote:
> > > If power is turned off, there's nothing we can do about it. Once that
> > > happens, it doesn't make much difference whether the mode switch occurs
> > > in usb-storage or from a userspace program. The old device instance
> > > will go away and a new one will appear.
> >
> > That is what happens and what must happen if we switch mode in user
> > space. In kernel space, the kernel could repeat the mode switch.
>
> How? Doesn't the mode switch cause a change in the configuration,
> interface, or endpoint descriptors? The end result would be the same
> -- the old device instance would go away and a new one would appear.
But it switches to a known state which we could use to trigger a switch
and recompare after the switch.
Regards
Oliver
^ permalink raw reply
* Re: iwlwifi connection troubles, maybe aggregation related
From: Greg Oliver @ 2009-11-04 10:59 UTC (permalink / raw)
To: Johannes Berg; +Cc: Andrew Lutomirski, linux-wireless, ilw
In-Reply-To: <1257327017.28469.76.camel@johannes.local>
On Wed, Nov 4, 2009 at 3:30 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Tue, 2009-11-03 at 18:38 -0500, Andrew Lutomirski wrote:
>
>> iwlagn 0000:03:00.0: iwl_tx_agg_start on ra = 00:21:d8:49:4a:52 tid = 0
>
>> Turning on or off power management and fiddling with
>> no_sleep_autoadjust makes no difference. Setting tx_agg_tid_enable to
>> zero in debugfs while the connection was working seemed to make it a
>> little more reliable (it lasted long enough to do "git pull" but not
>> much longer).
>>
>> After running "iw dev wlan0 disconnect" a few times, I start to get
>> errors like this:
>>
>> [18078.209635] iwlagn 0000:03:00.0: SENSITIVITY_CMD failed
>> [18078.313461] iwlagn 0000:03:00.0: No space for Tx
>> [18078.313467] iwlagn 0000:03:00.0: Error sending SENSITIVITY_CMD:
>> enqueue_hcmd failed: -28
>> [18078.313470] iwlagn 0000:03:00.0: SENSITIVITY_CMD failed
>> [18078.522409] iwlagn 0000:03:00.0: No space for Tx
>> [18078.522414] iwlagn 0000:03:00.0: Error sending SENSITIVITY_CMD:
>> enqueue_hcmd failed: -28
>
> Sounds like the firmware messes up ...
>
> Maybe as a first workaround you could modprobe iwlagn with
> 11n_disable=1. But I don't know at this point what the problem could be.
>
> johannes
>
I am also still getting oops' with -rc5..
[36759.355012] Pid: 0, comm: swapper Tainted: P
2.6.31-14-generic #48-Ubuntu
[36759.355018] Call Trace:
[36759.355022] <IRQ> [<ffffffff810e083c>] __alloc_pages_slowpath+0x4cc/0x4e0
[36759.355047] [<ffffffff810e099e>] __alloc_pages_nodemask+0x14e/0x150
[36759.355059] [<ffffffff81111dfa>] kmalloc_large_node+0x5a/0xb0
[36759.355067] [<ffffffff81115fa5>] __kmalloc_node_track_caller+0x135/0x180
[36759.355109] [<ffffffffa03c7977>] ? iwl_rx_allocate+0x197/0x2f0 [iwlcore]
[36759.355121] [<ffffffff8142e41b>] __alloc_skb+0x7b/0x180
[36759.355146] [<ffffffffa03c7977>] iwl_rx_allocate+0x197/0x2f0 [iwlcore]
[36759.355171] [<ffffffffa03c8de6>] iwl_rx_replenish_now+0x16/0x30 [iwlcore]
[36759.355191] [<ffffffffa03e4f18>] iwl_rx_handle+0x288/0x2f0 [iwlagn]
[36759.355208] [<ffffffffa03e5708>] iwl_irq_tasklet+0x138/0x4e0 [iwlagn]
[36759.355220] [<ffffffff810741e0>] ? delayed_work_timer_fn+0x0/0x40
[36759.355228] [<ffffffff81073d82>] ? insert_work+0x72/0xc0
[36759.355239] [<ffffffff81036419>] ? default_spin_lock_flags+0x9/0x10
[36759.355248] [<ffffffff81063ee0>] tasklet_action+0xd0/0xe0
[36759.355257] [<ffffffff8106549d>] __do_softirq+0xbd/0x200
[36759.355266] [<ffffffff810131ec>] call_softirq+0x1c/0x30
[36759.355273] [<ffffffff81014bc5>] do_softirq+0x55/0x90
[36759.355281] [<ffffffff81065205>] irq_exit+0x85/0x90
[36759.355287] [<ffffffff81014100>] do_IRQ+0x70/0xe0
[36759.355296] [<ffffffff81012a13>] ret_from_intr+0x0/0x11
[36759.355301] <EOI> [<ffffffff812d7ed9>] ? acpi_idle_enter_bm+0x28b/0x2bf
[36759.355317] [<ffffffff812d7ed2>] ? acpi_idle_enter_bm+0x284/0x2bf
[36759.355327] [<ffffffff813fe40b>] ? cpuidle_idle_call+0x9b/0xf0
[36759.355335] [<ffffffff81010e12>] ? cpu_idle+0xb2/0x100
[36759.355344] [<ffffffff81514c56>] ? rest_init+0x66/0x70
[36759.355355] [<ffffffff8183a047>] ? start_kernel+0x352/0x35b
[36759.355364] [<ffffffff8183959a>] ? x86_64_start_reservations+0x125/0x129
[36759.355372] [<ffffffff81839698>] ? x86_64_start_kernel+0xfa/0x109
Same oops' as with -rc4 it seems.. It does not hard lock anything -
this is not during any suspend/resume.. This laptop is always on..
[36894.090466] iwlagn 0000:04:00.0: Failed to allocate SKB buffer with
GFP_ATOMIC. Only 0 free buffers remaining.
-Greg
^ permalink raw reply
* Re: iwlwifi connection troubles, maybe aggregation related
From: Greg Oliver @ 2009-11-04 11:32 UTC (permalink / raw)
To: Johannes Berg; +Cc: Andrew Lutomirski, linux-wireless, ilw
In-Reply-To: <51058d550911040259k1da3a624wc6325c78b954d56f@mail.gmail.com>
On Wed, Nov 4, 2009 at 4:59 AM, Greg Oliver <oliver.greg@gmail.com> wrote:
> On Wed, Nov 4, 2009 at 3:30 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
>> On Tue, 2009-11-03 at 18:38 -0500, Andrew Lutomirski wrote:
>>
>>> iwlagn 0000:03:00.0: iwl_tx_agg_start on ra = 00:21:d8:49:4a:52 tid = 0
>>
>>> Turning on or off power management and fiddling with
>>> no_sleep_autoadjust makes no difference. Setting tx_agg_tid_enable to
>>> zero in debugfs while the connection was working seemed to make it a
>>> little more reliable (it lasted long enough to do "git pull" but not
>>> much longer).
>>>
>>> After running "iw dev wlan0 disconnect" a few times, I start to get
>>> errors like this:
>>>
>>> [18078.209635] iwlagn 0000:03:00.0: SENSITIVITY_CMD failed
>>> [18078.313461] iwlagn 0000:03:00.0: No space for Tx
>>> [18078.313467] iwlagn 0000:03:00.0: Error sending SENSITIVITY_CMD:
>>> enqueue_hcmd failed: -28
>>> [18078.313470] iwlagn 0000:03:00.0: SENSITIVITY_CMD failed
>>> [18078.522409] iwlagn 0000:03:00.0: No space for Tx
>>> [18078.522414] iwlagn 0000:03:00.0: Error sending SENSITIVITY_CMD:
>>> enqueue_hcmd failed: -28
>>
>> Sounds like the firmware messes up ...
>>
>> Maybe as a first workaround you could modprobe iwlagn with
>> 11n_disable=1. But I don't know at this point what the problem could be.
>>
>> johannes
>>
>
> I am also still getting oops' with -rc5..
>
> [36759.355012] Pid: 0, comm: swapper Tainted: P
> 2.6.31-14-generic #48-Ubuntu
> [36759.355018] Call Trace:
> [36759.355022] <IRQ> [<ffffffff810e083c>] __alloc_pages_slowpath+0x4cc/0x4e0
> [36759.355047] [<ffffffff810e099e>] __alloc_pages_nodemask+0x14e/0x150
> [36759.355059] [<ffffffff81111dfa>] kmalloc_large_node+0x5a/0xb0
> [36759.355067] [<ffffffff81115fa5>] __kmalloc_node_track_caller+0x135/0x180
> [36759.355109] [<ffffffffa03c7977>] ? iwl_rx_allocate+0x197/0x2f0 [iwlcore]
> [36759.355121] [<ffffffff8142e41b>] __alloc_skb+0x7b/0x180
> [36759.355146] [<ffffffffa03c7977>] iwl_rx_allocate+0x197/0x2f0 [iwlcore]
> [36759.355171] [<ffffffffa03c8de6>] iwl_rx_replenish_now+0x16/0x30 [iwlcore]
> [36759.355191] [<ffffffffa03e4f18>] iwl_rx_handle+0x288/0x2f0 [iwlagn]
> [36759.355208] [<ffffffffa03e5708>] iwl_irq_tasklet+0x138/0x4e0 [iwlagn]
> [36759.355220] [<ffffffff810741e0>] ? delayed_work_timer_fn+0x0/0x40
> [36759.355228] [<ffffffff81073d82>] ? insert_work+0x72/0xc0
> [36759.355239] [<ffffffff81036419>] ? default_spin_lock_flags+0x9/0x10
> [36759.355248] [<ffffffff81063ee0>] tasklet_action+0xd0/0xe0
> [36759.355257] [<ffffffff8106549d>] __do_softirq+0xbd/0x200
> [36759.355266] [<ffffffff810131ec>] call_softirq+0x1c/0x30
> [36759.355273] [<ffffffff81014bc5>] do_softirq+0x55/0x90
> [36759.355281] [<ffffffff81065205>] irq_exit+0x85/0x90
> [36759.355287] [<ffffffff81014100>] do_IRQ+0x70/0xe0
> [36759.355296] [<ffffffff81012a13>] ret_from_intr+0x0/0x11
> [36759.355301] <EOI> [<ffffffff812d7ed9>] ? acpi_idle_enter_bm+0x28b/0x2bf
> [36759.355317] [<ffffffff812d7ed2>] ? acpi_idle_enter_bm+0x284/0x2bf
> [36759.355327] [<ffffffff813fe40b>] ? cpuidle_idle_call+0x9b/0xf0
> [36759.355335] [<ffffffff81010e12>] ? cpu_idle+0xb2/0x100
> [36759.355344] [<ffffffff81514c56>] ? rest_init+0x66/0x70
> [36759.355355] [<ffffffff8183a047>] ? start_kernel+0x352/0x35b
> [36759.355364] [<ffffffff8183959a>] ? x86_64_start_reservations+0x125/0x129
> [36759.355372] [<ffffffff81839698>] ? x86_64_start_kernel+0xfa/0x109
>
> Same oops' as with -rc4 it seems.. It does not hard lock anything -
> this is not during any suspend/resume.. This laptop is always on..
>
> [36894.090466] iwlagn 0000:04:00.0: Failed to allocate SKB buffer with
> GFP_ATOMIC. Only 0 free buffers remaining.
>
> -Greg
>
Disregard that - I forgot I was not using the -rc5 currently....
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Pavel Machek @ 2009-11-02 21:16 UTC (permalink / raw)
To: Luis Correia
Cc: John W. Linville, Ingo Molnar, Johannes Berg, Jarek Poplawski,
Bartlomiej Zolnierkiewicz, Pekka Enberg, David Miller,
linux-wireless, netdev, linux-kernel
In-Reply-To: <efe7343f0911020932l21a570c8u9478568329d38e2c@mail.gmail.com>
> About Bartlomiej, there is only one more thing that I'll say:
>
> I've searched on my GMail archives and the only patch Bart has
> provided so far for the rt2x00 project is this:
>
> [PATCH] MAINTAINERS: rt2x00 list is moderated
>
> Which, while technically correct, adds nothing to the project.
>
> So, I will personally continue to ignore Bart's comments, regards and
> rants, until he provides patches for rt2x00 that actually make the
> driver better.
Well, he provided review feedback... he should be thanked for that,
not flamed for it.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [RFC] usb: Check results of dma_map_single
From: Paulius Zaleckas @ 2009-11-04 12:50 UTC (permalink / raw)
To: Larry Finger; +Cc: Greg Kroah-Hartman, linux-wireless, linux-usb
In-Reply-To: <4af115c3.JUDAYfcydqPYCYyH%Larry.Finger@lwfinger.net>
On 11/04/2009 07:48 AM, Larry Finger wrote:
> At http://marc.info/?l=linux-wireless&m=125695331205062&w=2, a problem
> with DMA buffer processing was corrected for the libertas driver. Because
> routine usb_fill_bulk_urb() does not check that DMA is possible when
> dma_map_single() is called, this condition was not detected until the buffer
> was unmapped. By this time memory corruption had occurred.
>
> The situation is fixed by testing the returned DMA address. If not a legal
> address, a WARN_ON(1) is executed to provide traceback and the error is
> returned.
>
> Signed-off-by: Larry Finger<Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
> ---
>
> Index: linux-2.6/drivers/usb/core/hcd.c
> ===================================================================
> --- linux-2.6.orig/drivers/usb/core/hcd.c
> +++ linux-2.6/drivers/usb/core/hcd.c
> @@ -1281,6 +1281,13 @@ static int map_urb_for_dma(struct usb_hc
> urb->setup_packet,
> sizeof(struct usb_ctrlrequest),
> DMA_TO_DEVICE);
> + ret = dma_mapping_error(hcd->self.controller,
> + urb->setup_dma);
> + /* warn if DMA mapping failed */
> + if (ret) {
> + WARN_ON(1);
> + return ret;
> + }
First of all you forgot to add { } around everything under if statement.
I don't think WARN_ON is needed...
dma_mapping_error under most architectures return 0 or 1 so it would be
better to make some real error value. EAGAIN seems to be proper error,
since documentation says that driver should try again later.
I would write this error handler like this:
if (dma_mapping_error(hcd->self.controller, urb->setup_dma))
ret = -EAGAIN;
> else if (hcd->driver->flags& HCD_LOCAL_MEM)
> ret = hcd_alloc_coherent(
> urb->dev->bus, mem_flags,
> @@ -1299,6 +1306,13 @@ static int map_urb_for_dma(struct usb_hc
> urb->transfer_buffer,
> urb->transfer_buffer_length,
> dir);
> + ret = dma_mapping_error(hcd->self.controller,
> + urb->transfer_dma);
> + /* warn if DMA mapping failed */
> + if (ret) {
> + WARN_ON(1);
> + return ret;
> + }
ditto
> else if (hcd->driver->flags& HCD_LOCAL_MEM) {
> ret = hcd_alloc_coherent(
> urb->dev->bus, mem_flags,
^ 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