* Re: 2.6.31-rc2: Possible regression in rt61pci driver
From: Chris Clayton @ 2009-07-26 19:15 UTC (permalink / raw)
To: linux-wireless; +Cc: LKML, linville
In-Reply-To: <c6b1100b0907210439jf67d886s3125dafa5f4d3928@mail.gmail.com>
2009/7/21 Chris Clayton <chris2553@googlemail.com>:
> 2009/7/14 Chris Clayton <chris2553@googlemail.com>:
> <snip>
>
>> I've updated to 2.6.31-rc3 this morning and done some more testing.
>> I'm now convinced that the rt61pci driver is somehow involved in
>> locking up the laptop. With the (Belkin) rt61 card inserted, the
>> machine will lock up even if I am doing nothing (no web browsing,
>> email or anything else at all) except running this script in a console
>> window:
>>
>> i=0
>> while true; do
>> let i++
>> echo -n "$i "
>> sleep 1
>> done
>>
>> In the tests I have done so far, the counter has never gone beyond 240
>> before the machine locked. With the (no-name) ath5k card inserted I
>> can use the laptop for normal web browsing, email, etc with no
>> problems - the counter in the script above gets to over 2000.
>>
>
> The freeze still happens with 2.6.31-rc3-git5, but I've been doing
> some more fact-finding.
>
> Running the script shown above and with the rt61-based card inserted,
> I can freeze the laptop even if I am doing nothing else on the laptop.
> When the freeze occurs, the laptop is effectively dead, no response to
> mouse movement or keyboard input and no response to pings from
> another machine on my network. However, if I eject the card, the
> laptop comes to life again. The key presses from when the laptop was
> frozen appear on screen and pings from another machine are responded
> to. The script continues to run and display the counter. I then
> reinsert the card and everything appears OK until the laptop freezes
> again a minute or two later. During a test run this morning the
> machine froze at (from the output of the script) 80, 235, 369, 538 and
> 672. Each time, ejecting the card brought the machine back to life.
>
> Trying the same test with the ath5k-based card inserted resulted in
> the script getting to 2300 without the laptop freezing, at which point
> I stopped the script.
>
One more data point. I wondered whether the freeze would "time out" if
I just left the laptop frozen, but my testing shows that it probably
does not (or if it does it takes more than 27 minutes to do so.
I've also tried to bisect again, but, as last time, once I got to the
batch of network-related changes that went into -rc1, I get a series
of kernels that build but either won't boot or have inoperable
wireless networking.
Finally, since I haven't had a single reply to the regression report I
posted almost two weeks ago, I now give up. I'll switch to using the
card supported by the ath5k driver.
<snip>
Chris
--
No, Sir; there is nothing which has yet been contrived by man, by
which so much happiness is produced as by a good tavern or inn -
Doctor Samuel Johnson
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-07-24
From: John W. Linville @ 2009-07-26 17:52 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev
In-Reply-To: <20090726.100214.125172881.davem@davemloft.net>
On Sun, Jul 26, 2009 at 10:02:14AM -0700, David Miller wrote:
> From: "John W. Linville" <linville@tuxdriver.com>
> Date: Fri, 24 Jul 2009 15:36:25 -0400
>
> > Here is the latest huge round of wireless patches intended for 2.6.32.
> > It hits all the usual areas (i.e. drivers, mac80211, and cfg80211) with
> > patches from all the usual suspects. This includes the reworking of
> > mac80211 to eliminate the confusing "master netdev".
> >
> > FWIW, my laptop has been happy with it. Most of the bits here have been
> > in -next for at least a few days.
> >
> > Please let me know if there are problems!
>
> Pulled, thanks a lot John!
>
> Please try to resolve the regression reports that I saw posted against
> wireless-testing on the same day you sent this pull request.
Certainly! But FWIW I think most of those are about patches that I
have not yet sent to you, so I don't think you need to worry a lot
about your tree ATM.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
¡Viva Honduras Libre!
^ permalink raw reply
* kernel panic ieee80211_agg_splice_packets+0x3d/0xc0 [mac80211]
From: Jack Lau @ 2009-07-26 17:35 UTC (permalink / raw)
To: linux-wireless
[-- Attachment #1: Type: text/plain, Size: 1853 bytes --]
Dear all
This is my very first post on a public mailing list where I am not into programming. I just set up and configure Linux but have very little experience with programing except BASIC and shell scripting.
I have recently assembled a Linux server and router (no GUI) where I am using an Atheros AR9160 controller (Sparklan WMIA-268N) as an access point. I am using Ubuntu 9.04 jaunty release but using hostapd 0.69 from the upcoming 9.10 karmic release because the one that comes with jaunty does not support nl80211.
The problem is that I am constantly getting kernel panics, each time of the same error kernel panic ieee80211_agg_splice_packets+0x3d/0xc0 [mac80211]
I have tried many compat-wireless releases including 2.6.31-rc*, daily builds and many kernels including 2.6.31-* all to no avail, even the latest one doesn't fix the problem. The one which I have took screenshots is from kernel 2.6.28-13 with compat-wireless 2.6.30 installed.
My easiest way to reproduce the problem is to surf the web using my Windows notebook, turn wifi off using the button so that it is suddenly disconnected without de-authenticating, turning wifi back on and then surfing the web and this kernel panic comes just about every time. The notebook is fitted with an Intel 4965AGN in 802.11n mode where I have used both XP and Vista.
I enclose screenshots of 3 occurrences, the last occurrence with the options nosmp noacpi acpi=off noapic just to see if it solves the problem but it didn't. Most frustratingly, I hate it when I am the only person experiencing it because searching Google yields nothing with this error.
Jack
_________________________________________________________________
Celebrate a decade of Messenger with free winks, emoticons, display pics, and more.
http://clk.atdmt.com/UKM/go/157562755/direct/01/
[-- Attachment #2: panic1.jpg --]
[-- Type: image/pjpeg, Size: 175218 bytes --]
[-- Attachment #3: panic2.jpg --]
[-- Type: image/pjpeg, Size: 170778 bytes --]
[-- Attachment #4: panic3.jpg --]
[-- Type: image/pjpeg, Size: 184062 bytes --]
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-07-24
From: David Miller @ 2009-07-26 17:02 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev
In-Reply-To: <20090724193625.GB2711@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Fri, 24 Jul 2009 15:36:25 -0400
> Here is the latest huge round of wireless patches intended for 2.6.32.
> It hits all the usual areas (i.e. drivers, mac80211, and cfg80211) with
> patches from all the usual suspects. This includes the reworking of
> mac80211 to eliminate the confusing "master netdev".
>
> FWIW, my laptop has been happy with it. Most of the bits here have been
> in -next for at least a few days.
>
> Please let me know if there are problems!
Pulled, thanks a lot John!
Please try to resolve the regression reports that I saw posted against
wireless-testing on the same day you sent this pull request.
^ permalink raw reply
* Re: [ipw3945-devel] [BUG] Current head of wireless testing unusable
From: Maxim Levitsky @ 2009-07-26 10:14 UTC (permalink / raw)
To: John Ranson
Cc: Marcel Holtmann, Pavel Roskin, linux-wireless,
iwlwifi maling list
In-Reply-To: <bcd1ba70907252334y2fd88cf0i4fe812f4fd686c8e@mail.gmail.com>
On Sat, 2009-07-25 at 23:34 -0700, John Ranson wrote:
> Hi Maxim and Marcel,
>
> On Sat, Jul 25, 2009 at 10:25 PM, Marcel Holtmann<marcel@holtmann.org> wrote:
> > Hi Maxim,
> >
> >> > > > I probably should work more to did these bugs out myself, but anyway I
> >> > > > want to let you know what I currently see.
> >> > > >
> >> > > > First system oopses just after NM starts up, happens always, and after
> >> > > > planting few test points bug happens somewhere in following lines.
> >> > >
> >> > > We are discussing a bug in the scan state machine in another thread,
> >> > > which could have nasty consequences in not caught. And I don't quite
> >> > > understand why my system was catching it immediately, maybe because I'm
> >> > > using gcc 4.4, which has array bounds checking.
> >> > Yea, there are two patches with same title for this, I applied the
> >> > newer.
> >> >
> >> > Currently thanks to Johannes Berg, the patch
> >> > [PATCH] nl80211: add missing parameter clearing
> >> > Fixes this nasty oops, now wireless more or less works, but plenty of
> >> > problems still, first it oopses on reconnect as inilialized from
> >> > wpa_supplicant, second iwconfig misses most of its settings, and
> >> > probably thus NM think signal level is zero. If I switch to good old
> >> > wext in wpa_supplicant, it works just fine and none of above problems
> >> > present (I recheck this again to be sure)
> >> Except very frequent reconnects,
> >> "[ 919.250097] No probe response from AP 00:1b:9e:d8:77:02 after 200ms, disconnecting."
> >
> > I have the same issue with my Intel 5350 card and if the signal strength
> > of the AP gets a little bit weaker.
> >
>
> I also am seeing this frequently, and I'm sitting about six feet from
> my access point. I don't think that it's necessarily related to signal
> strength.
>
Me too, I was sitting about same six feet from the AP
Best regards,
Maxim Levitsky
> John
^ permalink raw reply
* Re: wireless drivers sparse warnings 07-24
From: Daniel Drake @ 2009-07-26 9:56 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <43e72e890907240922q3d7c9f0agfc8479008f9ba959@mail.gmail.com>
Luis R. Rodriguez wrote:
> CHECK drivers/net/wireless/zd1211rw/zd_usb.c
> drivers/net/wireless/zd1211rw/zd_usb.c:367:24: warning: implicit cast
> from nocast type
>
> I last tried to address this last one with Dan but I forget where we ended up.
I suggested that you avoid using a constant designed for register usage
here because you are not dealing with register addresses (it is just a
coincidence, perhaps intentional, that it is the same value as a related
register address). i.e. change CR_INTERRUPT to 0x9510 or a new constant.
Daniel
^ permalink raw reply
* Re: [PATCH] ath9k: cancel xmit poll work at stop() callback
From: Luis R. Rodriguez @ 2009-07-26 9:48 UTC (permalink / raw)
To: linville, johannes; +Cc: linux-wireless, ath9k-devel, Luis R. Rodriguez
In-Reply-To: <1248482853-17032-4-git-send-email-lrodriguez@atheros.com>
On Fri, Jul 24, 2009 at 5:47 PM, Luis R.
Rodriguez<lrodriguez@atheros.com> wrote:
> We forgot to cancel this work at the stop() callback.
>
<-- snip -->
> diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
> index 3eb3032..fff89cc 100644
> --- a/drivers/net/wireless/ath/ath9k/main.c
> +++ b/drivers/net/wireless/ath/ath9k/main.c
> @@ -2100,6 +2100,8 @@ static void ath9k_stop(struct ieee80211_hw *hw)
>
> mutex_lock(&sc->mutex);
>
> + cancel_delayed_work_sync(&sc->tx_complete_work);
> +
> if (ath9k_wiphy_started(sc)) {
> mutex_unlock(&sc->mutex);
> return; /* another wiphy still in use */
This is in the right place but I see we call it upon detach. That is a
wrong place for this stuff... as well as the other cancels. Due to
virtual stuff this is more involved. We'll have to clean this better.
Luis
^ permalink raw reply
* Re: [PATCH] mac80211: redefine usage of the mac80211 workqueue
From: Luis R. Rodriguez @ 2009-07-26 8:06 UTC (permalink / raw)
To: Johannes Berg, Christian Lamparter
Cc: linville, linux-wireless, ath9k-devel, Reinette Chatre,
Dan Williams, Lennert Buytenhek, Daniel Drake
In-Reply-To: <1248510909.32151.48.camel@johannes.local>
On Sat, Jul 25, 2009 at 1:35 AM, Johannes Berg<johannes@sipsolutions.net> wrote:
> On Fri, 2009-07-24 at 20:47 -0400, Luis R. Rodriguez wrote:
>> The mac80211 workqueue exists to enable mac80211 and drivers
>> to queue their own work on a single threaded workqueue. mac80211
>> takes care to flush the workqueue during suspend but we never
>> really had requirements on drivers for how they should use
>> the workqueue in consideration for suspend.
>>
>> We extend mac80211 to document how the mac80211 workqueue should
>> be used, how it should not be used and finally move raw access to
>> the workqueue to mac80211 only. Drivers and mac80211 use helpers
>> to queue work and flush the mac80211 workqueue:
>>
>> * ieee80211_queue_work()
>> * ieee80211_queue_delayed_work()
>> * ieee80211_flush_workqueue()
>
> I would prefer to have wait_on_work()
That's currently static.
> and/or cancel_work_sync() instead
> of flushing?
That's fine but currently drivers are issuing flush_workqueue() directly.
> It's often preferable due to locking constraints to
> cancel_work_sync() instead of flush_workqueue(). Do people really need
> flush_workqueue()?
Yeah good point, so I see 2 users of flush_workqueue, one in at76 and
another on ar9170.
at76: at76_delete_device()
This is used at usb disconnect and probe failure. cancel_work_sync()
definitely seems more appropriate.
ar9170: ar9170_op_stop()
same here, but seems we could add the flush on mac80211 prior to
calling the drv_stop() currently we call it after.
Luis
^ permalink raw reply
* Re: [ipw3945-devel] [BUG] Current head of wireless testing unusable
From: John Ranson @ 2009-07-26 6:34 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Maxim Levitsky, Pavel Roskin, linux-wireless, iwlwifi maling list
In-Reply-To: <1248585928.28545.166.camel@violet>
Hi Maxim and Marcel,
On Sat, Jul 25, 2009 at 10:25 PM, Marcel Holtmann<marcel@holtmann.org> wrote:
> Hi Maxim,
>
>> > > > I probably should work more to did these bugs out myself, but anyway I
>> > > > want to let you know what I currently see.
>> > > >
>> > > > First system oopses just after NM starts up, happens always, and after
>> > > > planting few test points bug happens somewhere in following lines.
>> > >
>> > > We are discussing a bug in the scan state machine in another thread,
>> > > which could have nasty consequences in not caught. And I don't quite
>> > > understand why my system was catching it immediately, maybe because I'm
>> > > using gcc 4.4, which has array bounds checking.
>> > Yea, there are two patches with same title for this, I applied the
>> > newer.
>> >
>> > Currently thanks to Johannes Berg, the patch
>> > [PATCH] nl80211: add missing parameter clearing
>> > Fixes this nasty oops, now wireless more or less works, but plenty of
>> > problems still, first it oopses on reconnect as inilialized from
>> > wpa_supplicant, second iwconfig misses most of its settings, and
>> > probably thus NM think signal level is zero. If I switch to good old
>> > wext in wpa_supplicant, it works just fine and none of above problems
>> > present (I recheck this again to be sure)
>> Except very frequent reconnects,
>> "[ 919.250097] No probe response from AP 00:1b:9e:d8:77:02 after 200ms, disconnecting."
>
> I have the same issue with my Intel 5350 card and if the signal strength
> of the AP gets a little bit weaker.
>
I also am seeing this frequently, and I'm sitting about six feet from
my access point. I don't think that it's necessarily related to signal
strength.
John
^ permalink raw reply
* Re: new lockdep warning in 2.6.31-rc3-wl
From: Johannes Berg @ 2009-07-26 6:21 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: reinette chatre, linux-wireless
In-Reply-To: <43e72e890907251221rdf7d247yc81d7bc7cb23f255@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1218 bytes --]
On Sat, 2009-07-25 at 12:21 -0700, Luis R. Rodriguez wrote:
> On Sat, Jul 25, 2009 at 2:13 AM, Johannes Berg<johannes@sipsolutions.net> wrote:
> > Obviously 3) is my favourite solution, not only because it's the only
> > one that seems feasible at all, but it's somewhat more complex, and I
> > don't really have time to do that today.
>
> Hm yeah this seems very appealing, it should be noted that this is
> called *very* often too right now because we call this for every
> beacon.
Actually, no, because I added filtering in mac80211 to make it behave
similarly with and without hardware beacon filtering.
> If we want to merge beacon hint and 11d stuff with the added
> advantage to make new functionality available to cfg80211 it would
> seem then to make sense to add some sort of beacon parser so we can
> extend it later if needed.
True.
> But can fullmac cards send full beacon stuff somehow to cfg80211? Can
> they send 11d stuff or would they have to try to build one? Or can
> they realistically only send alpha2 stuff?
They are supposed to send us at least the IEs from the beacon frame,
which we can process similarly. Otherwise, they cannot even support WPA.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [BUG] Current head of wireless testing unusable
From: Marcel Holtmann @ 2009-07-26 5:25 UTC (permalink / raw)
To: Maxim Levitsky; +Cc: Pavel Roskin, linux-wireless, iwlwifi maling list
In-Reply-To: <1248562407.7314.1.camel@maxim-laptop>
Hi Maxim,
> > > > I probably should work more to did these bugs out myself, but anyway I
> > > > want to let you know what I currently see.
> > > >
> > > > First system oopses just after NM starts up, happens always, and after
> > > > planting few test points bug happens somewhere in following lines.
> > >
> > > We are discussing a bug in the scan state machine in another thread,
> > > which could have nasty consequences in not caught. And I don't quite
> > > understand why my system was catching it immediately, maybe because I'm
> > > using gcc 4.4, which has array bounds checking.
> > Yea, there are two patches with same title for this, I applied the
> > newer.
> >
> > Currently thanks to Johannes Berg, the patch
> > [PATCH] nl80211: add missing parameter clearing
> > Fixes this nasty oops, now wireless more or less works, but plenty of
> > problems still, first it oopses on reconnect as inilialized from
> > wpa_supplicant, second iwconfig misses most of its settings, and
> > probably thus NM think signal level is zero. If I switch to good old
> > wext in wpa_supplicant, it works just fine and none of above problems
> > present (I recheck this again to be sure)
> Except very frequent reconnects,
> "[ 919.250097] No probe response from AP 00:1b:9e:d8:77:02 after 200ms, disconnecting."
I have the same issue with my Intel 5350 card and if the signal strength
of the AP gets a little bit weaker.
Regards
Marcel
^ permalink raw reply
* Re: Unable to load iwlagn module: Failed to register hw (error -17)
From: John Ranson @ 2009-07-26 2:41 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Johannes Berg, reinette chatre, linux-wireless@vger.kernel.org
In-Reply-To: <43e72e890907160913i40c8341fo13b75b38b2700055@mail.gmail.com>
Running wireless testing directly fixed this issue.
John
On Thu, Jul 16, 2009 at 9:13 AM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> On Wed, Jul 15, 2009 at 8:58 PM, John Ranson<ranson@analager.net> wrote:
>> The release is master-2009-07-08-3-g3615cdf
>>
>> /sys/class/ieee80211/ is empty
>>
>> I'm running Gentoo on an Lenovo R61. I don't think that there is
>> anything too special about my configuration.
>>
>> Is there any more information that I can provide that will help debug?
>
> You can try wireless-testing directly:
>
> http://wireless.kernel.org/en/developers/Documentation/git-guide
>
> Luis
>
^ permalink raw reply
* Re: [BUG] Current head of wireless testing unusable
From: Maxim Levitsky @ 2009-07-25 22:53 UTC (permalink / raw)
To: Pavel Roskin; +Cc: linux-wireless, iwlwifi maling list
In-Reply-To: <1248561109.4753.9.camel@maxim-laptop>
On Sun, 2009-07-26 at 01:31 +0300, Maxim Levitsky wrote:
> On Sat, 2009-07-25 at 17:52 -0400, Pavel Roskin wrote:
> > On Sat, 2009-07-25 at 17:10 +0300, Maxim Levitsky wrote:
> > > I probably should work more to did these bugs out myself, but anyway I
> > > want to let you know what I currently see.
> > >
> > > First system oopses just after NM starts up, happens always, and after
> > > planting few test points bug happens somewhere in following lines.
> >
> > We are discussing a bug in the scan state machine in another thread,
> > which could have nasty consequences in not caught. And I don't quite
> > understand why my system was catching it immediately, maybe because I'm
> > using gcc 4.4, which has array bounds checking.
> Yea, there are two patches with same title for this, I applied the
> newer.
>
> Currently thanks to Johannes Berg, the patch
> [PATCH] nl80211: add missing parameter clearing
> Fixes this nasty oops, now wireless more or less works, but plenty of
> problems still, first it oopses on reconnect as inilialized from
> wpa_supplicant, second iwconfig misses most of its settings, and
> probably thus NM think signal level is zero. If I switch to good old
> wext in wpa_supplicant, it works just fine and none of above problems
> present (I recheck this again to be sure)
Except very frequent reconnects,
"[ 919.250097] No probe response from AP 00:1b:9e:d8:77:02 after 200ms, disconnecting."
Rest works fine.
Best regards,
Maxim Levitsky
>
> Thanks, I soon run kmemcheck as well.
>
> Best regards,
> Maxim Levitsky
>
> >
> > I have also seen two oopses in the code unrelated to wireless
> > networking, one of which lead to my .bash_history becoming empty.
> >
> > So please be extra careful. It would be great if somebody could test
> > the current kernel extensively with kmemcheck an other options and
> > bisect the bad commit, whether it's wireless related or not.
>
> Thanks!
>
^ permalink raw reply
* Re: [Acpi4asus-user] [PATCH 2.6.31] rfkill: allow toggling soft state in sysfs again
From: John W. Linville @ 2009-07-25 22:35 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Johannes Berg, acpi4asus-user, Darren Salt, debian-eeepc-devel,
linux-wireless, linux-kernel, Thiemo Nagel, Corentin Chary
In-Reply-To: <200907252256.44570.rjw@sisk.pl>
On Sat, Jul 25, 2009 at 10:56:43PM +0200, Rafael J. Wysocki wrote:
> On Friday 10 July 2009, Johannes Berg wrote:
> > On Fri, 2009-07-10 at 22:09 +0100, Darren Salt wrote:
> > > I demand that Johannes Berg may or may not have written...
> > >
> > > > Apparently there actually _are_ tools that try to set this in sysfs even
> > > > though it wasn't supposed to be used this way without claiming first.
> > >
> > > Then it should have been documented as such. I don't see anything about this
> > > in Documentation/rfkill.txt (as found in 2.6.30), other than a vague
> > > statement that "Kernel handles events", which isn't exactly helpful :-\
> >
> > Oh, it's not just that rfkill was horrible, the documentation matched :)
> > All the SHOUTING in it about what you must and must not do but nothing
> > actually helpful :)
> >
> > > > *shrug*, I don't like it, but whatever...
> > >
> > > I do. It means that we have a nice simple text-based interface for use in
> > > scripts (for now), and a binary interface which is better suited to the likes
> > > of desktop applications.
> >
> > Indeed, and as long as you expect to only use soft toggle... problem is
> > that you won't know whether it's soft-toggled or not while it's
> > hard-blocked (off)!
> >
> > > > Please test & report.
> > >
> > > With the patch applied, Bluetooth toggling is working again, so you get to
> > > add this:
> > >
> > > Tested-By: Darren Salt <linux@youmustbejoking.demon.co.uk>
> >
> > Ok, John, please pick up the patch.
>
> Is there anything going on with the patch?
>
> Surely it's not in -rc4.
commit f54c142725ad2ba33c3ee627873cb6966bf05447
Author: Johannes Berg <johannes@sipsolutions.net>
Date: Fri Jul 10 21:41:39 2009 +0200
rfkill: allow toggling soft state in sysfs again
Apparently there actually _are_ tools that try to set
this in sysfs even though it wasn't supposed to be used
this way without claiming first. Guess what: now that
I've cleaned it all up it doesn't matter and we can
simply allow setting the soft-block state in sysfs.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Tested-By: Darren Salt <linux@youmustbejoking.demon.co.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Didn't make -rc4, should be in -rc5.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
¡Viva Honduras Libre!
^ permalink raw reply
* Re: [BUG] Current head of wireless testing unusable
From: Maxim Levitsky @ 2009-07-25 22:31 UTC (permalink / raw)
To: Pavel Roskin; +Cc: linux-wireless, iwlwifi maling list
In-Reply-To: <1248558755.11389.21.camel@mj>
On Sat, 2009-07-25 at 17:52 -0400, Pavel Roskin wrote:
> On Sat, 2009-07-25 at 17:10 +0300, Maxim Levitsky wrote:
> > I probably should work more to did these bugs out myself, but anyway I
> > want to let you know what I currently see.
> >
> > First system oopses just after NM starts up, happens always, and after
> > planting few test points bug happens somewhere in following lines.
>
> We are discussing a bug in the scan state machine in another thread,
> which could have nasty consequences in not caught. And I don't quite
> understand why my system was catching it immediately, maybe because I'm
> using gcc 4.4, which has array bounds checking.
Yea, there are two patches with same title for this, I applied the
newer.
Currently thanks to Johannes Berg, the patch
[PATCH] nl80211: add missing parameter clearing
Fixes this nasty oops, now wireless more or less works, but plenty of
problems still, first it oopses on reconnect as inilialized from
wpa_supplicant, second iwconfig misses most of its settings, and
probably thus NM think signal level is zero. If I switch to good old
wext in wpa_supplicant, it works just fine and none of above problems
present (I recheck this again to be sure)
Thanks, I soon run kmemcheck as well.
Best regards,
Maxim Levitsky
>
> I have also seen two oopses in the code unrelated to wireless
> networking, one of which lead to my .bash_history becoming empty.
>
> So please be extra careful. It would be great if somebody could test
> the current kernel extensively with kmemcheck an other options and
> bisect the bad commit, whether it's wireless related or not.
Thanks!
^ permalink raw reply
* Re: [BUG] Current head of wireless testing unusable
From: Pavel Roskin @ 2009-07-25 21:52 UTC (permalink / raw)
To: Maxim Levitsky; +Cc: linux-wireless, iwlwifi maling list
In-Reply-To: <1248531054.15242.16.camel@maxim-laptop>
On Sat, 2009-07-25 at 17:10 +0300, Maxim Levitsky wrote:
> I probably should work more to did these bugs out myself, but anyway I
> want to let you know what I currently see.
>
> First system oopses just after NM starts up, happens always, and after
> planting few test points bug happens somewhere in following lines.
We are discussing a bug in the scan state machine in another thread,
which could have nasty consequences in not caught. And I don't quite
understand why my system was catching it immediately, maybe because I'm
using gcc 4.4, which has array bounds checking.
I have also seen two oopses in the code unrelated to wireless
networking, one of which lead to my .bash_history becoming empty.
So please be extra careful. It would be great if somebody could test
the current kernel extensively with kmemcheck an other options and
bisect the bad commit, whether it's wireless related or not.
--
Regards,
Pavel Roskin
^ permalink raw reply
* [PATCH] ipw2x00: Write outside array bounds
From: Roel Kluin @ 2009-07-25 21:48 UTC (permalink / raw)
To: yi.zhu, linux-wireless, ipw2100-devel, Andrew Morton
channel_index loops up to IPW_SCAN_CHANNELS, but is used after being
incremented. This might be able to access 1 past the end of the array
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
diff --git a/drivers/net/wireless/ipw2x00/ipw2200.c b/drivers/net/wireless/ipw2x00/ipw2200.c
index 44c29b3..d1c9d6d 100644
--- a/drivers/net/wireless/ipw2x00/ipw2200.c
+++ b/drivers/net/wireless/ipw2x00/ipw2200.c
@@ -6249,7 +6249,10 @@ static void ipw_add_scan_channels(struct ipw_priv *priv,
channels[channel - 1] = 1;
priv->speed_scan_pos++;
- channel_index++;
+
+ if (++channel_index >= IPW_SCAN_CHANNELS)
+ break;
+
scan->channels_list[channel_index] = channel;
index =
ieee80211_channel_to_index(priv->ieee, channel);
^ permalink raw reply related
* Re: [PATCH] mac80211: fix oops in ieee80211_scan_state_set_channel()
From: Pavel Roskin @ 2009-07-25 21:44 UTC (permalink / raw)
To: Helmut Schaa; +Cc: Johannes Berg, linux-wireless, John Linville, Larry Finger
In-Reply-To: <200907252015.07010.helmut.schaa@googlemail.com>
On Sat, 2009-07-25 at 20:15 +0200, Helmut Schaa wrote:
> > Lack of SCAN_DONE in mac80211_scan_state. We exit scanning through the
> > "entry point".
>
> I also thought of a separate state SCAN_DONE or something similar but
> dropped that idea as the only thing this state would have to do is the
> call to ieee80211_scan_completed. So, once the scan is finished we
> just stay in SCAN_DECISION as long as the scan state machine gets poked
> again by a start_scan call.
It's just an idea. I only touched that code because it was failing for
me.
There is some duplication of information between local->scanning and
local->next_scan_state, but it's probably hard to avoid.
> > Use of "unsigned long" for bitwise fields, such as queue_stop_reasons
> > and scanning. This reminds me of the good old days where long was
> > always 32 bit, but int wasn't. I think "unsigned int" should be enough,
> > and you can annotate it with __bitwise to make sparse catch some
> > misuses.
>
> No objections :)
Sorry, it turns out test_bit() wants unsigned long. I don't quite like
what it does, but I'm not going to rewrite it.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] mac80211: fix receiving deauth
From: Maxim Levitsky @ 2009-07-25 21:42 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, Marcel Holtmann, linux-wireless
In-Reply-To: <1248515916.19945.1.camel@johannes.local>
On Sat, 2009-07-25 at 11:58 +0200, Johannes Berg wrote:
> Marcel reported a warning, which quite obviously comes
> from an oversight in the code handling deauth frames,
> and which resulted in multiple follow-up warnings due
> to this missing handling. This patch adds the missing
> deauth handling (telling cfg80211 about it) and also
> removes the follow-up warnings since they could happen
> due to races even if nothing is wrong. I've explained
> the races in the comments.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
> Reported-by: Marcel Holtmann <marcel@holtmann.org>
> ---
> net/mac80211/mlme.c | 21 +++++++++++++++++----
> 1 file changed, 17 insertions(+), 4 deletions(-)
>
> --- wireless-testing.orig/net/mac80211/mlme.c 2009-07-25 11:03:12.000000000 +0200
> +++ wireless-testing/net/mac80211/mlme.c 2009-07-25 11:55:35.000000000 +0200
> @@ -2003,6 +2003,9 @@ static void ieee80211_sta_rx_queued_mgmt
> case RX_MGMT_CFG80211_ASSOC:
> cfg80211_send_rx_assoc(sdata->dev, (u8 *) mgmt, skb->len);
> break;
> + case RX_MGMT_CFG80211_DEAUTH:
> + cfg80211_send_deauth(sdata->dev, (u8 *)mgmt, skb->len, NULL);
> + break;
> default:
> WARN(1, "unexpected: %d", rma);
> }
> @@ -2498,8 +2501,13 @@ int ieee80211_mgd_deauth(struct ieee8021
> }
> }
>
> - /* cfg80211 should catch this... */
> - if (WARN_ON(!bssid)) {
> + /*
> + * cfg80211 should catch this ... but it's racy since
> + * we can receive a deauth frame, process it, hand it
> + * to cfg80211 while that's in a locked section already
> + * trying to tell us that the user wants to disconnect.
> + */
> + if (!bssid) {
> mutex_unlock(&ifmgd->mtx);
> return -ENOLINK;
> }
> @@ -2524,8 +2532,13 @@ int ieee80211_mgd_disassoc(struct ieee80
>
> mutex_lock(&ifmgd->mtx);
>
> - /* cfg80211 should catch that */
> - if (WARN_ON(&ifmgd->associated->cbss != req->bss)) {
> + /*
> + * cfg80211 should catch this ... but it's racy since
> + * we can receive a disassoc frame, process it, hand it
> + * to cfg80211 while that's in a locked section already
> + * trying to tell us that the user wants to disconnect.
> + */
> + if (&ifmgd->associated->cbss != req->bss) {
> mutex_unlock(&ifmgd->mtx);
> return -ENOLINK;
> }
Don't know if related, but I see this on latest wireless testing with 2
patches applied:
[PATCH]_nl80211:_add_missing_parameter_clearing
[PATCH]_mac80211:_fix_an_oops_in_ieee80211_scan_state_set_channel
<1>[ 315.219232] BUG: unable to handle kernel NULL pointer dereference a 0000000000000048
<1>[ 315.219242] IP: [<ffffffffa0a467c8>] cfg80211_mlme_disassoc+0x98/0x110 [cfg80211]
<4>[ 315.219271] PGD 7061b067 PUD 7e9c0067 PMD 0
<0>[ 315.219280] Oops: 0000 [#1] PREEMPT SMP
<0>[ 315.219287] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
<4>[ 315.219293] CPU 0
<4>[ 315.219297] Modules linked in: af_packet sco bridge stp llc bnep l2cap bluetooth nfsd exportfs nfs lockd nfs_acl auth_rpcgss sunrpc usb_storage usb_libusual cpufreq_powersave cpufreq_conservative cpufreq_userspace acpi_cpufreq coretemp joydev sbp2 snd_hda_codec_realtek iwl3945 iwlcore snd_hda_intel snd_hda_codec uvcvideo mac80211 videodev snd_hwdep psmouse v4l1_compat v4l2_compat_ioctl32 snd_pcm acer_wmi backlight cfg80211 serio_raw snd_timer tg3 iTCO_wdt uhci_hcd rfkill nvidia(P) ohci1394 snd_page_alloc ehci_hcd sdhci_pci sdhci libphy iTCO_vendor_support usbcore wmi evdev fuse
<6>[ 315.219383] Pid: 4078, comm: wpa_supplicant Tainted: P 2.6.31-rc4-wl #32 Aspire 5720
<6>[ 315.219388] RIP: 0010:[<ffffffffa0a467c8>] [<ffffffffa0a467c8>] cfg80211_mlme_disassoc+0x98/0x110 [cfg80211]
<6>[ 315.219411] RSP: 0018:ffff880070611988 EFLAGS: 00010296
<6>[ 315.219415] RAX: 0000000000000000 RBX: 00000000ffffff95 RCX: 0000000000000006
<6>[ 315.219420] RDX: ffff880067e61828 RSI: 0000000000000048 RDI: ffff880067e61828
<6>[ 315.219425] RBP: ffff8800706119f8 R08: ffff8800706119a8 R09: 0000000000000000
<6>[ 315.219430] R10: ffff88007f8df000 R11: 0000000000000000 R12: ffff88007f8df590
<6>[ 315.219435] R13: ffff88007f8df000 R14: 0000000000000000 R15: 0000000000000000
<6>[ 315.219441] FS: 00007fd2a264f6f0(0000) GS:ffff8800016a3000(0000) knlGS:0000000000000000
<6>[ 315.219446] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<6>[ 315.219450] CR2: 0000000000000048 CR3: 00000000704e1000 CR4: 00000000000006f0
<6>[ 315.219455] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
<6>[ 315.219460] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
<4>[ 315.219465] Process wpa_supplicant (pid: 4078, threadinfo ffff880070610000, task ffff88007056c230)
<0>[ 315.219469] Stack:
<4>[ 315.219472] ffff8800706119a8 ffff880067e61828 ffff88007f330000 ffff88007f8df5b8
<4>[ 315.219480] <0> 0000000000000000 0000000000000000 0000000000000000 0000000000000003
<4>[ 315.219489] <0> ffff8800706119f8 00000000ffffffea ffff880070611a58 ffff880067e61800
<0>[ 315.219499] Call Trace:
<4>[ 315.219522] [<ffffffffa0a3f287>] nl80211_disassociate+0x127/0x140 [cfg80211]
<4>[ 315.219533] [<ffffffff81340b06>] genl_rcv_msg+0x1b6/0x1f0
<4>[ 315.219541] [<ffffffff81340950>] ? genl_rcv_msg+0x0/0x1f0
<4>[ 315.219547] [<ffffffff813408e9>] netlink_rcv_skb+0x89/0xb0
<4>[ 315.219553] [<ffffffff81340937>] genl_rcv+0x27/0x40
<4>[ 315.219559] [<ffffffff81340449>] ? netlink_sendmsg+0x159/0x300
<4>[ 315.219566] [<ffffffff813402da>] netlink_unicast+0x2da/0x2f0
<4>[ 315.219574] [<ffffffff8131fefe>] ? __alloc_skb+0x6e/0x170
<4>[ 315.219581] [<ffffffff813404ee>] netlink_sendmsg+0x1fe/0x300
<4>[ 315.219591] [<ffffffff810ac158>] ? generic_file_buffered_write+0x128/0x340
<4>[ 315.219600] [<ffffffff81316ed7>] sock_sendmsg+0x127/0x140
<4>[ 315.219608] [<ffffffff81063ee0>] ? autoremove_wake_function+0x0/0x40
<4>[ 315.219616] [<ffffffff810ad382>] ? generic_file_aio_write+0x72/0xd0
<4>[ 315.219623] [<ffffffff81315b1b>] ? move_addr_to_kernel+0x2b/0x40
<4>[ 315.219629] [<ffffffff8132151c>] ? verify_iovec+0x3c/0xd0
<4>[ 315.219636] [<ffffffff81317079>] sys_sendmsg+0x189/0x320
<4>[ 315.219643] [<ffffffff81063ee0>] ? autoremove_wake_function+0x0/0x40
<4>[ 315.219651] [<ffffffff810c4d28>] ? handle_mm_fault+0x1d8/0x830
<4>[ 315.219660] [<ffffffff810e194f>] ? vfs_write+0x13f/0x1a0
<4>[ 315.219669] [<ffffffff8100beeb>] system_call_fastpath+0x16/0x1b
<0>[ 315.219673] Code: 5d c8 4c 89 75 b8 49 63 c7 b9 06 00 00 00 48 89 45 c0 48 8b 7d 98 4d 8b 8c 24 d8 00 00 00 4c 8d 45 b0 49 8d 71 48 bb 95 ff ff ff <f3> a6 0f 97 c2 0f 92 c0 38 c2 75 2a 48 8b 55 a0 49 8d 41 40 48
<1>[ 315.219743] RIP [<ffffffffa0a467c8>] cfg80211_mlme_disassoc+0x98/0x110 [cfg80211]
<4>[ 315.219764] RSP <ffff880070611988>
<0>[ 315.219767] CR2: 0000000000000048
<4>[ 315.219772] ---[ end trace f7733b1bb80b3185 ]---
NM associates, but then if I manually ask it to associate again, this happens. I use nl80211 in wpa_supplicant
Best regards,
Maxim Levitsky
^ permalink raw reply
* [PATCH] iwlwifi: Read outside array bounds
From: Roel Kluin @ 2009-07-25 21:34 UTC (permalink / raw)
To: yi.zhu, linux-wireless, ipw3945-devel, Andrew Morton
tid is bounded (above) by the size of default_tid_to_tx_fifo (17 elements), but
the size of priv->stations[].tid[] is MAX_TID_COUNT (9) elements.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
diff --git a/drivers/net/wireless/iwlwifi/iwl-tx.c b/drivers/net/wireless/iwlwifi/iwl-tx.c
index 85ae7a6..e9441c6 100644
--- a/drivers/net/wireless/iwlwifi/iwl-tx.c
+++ b/drivers/net/wireless/iwlwifi/iwl-tx.c
@@ -1170,6 +1170,8 @@ int iwl_tx_agg_start(struct iwl_priv *priv, const u8 *ra, u16 tid, u16 *ssn)
IWL_ERR(priv, "Start AGG on invalid station
");
return -ENXIO;
}
+ if (unlikely(tid >= MAX_TID_COUNT))
+ return -EINVAL;
if (priv->stations[sta_id].tid[tid].agg.state != IWL_AGG_OFF) {
IWL_ERR(priv, "Start AGG when state is not IWL_AGG_OFF !
");
^ permalink raw reply related
* [PATCH] ath9k: Read outside array bounds
From: Roel Kluin @ 2009-07-25 21:21 UTC (permalink / raw)
To: lrodriguez, linux-wireless, ath9k-devel, Andrew Morton
Incorrect limits leads to reads outside array bounds.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
diff --git a/drivers/net/wireless/ath/ath9k/eeprom.c b/drivers/net/wireless/ath/ath9k/eeprom.c
index a2fda70..ce0e86c 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom.c
@@ -460,7 +460,7 @@ static int ath9k_hw_4k_check_eeprom(struct ath_hw *ah)
integer = swab32(eep->modalHeader.antCtrlCommon);
eep->modalHeader.antCtrlCommon = integer;
- for (i = 0; i < AR5416_MAX_CHAINS; i++) {
+ for (i = 0; i < AR5416_EEP4K_MAX_CHAINS; i++) {
integer = swab32(eep->modalHeader.antCtrlChain[i]);
eep->modalHeader.antCtrlChain[i] = integer;
}
@@ -914,7 +914,7 @@ static void ath9k_hw_set_4k_power_per_rate_table(struct ath_hw *ah,
ctlMode, numCtlModes, isHt40CtlMode,
(pCtlMode[ctlMode] & EXT_ADDITIVE));
- for (i = 0; (i < AR5416_NUM_CTLS) &&
+ for (i = 0; (i < AR5416_EEP4K_NUM_CTLS) &&
pEepData->ctlIndex[i]; i++) {
DPRINTF(ah->ah_sc, ATH_DBG_EEPROM,
" LOOP-Ctlidx %d: cfgCtl 0x%2.2x "
^ permalink raw reply related
* [PATCH] airo: Buffer overflow
From: Roel Kluin @ 2009-07-25 21:02 UTC (permalink / raw)
To: linville, linux-wireless, Andrew Morton
SSID_rid has space for only 3 ssids.
txPowerLevels[i] is read before the bounds check for i
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
diff --git a/drivers/net/wireless/airo.c b/drivers/net/wireless/airo.c
index c70604f..8ce5e4c 100644
--- a/drivers/net/wireless/airo.c
+++ b/drivers/net/wireless/airo.c
@@ -5918,20 +5918,19 @@ static int airo_set_essid(struct net_device *dev,
readSsidRid(local, &SSID_rid);
/* Check if we asked for `any' */
- if(dwrq->flags == 0) {
+ if (dwrq->flags == 0) {
/* Just send an empty SSID list */
memset(&SSID_rid, 0, sizeof(SSID_rid));
} else {
- int index = (dwrq->flags & IW_ENCODE_INDEX) - 1;
+ unsigned index = (dwrq->flags & IW_ENCODE_INDEX) - 1;
/* Check the size of the string */
- if(dwrq->length > IW_ESSID_MAX_SIZE) {
+ if (dwrq->length > IW_ESSID_MAX_SIZE)
return -E2BIG ;
- }
+
/* Check if index is valid */
- if((index < 0) || (index >= 4)) {
+ if (index >= ARRAY_SIZE(SSID_rid.ssids))
return -EINVAL;
- }
/* Set the SSID */
memset(SSID_rid.ssids[index].ssid, 0,
@@ -6819,7 +6818,7 @@ static int airo_set_txpow(struct net_device *dev,
return -EINVAL;
}
clear_bit (FLAG_RADIO_OFF, &local->flags);
- for (i = 0; cap_rid.txPowerLevels[i] && (i < 8); i++)
+ for (i = 0; i < 8 && cap_rid.txPowerLevels[i]; i++)
if (v == cap_rid.txPowerLevels[i]) {
readConfigRid(local, 1);
local->config.txPower = v;
^ permalink raw reply related
* Re: [Acpi4asus-user] [PATCH 2.6.31] rfkill: allow toggling soft state in sysfs again
From: Rafael J. Wysocki @ 2009-07-25 20:56 UTC (permalink / raw)
To: Johannes Berg, John Linville
Cc: acpi4asus-user, Darren Salt, debian-eeepc-devel, linux-wireless,
linux-kernel, Thiemo Nagel, Corentin Chary
In-Reply-To: <1247262952.26071.1.camel@johannes.local>
On Friday 10 July 2009, Johannes Berg wrote:
> On Fri, 2009-07-10 at 22:09 +0100, Darren Salt wrote:
> > I demand that Johannes Berg may or may not have written...
> >
> > > Apparently there actually _are_ tools that try to set this in sysfs even
> > > though it wasn't supposed to be used this way without claiming first.
> >
> > Then it should have been documented as such. I don't see anything about this
> > in Documentation/rfkill.txt (as found in 2.6.30), other than a vague
> > statement that "Kernel handles events", which isn't exactly helpful :-\
>
> Oh, it's not just that rfkill was horrible, the documentation matched :)
> All the SHOUTING in it about what you must and must not do but nothing
> actually helpful :)
>
> > > *shrug*, I don't like it, but whatever...
> >
> > I do. It means that we have a nice simple text-based interface for use in
> > scripts (for now), and a binary interface which is better suited to the likes
> > of desktop applications.
>
> Indeed, and as long as you expect to only use soft toggle... problem is
> that you won't know whether it's soft-toggled or not while it's
> hard-blocked (off)!
>
> > > Please test & report.
> >
> > With the patch applied, Bluetooth toggling is working again, so you get to
> > add this:
> >
> > Tested-By: Darren Salt <linux@youmustbejoking.demon.co.uk>
>
> Ok, John, please pick up the patch.
Is there anything going on with the patch?
Surely it's not in -rc4.
Rafael
^ permalink raw reply
* Re: new lockdep warning in 2.6.31-rc3-wl
From: Luis R. Rodriguez @ 2009-07-25 19:21 UTC (permalink / raw)
To: Johannes Berg; +Cc: reinette chatre, linux-wireless
In-Reply-To: <1248513231.32151.60.camel@johannes.local>
On Sat, Jul 25, 2009 at 2:13 AM, Johannes Berg<johannes@sipsolutions.net> wrote:
> Obviously 3) is my favourite solution, not only because it's the only
> one that seems feasible at all, but it's somewhat more complex, and I
> don't really have time to do that today.
Hm yeah this seems very appealing, it should be noted that this is
called *very* often too right now because we call this for every
beacon. If we want to merge beacon hint and 11d stuff with the added
advantage to make new functionality available to cfg80211 it would
seem then to make sense to add some sort of beacon parser so we can
extend it later if needed.
But can fullmac cards send full beacon stuff somehow to cfg80211? Can
they send 11d stuff or would they have to try to build one? Or can
they realistically only send alpha2 stuff?
Luis
^ permalink raw reply
* Re: [PATCH] mac80211: fix oops in ieee80211_scan_state_set_channel()
From: Helmut Schaa @ 2009-07-25 18:34 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Johannes Berg, linux-wireless, John Linville, Larry Finger
In-Reply-To: <200907252015.07010.helmut.schaa@googlemail.com>
Am Samstag, 25. Juli 2009 schrieb Helmut Schaa:
> Am Samstag, 25. Juli 2009 schrieb Pavel Roskin:
> > Lack of SCAN_DONE in mac80211_scan_state. We exit scanning through the
> > "entry point".
>
> I also thought of a separate state SCAN_DONE or something similar but
> dropped that idea as the only thing this state would have to do is the
> call to ieee80211_scan_completed. So, once the scan is finished we
> just stay in SCAN_DECISION as long as the scan state machine gets poked
> again by a start_scan call.
Maybe we should add a state SCAN_IDLE which is entered after the scan
finished just for consistency?
Helmut
^ 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