* Test message, please ignore.
From: Gábor Stefanik @ 2009-08-31 21:01 UTC (permalink / raw)
To: linux-wireless, Broadcom Wireless, linux-kernel
I suspect that this will trigger a response from a spambot.
reset
^ permalink raw reply
* Re: hal, rfkill and compat-wireless (Re: [RFC/RFT] rtl8187: Implement rfkill support)
From: Marcel Holtmann @ 2009-08-31 20:40 UTC (permalink / raw)
To: Inaky Perez-Gonzalez; +Cc: Luis R. Rodriguez, Hin-Tak Leung, linux-wireless
In-Reply-To: <1251749600.5165.1.camel@localhost.localdomain>
Hi Luis,
> > OK not so bad except for:
> >
> > > kernel/net/wimax/wimax.ko
> >
> > That's touching another subsystem but we could technically merge wimax
> > into compat-wireless if Inaky thinks that's a good idea. the point
> > here is to unify anything that uses rfkill for backport usage.
>
> Oh boy, can of worms
>
> I have my own compat-wimax already, which already handles things for
> backwards compat (many #ifdef hacks to simplify life) and which is
> heavily used internally.
>
> I don't really know how much worth it might be and I know I don't have
> resources to support both.
for the wireless-compat tree, I would just remove the RFKILL support for
WiMAX. It is really not worth to support it.
Regards
Marcel
^ permalink raw reply
* Re: hal, rfkill and compat-wireless (Re: [RFC/RFT] rtl8187: Implement rfkill support)
From: Inaky Perez-Gonzalez @ 2009-08-31 20:13 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Hin-Tak Leung, linux-wireless
In-Reply-To: <43e72e890908311225r3b0d80bcqcb3e3e11d81a255e@mail.gmail.com>
On Mon, 2009-08-31 at 13:25 -0600, Luis R. Rodriguez wrote:
> OK not so bad except for:
>
> > kernel/net/wimax/wimax.ko
>
> That's touching another subsystem but we could technically merge wimax
> into compat-wireless if Inaky thinks that's a good idea. the point
> here is to unify anything that uses rfkill for backport usage.
Oh boy, can of worms
I have my own compat-wimax already, which already handles things for
backwards compat (many #ifdef hacks to simplify life) and which is
heavily used internally.
I don't really know how much worth it might be and I know I don't have
resources to support both.
> > If everything that depends on rkill is bundled with
> > compat-wireless, there is probablt no need for the symbol and sysfs
> > renaming hacks.
>
> Right which is why I think this may be reasonable to do. Any thoughts Inaky?
> Luis
--
-- Inaky
^ permalink raw reply
* Re: memleaks, acpi + ext4 + tty
From: Luis R. Rodriguez @ 2009-08-31 20:02 UTC (permalink / raw)
To: John W. Linville
Cc: Catalin Marinas, H. Peter Anvin, linux-kernel, Aneesh Kumar K.V,
Greg Kroah-Hartman, linux-wireless
In-Reply-To: <20090831194753.GH5631@tuxdriver.com>
On Mon, Aug 31, 2009 at 12:47 PM, John W.
Linville<linville@tuxdriver.com> wrote:
> On Mon, Aug 31, 2009 at 12:43:01PM -0700, Luis R. Rodriguez wrote:
>> On Mon, Aug 31, 2009 at 12:33 PM, John W.
>> Linville<linville@tuxdriver.com> wrote:
>
>> > My guess is that the culprit is between
>> > v2.6.31-rc8 and whatever is at the head of linux-2.6-allstable.
>>
>> But the issue is *not* in linux-2.6-allstable, it is only present on
>> wireless-testing, and I went as far back as merge-2009-08-28. I was
>> using whatever tag was available prior to you moving to rc8, and that
>> worked.
>
> OK, then I can only guess that something went wrong in your bisection
> (e.g. dirty build, something not marked properly, etc).
Well so remember I did a clean git clone of wireless-testing and the
issue was still there, but I determined just now it seems rc8 from
Linus does indeed also have the issue. For some reason the issue was
not present on hpa's rc8 on linux-2.6-allstable. Will double check on
that again.
> That, or
> different .config files between your linux-2.6-allstable build and
> the merge-2009-08-28 build of wireless-testing?
I ensured to diff configs them between builds :T
Luis
^ permalink raw reply
* Re: memleaks, acpi + ext4 + tty
From: John W. Linville @ 2009-08-31 19:47 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Catalin Marinas, H. Peter Anvin, linux-kernel, Aneesh Kumar K.V,
Greg Kroah-Hartman, linux-wireless
In-Reply-To: <43e72e890908311243u50b9323fveda9feaaa4d8efdb@mail.gmail.com>
On Mon, Aug 31, 2009 at 12:43:01PM -0700, Luis R. Rodriguez wrote:
> On Mon, Aug 31, 2009 at 12:33 PM, John W.
> Linville<linville@tuxdriver.com> wrote:
> > My guess is that the culprit is between
> > v2.6.31-rc8 and whatever is at the head of linux-2.6-allstable.
>
> But the issue is *not* in linux-2.6-allstable, it is only present on
> wireless-testing, and I went as far back as merge-2009-08-28. I was
> using whatever tag was available prior to you moving to rc8, and that
> worked.
OK, then I can only guess that something went wrong in your bisection
(e.g. dirty build, something not marked properly, etc). That, or
different .config files between your linux-2.6-allstable build and
the merge-2009-08-28 build of wireless-testing?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: memleaks, acpi + ext4 + tty
From: Luis R. Rodriguez @ 2009-08-31 19:58 UTC (permalink / raw)
To: John W. Linville
Cc: Catalin Marinas, H. Peter Anvin, linux-kernel, Aneesh Kumar K.V,
Greg Kroah-Hartman, linux-wireless
In-Reply-To: <43e72e890908311243u50b9323fveda9feaaa4d8efdb@mail.gmail.com>
On Mon, Aug 31, 2009 at 12:43 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> On Mon, Aug 31, 2009 at 12:33 PM, John W.
> Linville<linville@tuxdriver.com> wrote:
>> On Mon, Aug 31, 2009 at 12:30:15PM -0700, Luis R. Rodriguez wrote:
>>> On Mon, Aug 31, 2009 at 11:37 AM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
>>
>>> > OK I tried this, I even 'rm -rf * ; git checkout -f' and ..
>>> > merge-2009-08-28 tag yields the same issues, long lag upon bootup with
>>> > some kmemleaks I cannot even get to check. So somehow something is
>>> > different between merge-2009-08-28 and Linus' rc8. This is just
>>> > bizarre so to be even safer I'm just going to do a fresh git clone on
>>> > wireless-testing.
>>>
>>> Hey John so I tested wireless-testing on the merge-2009-08-28 tag on a
>>> fresh git pull and verified this is indeed busted for me. Although I
>>> had tried hpa's linux-2.6-allstable on HEAD just to be sure I am now
>>> building Linus' tree from a fresh git clone on the v2.6.31-rc8 tag
>>> just to be double check this was indeed not a 2.6.31-rc8 issue but
>>> instead *something* on wireless-testing. What that something is is
>>> unclear to me still, I guess after all these tests I'll run a manual
>>> diff as git doesn't seem to be picking anything up.
>>
>> As you determined, there is no difference between merge-2009-08-28
>> and v2.6.31-rc8. If one works and the other doesn't, then the main
>> thing not working will be git...
>
> Hm that would suck big time. At any rate, even if it was git
> wireless-testing seems to have an issue right now. I'll confirm
> shortly with Linus' own tree.
>
>> What is linux-2.6-allstable?
>
> hpa's collection of 2.6 stable kernels, including extraversion stuff.
>
>> My guess is that the culprit is between
>> v2.6.31-rc8 and whatever is at the head of linux-2.6-allstable.
>
> But the issue is *not* in linux-2.6-allstable, it is only present on
> wireless-testing, and I went as far back as merge-2009-08-28. I was
> using whatever tag was available prior to you moving to rc8, and that
> worked.
Good news is Linus' rc8 tag *has the same issue* so the reason why
wireless-testing has it is rc8 *does indeed have it*.
So Peter, if there is something extra or missing from
linux-2.6-allstable head it certainly fixed my issues, will have to
try a new respin of it to ensure it wasn't a fluke. Odd thing too
though is even my distribution kernel (karmic rc8 generic) works fine.
At least now I can safely bisect between rc7 and rc8, or pull the
kmemleaks branch and see if that fixed.
Luis
^ permalink raw reply
* Re: memleaks, acpi + ext4 + tty
From: Luis R. Rodriguez @ 2009-08-31 19:43 UTC (permalink / raw)
To: John W. Linville
Cc: Catalin Marinas, H. Peter Anvin, linux-kernel, Aneesh Kumar K.V,
Greg Kroah-Hartman, linux-wireless
In-Reply-To: <20090831193345.GG5631@tuxdriver.com>
On Mon, Aug 31, 2009 at 12:33 PM, John W.
Linville<linville@tuxdriver.com> wrote:
> On Mon, Aug 31, 2009 at 12:30:15PM -0700, Luis R. Rodriguez wrote:
>> On Mon, Aug 31, 2009 at 11:37 AM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
>
>> > OK I tried this, I even 'rm -rf * ; git checkout -f' and ..
>> > merge-2009-08-28 tag yields the same issues, long lag upon bootup with
>> > some kmemleaks I cannot even get to check. So somehow something is
>> > different between merge-2009-08-28 and Linus' rc8. This is just
>> > bizarre so to be even safer I'm just going to do a fresh git clone on
>> > wireless-testing.
>>
>> Hey John so I tested wireless-testing on the merge-2009-08-28 tag on a
>> fresh git pull and verified this is indeed busted for me. Although I
>> had tried hpa's linux-2.6-allstable on HEAD just to be sure I am now
>> building Linus' tree from a fresh git clone on the v2.6.31-rc8 tag
>> just to be double check this was indeed not a 2.6.31-rc8 issue but
>> instead *something* on wireless-testing. What that something is is
>> unclear to me still, I guess after all these tests I'll run a manual
>> diff as git doesn't seem to be picking anything up.
>
> As you determined, there is no difference between merge-2009-08-28
> and v2.6.31-rc8. If one works and the other doesn't, then the main
> thing not working will be git...
Hm that would suck big time. At any rate, even if it was git
wireless-testing seems to have an issue right now. I'll confirm
shortly with Linus' own tree.
> What is linux-2.6-allstable?
hpa's collection of 2.6 stable kernels, including extraversion stuff.
> My guess is that the culprit is between
> v2.6.31-rc8 and whatever is at the head of linux-2.6-allstable.
But the issue is *not* in linux-2.6-allstable, it is only present on
wireless-testing, and I went as far back as merge-2009-08-28. I was
using whatever tag was available prior to you moving to rc8, and that
worked.
Luis
^ permalink raw reply
* Re: [PATCH v2] b43: LP-PHY: Begin implementing calibration & software RFKILL support
From: Gábor Stefanik @ 2009-08-31 19:38 UTC (permalink / raw)
To: Michael Buesch
Cc: John W. Linville, Larry Finger, Mark Huijgen, Broadcom Wireless,
linux-wireless
In-Reply-To: <200908312117.26915.mb@bu3sch.de>
On Mon, Aug 31, 2009 at 9:17 PM, Michael Buesch<mb@bu3sch.de> wrote:
> On Monday 31 August 2009 19:53:31 John W. Linville wrote:
>> On Sun, Aug 30, 2009 at 05:55:40PM +0200, Michael Buesch wrote:
>> > On Sunday 30 August 2009 17:10:23 Larry Finger wrote:
>> > > Michael Buesch wrote:
>> > > > On Sunday 30 August 2009 02:15:55 Gábor Stefanik wrote:
>> > > >> static void lpphy_pr41573_workaround(struct b43_wldev *dev)
>> > > >> {
>> > > >> struct b43_phy_lp *lpphy = dev->phy.lp;
>> > > >> @@ -1357,28 +1488,440 @@ static void lpphy_pr41573_workaround(struct b43_wldev *dev)
>> > > >> b43_lptab_read_bulk(dev, B43_LPTAB32(7, 0x140),
>> > > >> saved_tab_size, saved_tab);
>> > > >> }
>> > > >> + b43_put_phy_into_reset(dev);
>> > > >
>> > > > Are you sure you really want this?
>> > > > This function completely disables the PHY on the backplane and keeps the physical
>> > > > PHY reset pin asserted (even after return from the function).
>> > > > So the PHY will physically be powered down from this point on. The following
>> > > > PHY accesses could even hang the machine, because the PHY won't respond to
>> > > > register accesses anymore.
>> > > >
>> > > > We currently only use this function on A/G Multi-PHY devices to permanently
>> > > > hard-disable the PHY that's not used.
>> > >
>> > > The PHY reset routine in
>> > > http://bcm-v4.sipsolutions.net/802.11/PHY/Reset, which I just updated
>> > > for the latest N PHY changes, appears to be a different routine than
>> > > b43_put_phy_into_reset(). The names are confusing.
>> >
>> > b43_put_phy_into_reset() is opencoded in the specifications in various init
>> > routines. There's no separate specs page for that function.
>> > But I think the code is straightforward and easy to understand.
>>
>> So is this patch right or not? Should I hold onto it for 2.6.33
>> (i.e. after the 2.6.32 merge window)?
>
> I'm pretty sure it's incorrect.
>
> --
> Greetings, Michael.
>
Do we have the correct reset routine implemented somewhere, or is it a
new routine to add?
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: memleaks, acpi + ext4 + tty
From: John W. Linville @ 2009-08-31 19:33 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Catalin Marinas, H. Peter Anvin, linux-kernel, Aneesh Kumar K.V,
Greg Kroah-Hartman, linux-wireless
In-Reply-To: <43e72e890908311230u28b0642ep7a6bfd9dab82318a@mail.gmail.com>
On Mon, Aug 31, 2009 at 12:30:15PM -0700, Luis R. Rodriguez wrote:
> On Mon, Aug 31, 2009 at 11:37 AM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> > OK I tried this, I even 'rm -rf * ; git checkout -f' and ..
> > merge-2009-08-28 tag yields the same issues, long lag upon bootup with
> > some kmemleaks I cannot even get to check. So somehow something is
> > different between merge-2009-08-28 and Linus' rc8. This is just
> > bizarre so to be even safer I'm just going to do a fresh git clone on
> > wireless-testing.
>
> Hey John so I tested wireless-testing on the merge-2009-08-28 tag on a
> fresh git pull and verified this is indeed busted for me. Although I
> had tried hpa's linux-2.6-allstable on HEAD just to be sure I am now
> building Linus' tree from a fresh git clone on the v2.6.31-rc8 tag
> just to be double check this was indeed not a 2.6.31-rc8 issue but
> instead *something* on wireless-testing. What that something is is
> unclear to me still, I guess after all these tests I'll run a manual
> diff as git doesn't seem to be picking anything up.
As you determined, there is no difference between merge-2009-08-28
and v2.6.31-rc8. If one works and the other doesn't, then the main
thing not working will be git...
What is linux-2.6-allstable? My guess is that the culprit is between
v2.6.31-rc8 and whatever is at the head of linux-2.6-allstable.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: zd1211rw on ppc (iBook G4)
From: Hin-Tak Leung @ 2009-08-31 19:35 UTC (permalink / raw)
To: Michael Buesch; +Cc: Leonardo H. Souza Hamada, linux-wireless
In-Reply-To: <200908312127.57610.mb@bu3sch.de>
On Mon, Aug 31, 2009 at 8:27 PM, Michael Buesch<mb@bu3sch.de> wrote:
> On Monday 31 August 2009 20:26:22 Hin-Tak Leung wrote:
>> It would appear that the rw driver's ieee80211->mac80211 conversion
>> has broken big- endian platforms, at a first guess.
>
> Last time I tested the device worked fine on my powerbook with zd1211rw/mac80211.
> But that's maybe two or three release cycles in the past.
>
> --
> Greetings, Michael.
>
The rw ieee80211->mac80211 conversion happens in 2.6.27->26.28 ...
Iguess the question is whether it was 2.6.28 or 2.6.27 you had success
with? That's unfortunately two *and* three cycles in the past,
respectively :-).
^ permalink raw reply
* Re: [PATCH] ar9170: added phy register initialisation from eeprom values
From: Joerg Albert @ 2009-08-31 19:34 UTC (permalink / raw)
To: Chunkeey; +Cc: John W. Linville, Johannes Berg, linux-wireless@vger.kernel.org
In-Reply-To: <1789900589@web.de>
On 08/31/2009 11:53 AM, Chunkeey@web.de wrote:
> ...
> See Documentation/CodingStyle - Chapter 8
>
> The preferred style for long (multi-line) comments is:
> /*
> * look up a certain register in ar5416_phy_init[] and return the init. value
> * for the band and bandwidth given. Return 0 if register address not found.
> */
> ...
Thanks for the comments. I agree with all of them and will re-spin a patch.
> It's amazing how much **** you can _cut_ from the vendor driver.
Yes, at first sight it looks really complex but it isn't.
> BTW: does this patch help the 1-stage fw stability, or is it still broken?
Turned out I had a corrupt firmware file. After downloading from Luis' URL it works fine
with my WNDA3100. Guess I had an earlier version from before 2009/05/28 or firefox corrupted it during download.
What's your setup to get 80+ MBit/s throughput with the two-stage firmware?
I've used an 802.11g AP so far, but have access to an 802.11n dual-band AP now.
Guess I should use 5GHz as 2.4 is rather crowded here.
How can I put ar9170 into 802.11n/40MHz mode?
Regards,
Jörg.
^ permalink raw reply
* Re: memleaks, acpi + ext4 + tty
From: Luis R. Rodriguez @ 2009-08-31 19:30 UTC (permalink / raw)
To: Catalin Marinas, John W. Linville, H. Peter Anvin
Cc: linux-kernel, Aneesh Kumar K.V, Greg Kroah-Hartman,
linux-wireless
In-Reply-To: <43e72e890908311137k78ac439bs4edf376d07343a32@mail.gmail.com>
On Mon, Aug 31, 2009 at 11:37 AM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> On Mon, Aug 31, 2009 at 10:50 AM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
>> On Mon, Aug 31, 2009 at 1:23 AM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
>>> On Fri, Aug 28, 2009 at 3:09 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
>>>> On Fri, Aug 28, 2009 at 2:50 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
>>>>> On Fri, Aug 28, 2009 at 9:52 AM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
>>>>>> On Fri, Aug 28, 2009 at 9:32 AM, Catalin Marinas<catalin.marinas@arm.com> wrote:
>>>>>>> "Luis R. Rodriguez" <mcgrof@gmail.com> wrote:
>>>>>>>> I have an assorted collection of kmemleak reports for acpi, ext4 and
>>>>>>>> tty, not sure how to read these yet to fix so figure I'd at least post
>>>>>>>> them. To reproduce I can just dd=/dev/zero to some big file and played
>>>>>>>> some video.
>>>>>>>
>>>>>>> If you do a few echo scan > /sys/kernel/debug/kmemleak, do they
>>>>>>> disappear (i.e. transient false positives)?
>>>>>>
>>>>>> Sure, I will once on rc8.
>>>>>>
>>>>>>> Which kernel version is this?
>>>>>>
>>>>>> v2.6.31-rc7-33172-gf4a9f9a
>>>>>>
>>>>>> This is from wireless-testing, which has wireless patches on top of
>>>>>> rc7. John just rebased to rc8 so will give that a shot at work.
>>>>>>
>>>>>>>> unreferenced object 0xffff88003e0015c0 (size 64):
>>>>>>>> comm "swapper", pid 1, jiffies 4294892352
>>>>>>>> backtrace:
>>>>>>>> [<ffffffff81121fad>] create_object+0x13d/0x2d0
>>>>>>>> [<ffffffff81122265>] kmemleak_alloc+0x25/0x60
>>>>>>>> [<ffffffff81118a03>] kmem_cache_alloc_node+0x193/0x200
>>>>>>>> [<ffffffff8152509e>] process_zones+0x70/0x1cd
>>>>>>>> [<ffffffff81525230>] pageset_cpuup_callback+0x35/0x92
>>>>>>>> [<ffffffff8152c9b7>] notifier_call_chain+0x47/0x90
>>>>>>>> [<ffffffff81078549>] __raw_notifier_call_chain+0x9/0x10
>>>>>>>> [<ffffffff81523f25>] _cpu_up+0x75/0x130
>>>>>>>> [<ffffffff8152403a>] cpu_up+0x5a/0x6a
>>>>>>>> [<ffffffff8181969e>] kernel_init+0xcc/0x1ba
>>>>>>>> [<ffffffff810130ca>] child_rip+0xa/0x20
>>>>>>>> [<ffffffffffffffff>] 0xffffffffffffffff
>>>>>>>
>>>>>>> Can't really tell. Maybe a false positive caused by kmemleak not
>>>>>>> scanning the pgdata node_zones. Can you post your .config file?
>>>>>>
>>>>>> Sure, attached.
>>>>>>
>>>>>>>> unreferenced object 0xffff88003cb5f700 (size 64):
>>>>>>>> comm "swapper", pid 1, jiffies 4294892459
>>>>>>>> backtrace:
>>>>>>>> [<ffffffff81121fad>] create_object+0x13d/0x2d0
>>>>>>>> [<ffffffff81122265>] kmemleak_alloc+0x25/0x60
>>>>>>>> [<ffffffff81119f3b>] __kmalloc+0x16b/0x250
>>>>>>>> [<ffffffff812bb549>] kzalloc+0xf/0x11
>>>>>>>> [<ffffffff812bbb53>] acpi_add_single_object+0x58e/0xd3c
>>>>>>>> [<ffffffff812bc51c>] acpi_bus_scan+0x125/0x1af
>>>>>>>> [<ffffffff81842361>] acpi_scan_init+0xc8/0xe9
>>>>>>>> [<ffffffff8184211c>] acpi_init+0x21f/0x265
>>>>>>>> [<ffffffff8100a05b>] do_one_initcall+0x4b/0x1b0
>>>>>>>> [<ffffffff81819736>] kernel_init+0x164/0x1ba
>>>>>>>> [<ffffffff810130ca>] child_rip+0xa/0x20
>>>>>>>> [<ffffffffffffffff>] 0xffffffffffffffff
>>>>>>>
>>>>>>> I get ACPI reports as well and they may be real leaks. However, I
>>>>>>> didn't have time to analyse the code (pretty complicated reference
>>>>>>> counting).
>>>>>>
>>>>>> Heh OK thanks for reviewing them though.
>>>>>>
>>>>>>>> unreferenced object 0xffff880039571800 (size 1024):
>>>>>>>> comm "exe", pid 1168, jiffies 4294893410
>>>>>>>> backtrace:
>>>>>>>> [<ffffffff81121fad>] create_object+0x13d/0x2d0
>>>>>>>> [<ffffffff81122265>] kmemleak_alloc+0x25/0x60
>>>>>>>> [<ffffffff81119f3b>] __kmalloc+0x16b/0x250
>>>>>>>> [<ffffffff811e1d71>] ext4_mb_init+0x1a1/0x590
>>>>>>>> [<ffffffff811d2da3>] ext4_fill_super+0x1df3/0x26c0
>>>>>>>> [<ffffffff8112774f>] get_sb_bdev+0x16f/0x1b0
>>>>>>>> [<ffffffff811c8fd3>] ext4_get_sb+0x13/0x20
>>>>>>>> [<ffffffff81127216>] vfs_kern_mount+0x76/0x180
>>>>>>>> [<ffffffff8112738d>] do_kern_mount+0x4d/0x130
>>>>>>>> [<ffffffff8113fc57>] do_mount+0x307/0x8b0
>>>>>>>> [<ffffffff8114028f>] sys_mount+0x8f/0xe0
>>>>>>>> [<ffffffff81011f02>] system_call_fastpath+0x16/0x1b
>>>>>>>> [<ffffffffffffffff>] 0xffffffffffffffff
>>>>>>>
>>>>>>> The ext4 reports are real leaks and patch was posted here -
>>>>>>> http://lkml.org/lkml/2009/7/15/62. However, it hasn't been merged into
>>>>>>> mainline yet (I cc'ed Aneesh).
>>>>>>>
>>>>>>> The patch is merged in my "kmemleak-fixes" branch on
>>>>>>> git://linux-arm.org/linux-2.6.git.
>>>>>>
>>>>>> Will try to suck them out and try them.
>>>>>
>>>>> OK -- tested rc8 + a pull of your tree into mine. The bootup was
>>>>> really slow and something was just not going right. After a while
>>>>> memleak complained it had 8 kmemleak logs but I was not able to get my
>>>>> system usable enough to cat the file.
>>>>>
>>>>> In cases like these I wish I would hookup my ctrl-alt-del to kexec() a
>>>>> safe kernel.
>>>>>
>>>>> After a long period of time it seems X wished it would start, it tried
>>>>> and then flashed back to the tty. This kept repeating in a loop.
>>>>>
>>>>> I am not sure if the culprit was rc8 or the kmemleak branch merge --
>>>>> I'll find out after I boot into rc8 in a few.
>>>>
>>>> rc8 busted my bootup, the issues are present with just
>>>> wireless-testing. I highly doubt the issues are wireless-testing
>>>> related so I will not bisect there. Since I am unable to get anything
>>>> useful from the kernel to determine what may have gone sour, any
>>>> suggestions on a path to bisect, or should I just do the whole tree?
>>>
>>> I tried 2.6.31-rc8 from hpa's linux-2.6-allstable.git tree instead of
>>> Linus [1] as I already had that tree, git describe says:
>>>
>>> v2.6.31-rc8-15-gadda766
>>>
>>> Testing this would be the same as testing Linus' blessed rc8 --
>>> correct me I'm wrong. Contrary to what I expected this tree with the
>>> same config works well!
>>>
>>> I have compiled a fresh checkout of wireless-testing origin/master to
>>> double check the issue and it is indeed only present on
>>> wireless-testing. A diff stat between John's merge of 2.6.31-rc8 and
>>> current master branch on wireless-testing [2] doesn't reveal much
>>> other than wireless specific stuff, as expected, so it seems this may
>>> after all be introduced in a recent patches in wireless-testing. I
>>> still find this a bit odd given I see no others reporting major
>>> issues. My boot doesn't go very far, it stalls for a while after input
>>> devices are being detected, then it spits out a kmemleak warning about
>>> 13 kmemleaks. Here's a picture [3]. I didn't bother waiting as I did
>>> last time for X to try to come up, something is really wrong. I'll
>>> bisect wireless-testing in the morning, starting with a good marker at
>>> merge-2009-08-28 as that is when John pulled 2.6.31-rc8 (and I confirm
>>> a diff stat between that and v2.6.31-rc8 yields nothing as it should)
>>> and current master as the bad marker. I have 9 steps to go, will leave
>>> first step compiling overnight.
>>>
>>> [1] git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-allstable.git
>>> [2] git diff --stat merge-2009-08-28..HEAD
>>> [3] http://bombadil.infradead.org/~mcgrof/images/2009/08/lag-wl-2009-08-31.jpg
>>> [4] git diff --stat merge-2009-08-28..v2.6.31-rc8
>>
>> Hah, well this makes no sense:
>>
>> mcgrof@tux ~/wireless-testing (git::(no branch))$ git bisect bad
>> a4e774ca75e5f2d8347b4d9746a2e0a9a4fc521b is first bad commit
>> commit a4e774ca75e5f2d8347b4d9746a2e0a9a4fc521b
>> Author: John W. Linville <linville@tuxdriver.com>
>> Date: Wed Feb 27 16:04:18 2008 -0500
>>
>> Add localversion-wireless to identify builds from this tree.
>>
>> Signed-off-by: John W. Linville <linville@tuxdriver.com>
>>
>> :000000 100644 0000000000000000000000000000000000000000
>> 6a05d60db3b21d9c0a0b93b831c6ea453dc98785 A localversion-wireless
>>
>> I'll try a fresh branch on merge-2009-08-28 ..
>
> OK I tried this, I even 'rm -rf * ; git checkout -f' and ..
> merge-2009-08-28 tag yields the same issues, long lag upon bootup with
> some kmemleaks I cannot even get to check. So somehow something is
> different between merge-2009-08-28 and Linus' rc8. This is just
> bizarre so to be even safer I'm just going to do a fresh git clone on
> wireless-testing.
Hey John so I tested wireless-testing on the merge-2009-08-28 tag on a
fresh git pull and verified this is indeed busted for me. Although I
had tried hpa's linux-2.6-allstable on HEAD just to be sure I am now
building Linus' tree from a fresh git clone on the v2.6.31-rc8 tag
just to be double check this was indeed not a 2.6.31-rc8 issue but
instead *something* on wireless-testing. What that something is is
unclear to me still, I guess after all these tests I'll run a manual
diff as git doesn't seem to be picking anything up.
Luis
^ permalink raw reply
* Re: zd1211rw on ppc (iBook G4)
From: Michael Buesch @ 2009-08-31 19:27 UTC (permalink / raw)
To: Hin-Tak Leung; +Cc: Leonardo H. Souza Hamada, linux-wireless
In-Reply-To: <3ace41890908311126m5212926cl27172ae775fc92f2@mail.gmail.com>
On Monday 31 August 2009 20:26:22 Hin-Tak Leung wrote:
> It would appear that the rw driver's ieee80211->mac80211 conversion
> has broken big- endian platforms, at a first guess.
Last time I tested the device worked fine on my powerbook with zd1211rw/mac80211.
But that's maybe two or three release cycles in the past.
--
Greetings, Michael.
^ permalink raw reply
* Re: hal, rfkill and compat-wireless (Re: [RFC/RFT] rtl8187: Implement rfkill support)
From: Luis R. Rodriguez @ 2009-08-31 19:25 UTC (permalink / raw)
To: Hin-Tak Leung, linux-wireless, Perez-Gonzalez, Inaky
In-Reply-To: <3ace41890908311215u378951e8j3283037ec6794764@mail.gmail.com>
On Mon, Aug 31, 2009 at 12:15 PM, Hin-Tak Leung<hintak.leung@gmail.com> wrote:
> On Mon, Aug 31, 2009 at 7:54 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
>> On Mon, Aug 31, 2009 at 11:43 AM, Hin-Tak Leung<hintak.leung@gmail.com> wrote:
>>> On Thu, Aug 27, 2009 at 10:43 AM, Hin-Tak Leung<hintak.leung@gmail.com> wrote:
>>>> On Thu, Aug 27, 2009 at 8:14 AM, Johannes Berg<johannes@sipsolutions.net> wrote:
>>>>> On Wed, 2009-08-26 at 16:45 -0700, Luis R. Rodriguez wrote:
>>>>>
>>>>>> Johannes, did kernels < 2.6.31 have /sys/class/rfkill ?
>>>>>
>>>>> Yes, but I never understood why that matters. If you've got
>>>>> compat-wireless "rfkill" loaded then the original rfkill can't be loaded
>>>>> anyway. And their symbols would probably clash anyway if the original is
>>>>> built in, in which case you can't use compat.
>>>>>
>>>>> You haven't renamed cfg80211's sysfs either, so why rfkill?
>>>>>
>>>>> johannes
>>>>>
>>>>
>>>> There are a couple of wimax drivers which depends on rfkill... or
>>>> bluetooth drivers? I think one likely reason is that there are valid
>>>> situations or hardware combinations which requires having both of them
>>>> loaded. (but that's a whole can of worms )
>>>
>>> Argh, I just have a stacktrace after reboot - toshiba_acpi.ko (on a
>>> toshiba laptop) requires the stock-kernel rfkill-* symbols, and rfkill
>>> won't load because of my modified compat-wireless rfkill_backport.ko
>>> which takes up /sys/class/rfkill rather than
>>> /sys/class/rfkill_backport . There's your reason from sysfs renaming.
>>> I wonder why/how I could unload rfkill.ko earlier, since the *_acpi.ko
>>> needs it - maybe I had acpi unloaded as a side-effect also.
>>>
>>> I guess we'll need hal to treat /sys/class/rfkill_backport like
>>> /sys/class/rfkill then - will file a bug somewhere on freedesktop,
>>> although I hear hal is on its way out....
>>
>> How many modules depend on rfkill, as with ssb maybe we should just
>> add them all ? I'm not volunteering though, but just pointing out that
>> if its not that many as with ssb perhaps its best to just add the
>> other drivers.
>>
>> Luis
>>
>
> for fedora 11's stock, (which probably have all the modules of any use)
> #depmod -v | grep rfkill_register shows, besides drivers/net/wireless/* ,
>
> kernel/drivers/net/usb/hso.ko
> kernel/drivers/platform/x86/dell-laptop.ko
> kernel/drivers/platform/x86/acer-wmi.ko
> kernel/drivers/platform/x86/hp-wmi.ko
> kernel/drivers/platform/x86/sony-laptop.ko
> kernel/drivers/platform/x86/thinkpad_acpi.ko
> kernel/drivers/platform/x86/toshiba_acpi.ko
> kernel/net/wireless/cfg80211.ko
OK not so bad except for:
> kernel/net/wimax/wimax.ko
That's touching another subsystem but we could technically merge wimax
into compat-wireless if Inaky thinks that's a good idea. the point
here is to unify anything that uses rfkill for backport usage.
> If everything that depends on rkill is bundled with
> compat-wireless, there is probablt no need for the symbol and sysfs
> renaming hacks.
Right which is why I think this may be reasonable to do. Any thoughts Inaky?
Luis
^ permalink raw reply
* Re: [PATCH v2] b43: LP-PHY: Begin implementing calibration & software RFKILL support
From: Larry Finger @ 2009-08-31 19:23 UTC (permalink / raw)
To: Michael Buesch
Cc: John W. Linville, Gábor Stefanik, Mark Huijgen,
Broadcom Wireless, linux-wireless
In-Reply-To: <200908312117.26915.mb@bu3sch.de>
Michael Buesch wrote:
> On Monday 31 August 2009 19:53:31 John W. Linville wrote:
>> On Sun, Aug 30, 2009 at 05:55:40PM +0200, Michael Buesch wrote:
>>> On Sunday 30 August 2009 17:10:23 Larry Finger wrote:
>>>> Michael Buesch wrote:
>>>>> On Sunday 30 August 2009 02:15:55 Gábor Stefanik wrote:
>>>>>> static void lpphy_pr41573_workaround(struct b43_wldev *dev)
>>>>>> {
>>>>>> struct b43_phy_lp *lpphy = dev->phy.lp;
>>>>>> @@ -1357,28 +1488,440 @@ static void lpphy_pr41573_workaround(struct b43_wldev *dev)
>>>>>> b43_lptab_read_bulk(dev, B43_LPTAB32(7, 0x140),
>>>>>> saved_tab_size, saved_tab);
>>>>>> }
>>>>>> + b43_put_phy_into_reset(dev);
>>>>> Are you sure you really want this?
>>>>> This function completely disables the PHY on the backplane and keeps the physical
>>>>> PHY reset pin asserted (even after return from the function).
>>>>> So the PHY will physically be powered down from this point on. The following
>>>>> PHY accesses could even hang the machine, because the PHY won't respond to
>>>>> register accesses anymore.
>>>>>
>>>>> We currently only use this function on A/G Multi-PHY devices to permanently
>>>>> hard-disable the PHY that's not used.
>>>> The PHY reset routine in
>>>> http://bcm-v4.sipsolutions.net/802.11/PHY/Reset, which I just updated
>>>> for the latest N PHY changes, appears to be a different routine than
>>>> b43_put_phy_into_reset(). The names are confusing.
>>> b43_put_phy_into_reset() is opencoded in the specifications in various init
>>> routines. There's no separate specs page for that function.
>>> But I think the code is straightforward and easy to understand.
>> So is this patch right or not? Should I hold onto it for 2.6.33
>> (i.e. after the 2.6.32 merge window)?
>
> I'm pretty sure it's incorrect.
I agree.
Larry
^ permalink raw reply
* Re: [PATCH v2] b43: LP-PHY: Begin implementing calibration & software RFKILL support
From: Michael Buesch @ 2009-08-31 19:17 UTC (permalink / raw)
To: John W. Linville
Cc: Larry Finger, Gábor Stefanik, Mark Huijgen,
Broadcom Wireless, linux-wireless
In-Reply-To: <20090831175331.GB5631@tuxdriver.com>
On Monday 31 August 2009 19:53:31 John W. Linville wrote:
> On Sun, Aug 30, 2009 at 05:55:40PM +0200, Michael Buesch wrote:
> > On Sunday 30 August 2009 17:10:23 Larry Finger wrote:
> > > Michael Buesch wrote:
> > > > On Sunday 30 August 2009 02:15:55 Gábor Stefanik wrote:
> > > >> static void lpphy_pr41573_workaround(struct b43_wldev *dev)
> > > >> {
> > > >> struct b43_phy_lp *lpphy = dev->phy.lp;
> > > >> @@ -1357,28 +1488,440 @@ static void lpphy_pr41573_workaround(struct b43_wldev *dev)
> > > >> b43_lptab_read_bulk(dev, B43_LPTAB32(7, 0x140),
> > > >> saved_tab_size, saved_tab);
> > > >> }
> > > >> + b43_put_phy_into_reset(dev);
> > > >
> > > > Are you sure you really want this?
> > > > This function completely disables the PHY on the backplane and keeps the physical
> > > > PHY reset pin asserted (even after return from the function).
> > > > So the PHY will physically be powered down from this point on. The following
> > > > PHY accesses could even hang the machine, because the PHY won't respond to
> > > > register accesses anymore.
> > > >
> > > > We currently only use this function on A/G Multi-PHY devices to permanently
> > > > hard-disable the PHY that's not used.
> > >
> > > The PHY reset routine in
> > > http://bcm-v4.sipsolutions.net/802.11/PHY/Reset, which I just updated
> > > for the latest N PHY changes, appears to be a different routine than
> > > b43_put_phy_into_reset(). The names are confusing.
> >
> > b43_put_phy_into_reset() is opencoded in the specifications in various init
> > routines. There's no separate specs page for that function.
> > But I think the code is straightforward and easy to understand.
>
> So is this patch right or not? Should I hold onto it for 2.6.33
> (i.e. after the 2.6.32 merge window)?
I'm pretty sure it's incorrect.
--
Greetings, Michael.
^ permalink raw reply
* Re: [PATCH] rfkill: relicense header file
From: Michael Buesch @ 2009-08-31 19:16 UTC (permalink / raw)
To: John W. Linville
Cc: Johannes Berg, linux-wireless, Alan Jenkins,
Henrique de Moraes Holschuh, Iñaky Pérez-González,
Ivo van Doorn, Jaswinder Singh Rajput, Tomas Winkler
In-Reply-To: <20090831174542.GA5631@tuxdriver.com>
On Monday 31 August 2009 19:45:43 John W. Linville wrote:
> On Wed, Aug 26, 2009 at 06:13:17PM +0200, Johannes Berg wrote:
> > This header file is copied into userspace tools that
> > need not be GPLv2 licensed, make that easier.
> >
> > Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
> > Cc: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
> > Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
> > Cc: Iñaky Pérez-González <inaky.perez-gonzalez@intel.com>
> > Cc: Ivo van Doorn <IvDoorn@gmail.com>
> > Cc: Jaswinder Singh Rajput <jaswinder@kernel.org>
> > Cc: John W. Linville <linville@tuxdriver.com>
> > Cc: Michael Buesch <mb@bu3sch.de>
> > Cc: Tomas Winkler <tomas.winkler@intel.com>
> > ---
> > Need ACK from everybody listed who ever touched this
> > file according to git. Please?
>
> Michael? Jaswinder?
>
No problem. I don't think there's anything copyrightable by me in that file.
--
Greetings, Michael.
^ permalink raw reply
* Re: rtl8187b Problem with tx level
From: Hin-Tak Leung @ 2009-08-31 18:57 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Tobias Schlemmer, linux-wireless
In-Reply-To: <43e72e890908311141k6bcf5edbl6bce2b88670fb5f8@mail.gmail.com>
On Mon, Aug 31, 2009 at 7:41 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> On Mon, Aug 31, 2009 at 11:32 AM, Hin-Tak Leung<hintak.leung@gmail.com> wrote:
>> On Mon, Aug 31, 2009 at 7:02 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
>>> On Mon, Aug 31, 2009 at 10:55 AM, Hin-Tak Leung<hintak.leung@gmail.com> wrote:
>>>> On Sun, Aug 30, 2009 at 9:44 PM, Tobias
>>>> Schlemmer<keinstein_junior@gmx.net> wrote:
>>>>> Hi,
>>>>>
>>>>> I have some problem with my rtl8187b device. It is included in my laptop
>>>>> running Ubuntu linux 2.6.28. I've tested several compat-wireless releases
>>>>> including 2.6.30 and 2.6.31-rc7.
>>>>
>>>> Hmm, are compat-wireless versioned against kernels?
>>>
>>> The stable ones are:
>>>
>>> http://wireless.kernel.org/en/users/Download/stable/
>>>
>>> Luis
>>>
>>
>> Thanks - it is new addition to the web-site :-), I see.
>
> Yup, and when 2.6.32-rc1 is released we'll have another
> compat-wireless tarball made from that as well.
>
>> Anyway, Larry
>> and Herton have made more changes/improvements in rtl8187 in
>> latest-and-greatest than 2.6.31-rc7...
>
> Thanks for the heads up, what I recommend is you edit the
> wireless.kernel.org wiki page for rtl8187 and put there a section of
> 'recommended version' and explain what kernel release you expect to
> work the best, and if you do recommend latest and greatest put that on
> the wiki. This is what we did for ath9k as ath9k changes kept coming
> in for ath9k through kernel releases and distributions were still on
> old versions of it. What I hope is eventually users will just know to
> check wireless.kernel.org driver page for details for their own
> drivers.
>
> Luis
>
I just took a look at the history - there aren't obvious bug fixes, a
bunch of work queue-related changes from you & Johannes; feature-wise,
Larry added LED blinking after 2.6.30, and Herton added rfkill support
quite recently after 2.6.31-rc7 . But no, there isn't any change that
would affect tx level beyond 2.6.31-rc7, I think.
^ permalink raw reply
* Re: hal, rfkill and compat-wireless (Re: [RFC/RFT] rtl8187: Implement rfkill support)
From: Luis R. Rodriguez @ 2009-08-31 18:54 UTC (permalink / raw)
To: Hin-Tak Leung
Cc: Johannes Berg, hal, htl10, Larry Finger,
Herton Ronaldo Krzesinski, linux-wireless
In-Reply-To: <3ace41890908311143q697898a3mcbc681d3941b45c9@mail.gmail.com>
On Mon, Aug 31, 2009 at 11:43 AM, Hin-Tak Leung<hintak.leung@gmail.com> wrote:
> On Thu, Aug 27, 2009 at 10:43 AM, Hin-Tak Leung<hintak.leung@gmail.com> wrote:
>> On Thu, Aug 27, 2009 at 8:14 AM, Johannes Berg<johannes@sipsolutions.net> wrote:
>>> On Wed, 2009-08-26 at 16:45 -0700, Luis R. Rodriguez wrote:
>>>
>>>> Johannes, did kernels < 2.6.31 have /sys/class/rfkill ?
>>>
>>> Yes, but I never understood why that matters. If you've got
>>> compat-wireless "rfkill" loaded then the original rfkill can't be loaded
>>> anyway. And their symbols would probably clash anyway if the original is
>>> built in, in which case you can't use compat.
>>>
>>> You haven't renamed cfg80211's sysfs either, so why rfkill?
>>>
>>> johannes
>>>
>>
>> There are a couple of wimax drivers which depends on rfkill... or
>> bluetooth drivers? I think one likely reason is that there are valid
>> situations or hardware combinations which requires having both of them
>> loaded. (but that's a whole can of worms )
>
> Argh, I just have a stacktrace after reboot - toshiba_acpi.ko (on a
> toshiba laptop) requires the stock-kernel rfkill-* symbols, and rfkill
> won't load because of my modified compat-wireless rfkill_backport.ko
> which takes up /sys/class/rfkill rather than
> /sys/class/rfkill_backport . There's your reason from sysfs renaming.
> I wonder why/how I could unload rfkill.ko earlier, since the *_acpi.ko
> needs it - maybe I had acpi unloaded as a side-effect also.
>
> I guess we'll need hal to treat /sys/class/rfkill_backport like
> /sys/class/rfkill then - will file a bug somewhere on freedesktop,
> although I hear hal is on its way out....
How many modules depend on rfkill, as with ssb maybe we should just
add them all ? I'm not volunteering though, but just pointing out that
if its not that many as with ssb perhaps its best to just add the
other drivers.
Luis
^ permalink raw reply
* Re: hal, rfkill and compat-wireless (Re: [RFC/RFT] rtl8187: Implement rfkill support)
From: Hin-Tak Leung @ 2009-08-31 18:43 UTC (permalink / raw)
To: Johannes Berg
Cc: Luis R. Rodriguez, hal, htl10, Larry Finger,
Herton Ronaldo Krzesinski, linux-wireless
In-Reply-To: <3ace41890908270243i7c1d8ddav322a35c566d2c010@mail.gmail.com>
On Thu, Aug 27, 2009 at 10:43 AM, Hin-Tak Leung<hintak.leung@gmail.com> wrote:
> On Thu, Aug 27, 2009 at 8:14 AM, Johannes Berg<johannes@sipsolutions.net> wrote:
>> On Wed, 2009-08-26 at 16:45 -0700, Luis R. Rodriguez wrote:
>>
>>> Johannes, did kernels < 2.6.31 have /sys/class/rfkill ?
>>
>> Yes, but I never understood why that matters. If you've got
>> compat-wireless "rfkill" loaded then the original rfkill can't be loaded
>> anyway. And their symbols would probably clash anyway if the original is
>> built in, in which case you can't use compat.
>>
>> You haven't renamed cfg80211's sysfs either, so why rfkill?
>>
>> johannes
>>
>
> There are a couple of wimax drivers which depends on rfkill... or
> bluetooth drivers? I think one likely reason is that there are valid
> situations or hardware combinations which requires having both of them
> loaded. (but that's a whole can of worms )
Argh, I just have a stacktrace after reboot - toshiba_acpi.ko (on a
toshiba laptop) requires the stock-kernel rfkill-* symbols, and rfkill
won't load because of my modified compat-wireless rfkill_backport.ko
which takes up /sys/class/rfkill rather than
/sys/class/rfkill_backport . There's your reason from sysfs renaming.
I wonder why/how I could unload rfkill.ko earlier, since the *_acpi.ko
needs it - maybe I had acpi unloaded as a side-effect also.
I guess we'll need hal to treat /sys/class/rfkill_backport like
/sys/class/rfkill then - will file a bug somewhere on freedesktop,
although I hear hal is on its way out....
^ permalink raw reply
* Re: rtl8187b Problem with tx level
From: Luis R. Rodriguez @ 2009-08-31 18:41 UTC (permalink / raw)
To: Hin-Tak Leung; +Cc: Tobias Schlemmer, linux-wireless
In-Reply-To: <3ace41890908311132g16783b68y2d1771ce1d2780d@mail.gmail.com>
On Mon, Aug 31, 2009 at 11:32 AM, Hin-Tak Leung<hintak.leung@gmail.com> wrote:
> On Mon, Aug 31, 2009 at 7:02 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
>> On Mon, Aug 31, 2009 at 10:55 AM, Hin-Tak Leung<hintak.leung@gmail.com> wrote:
>>> On Sun, Aug 30, 2009 at 9:44 PM, Tobias
>>> Schlemmer<keinstein_junior@gmx.net> wrote:
>>>> Hi,
>>>>
>>>> I have some problem with my rtl8187b device. It is included in my laptop
>>>> running Ubuntu linux 2.6.28. I've tested several compat-wireless releases
>>>> including 2.6.30 and 2.6.31-rc7.
>>>
>>> Hmm, are compat-wireless versioned against kernels?
>>
>> The stable ones are:
>>
>> http://wireless.kernel.org/en/users/Download/stable/
>>
>> Luis
>>
>
> Thanks - it is new addition to the web-site :-), I see.
Yup, and when 2.6.32-rc1 is released we'll have another
compat-wireless tarball made from that as well.
> Anyway, Larry
> and Herton have made more changes/improvements in rtl8187 in
> latest-and-greatest than 2.6.31-rc7...
Thanks for the heads up, what I recommend is you edit the
wireless.kernel.org wiki page for rtl8187 and put there a section of
'recommended version' and explain what kernel release you expect to
work the best, and if you do recommend latest and greatest put that on
the wiki. This is what we did for ath9k as ath9k changes kept coming
in for ath9k through kernel releases and distributions were still on
old versions of it. What I hope is eventually users will just know to
check wireless.kernel.org driver page for details for their own
drivers.
Luis
^ permalink raw reply
* Re: memleaks, acpi + ext4 + tty
From: Luis R. Rodriguez @ 2009-08-31 18:37 UTC (permalink / raw)
To: Catalin Marinas, John W. Linville, H. Peter Anvin
Cc: linux-kernel, Aneesh Kumar K.V, Greg Kroah-Hartman,
linux-wireless
In-Reply-To: <43e72e890908311050s320d0ceen312a0d3d9e4fbc76@mail.gmail.com>
On Mon, Aug 31, 2009 at 10:50 AM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> On Mon, Aug 31, 2009 at 1:23 AM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
>> On Fri, Aug 28, 2009 at 3:09 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
>>> On Fri, Aug 28, 2009 at 2:50 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
>>>> On Fri, Aug 28, 2009 at 9:52 AM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
>>>>> On Fri, Aug 28, 2009 at 9:32 AM, Catalin Marinas<catalin.marinas@arm.com> wrote:
>>>>>> "Luis R. Rodriguez" <mcgrof@gmail.com> wrote:
>>>>>>> I have an assorted collection of kmemleak reports for acpi, ext4 and
>>>>>>> tty, not sure how to read these yet to fix so figure I'd at least post
>>>>>>> them. To reproduce I can just dd=/dev/zero to some big file and played
>>>>>>> some video.
>>>>>>
>>>>>> If you do a few echo scan > /sys/kernel/debug/kmemleak, do they
>>>>>> disappear (i.e. transient false positives)?
>>>>>
>>>>> Sure, I will once on rc8.
>>>>>
>>>>>> Which kernel version is this?
>>>>>
>>>>> v2.6.31-rc7-33172-gf4a9f9a
>>>>>
>>>>> This is from wireless-testing, which has wireless patches on top of
>>>>> rc7. John just rebased to rc8 so will give that a shot at work.
>>>>>
>>>>>>> unreferenced object 0xffff88003e0015c0 (size 64):
>>>>>>> comm "swapper", pid 1, jiffies 4294892352
>>>>>>> backtrace:
>>>>>>> [<ffffffff81121fad>] create_object+0x13d/0x2d0
>>>>>>> [<ffffffff81122265>] kmemleak_alloc+0x25/0x60
>>>>>>> [<ffffffff81118a03>] kmem_cache_alloc_node+0x193/0x200
>>>>>>> [<ffffffff8152509e>] process_zones+0x70/0x1cd
>>>>>>> [<ffffffff81525230>] pageset_cpuup_callback+0x35/0x92
>>>>>>> [<ffffffff8152c9b7>] notifier_call_chain+0x47/0x90
>>>>>>> [<ffffffff81078549>] __raw_notifier_call_chain+0x9/0x10
>>>>>>> [<ffffffff81523f25>] _cpu_up+0x75/0x130
>>>>>>> [<ffffffff8152403a>] cpu_up+0x5a/0x6a
>>>>>>> [<ffffffff8181969e>] kernel_init+0xcc/0x1ba
>>>>>>> [<ffffffff810130ca>] child_rip+0xa/0x20
>>>>>>> [<ffffffffffffffff>] 0xffffffffffffffff
>>>>>>
>>>>>> Can't really tell. Maybe a false positive caused by kmemleak not
>>>>>> scanning the pgdata node_zones. Can you post your .config file?
>>>>>
>>>>> Sure, attached.
>>>>>
>>>>>>> unreferenced object 0xffff88003cb5f700 (size 64):
>>>>>>> comm "swapper", pid 1, jiffies 4294892459
>>>>>>> backtrace:
>>>>>>> [<ffffffff81121fad>] create_object+0x13d/0x2d0
>>>>>>> [<ffffffff81122265>] kmemleak_alloc+0x25/0x60
>>>>>>> [<ffffffff81119f3b>] __kmalloc+0x16b/0x250
>>>>>>> [<ffffffff812bb549>] kzalloc+0xf/0x11
>>>>>>> [<ffffffff812bbb53>] acpi_add_single_object+0x58e/0xd3c
>>>>>>> [<ffffffff812bc51c>] acpi_bus_scan+0x125/0x1af
>>>>>>> [<ffffffff81842361>] acpi_scan_init+0xc8/0xe9
>>>>>>> [<ffffffff8184211c>] acpi_init+0x21f/0x265
>>>>>>> [<ffffffff8100a05b>] do_one_initcall+0x4b/0x1b0
>>>>>>> [<ffffffff81819736>] kernel_init+0x164/0x1ba
>>>>>>> [<ffffffff810130ca>] child_rip+0xa/0x20
>>>>>>> [<ffffffffffffffff>] 0xffffffffffffffff
>>>>>>
>>>>>> I get ACPI reports as well and they may be real leaks. However, I
>>>>>> didn't have time to analyse the code (pretty complicated reference
>>>>>> counting).
>>>>>
>>>>> Heh OK thanks for reviewing them though.
>>>>>
>>>>>>> unreferenced object 0xffff880039571800 (size 1024):
>>>>>>> comm "exe", pid 1168, jiffies 4294893410
>>>>>>> backtrace:
>>>>>>> [<ffffffff81121fad>] create_object+0x13d/0x2d0
>>>>>>> [<ffffffff81122265>] kmemleak_alloc+0x25/0x60
>>>>>>> [<ffffffff81119f3b>] __kmalloc+0x16b/0x250
>>>>>>> [<ffffffff811e1d71>] ext4_mb_init+0x1a1/0x590
>>>>>>> [<ffffffff811d2da3>] ext4_fill_super+0x1df3/0x26c0
>>>>>>> [<ffffffff8112774f>] get_sb_bdev+0x16f/0x1b0
>>>>>>> [<ffffffff811c8fd3>] ext4_get_sb+0x13/0x20
>>>>>>> [<ffffffff81127216>] vfs_kern_mount+0x76/0x180
>>>>>>> [<ffffffff8112738d>] do_kern_mount+0x4d/0x130
>>>>>>> [<ffffffff8113fc57>] do_mount+0x307/0x8b0
>>>>>>> [<ffffffff8114028f>] sys_mount+0x8f/0xe0
>>>>>>> [<ffffffff81011f02>] system_call_fastpath+0x16/0x1b
>>>>>>> [<ffffffffffffffff>] 0xffffffffffffffff
>>>>>>
>>>>>> The ext4 reports are real leaks and patch was posted here -
>>>>>> http://lkml.org/lkml/2009/7/15/62. However, it hasn't been merged into
>>>>>> mainline yet (I cc'ed Aneesh).
>>>>>>
>>>>>> The patch is merged in my "kmemleak-fixes" branch on
>>>>>> git://linux-arm.org/linux-2.6.git.
>>>>>
>>>>> Will try to suck them out and try them.
>>>>
>>>> OK -- tested rc8 + a pull of your tree into mine. The bootup was
>>>> really slow and something was just not going right. After a while
>>>> memleak complained it had 8 kmemleak logs but I was not able to get my
>>>> system usable enough to cat the file.
>>>>
>>>> In cases like these I wish I would hookup my ctrl-alt-del to kexec() a
>>>> safe kernel.
>>>>
>>>> After a long period of time it seems X wished it would start, it tried
>>>> and then flashed back to the tty. This kept repeating in a loop.
>>>>
>>>> I am not sure if the culprit was rc8 or the kmemleak branch merge --
>>>> I'll find out after I boot into rc8 in a few.
>>>
>>> rc8 busted my bootup, the issues are present with just
>>> wireless-testing. I highly doubt the issues are wireless-testing
>>> related so I will not bisect there. Since I am unable to get anything
>>> useful from the kernel to determine what may have gone sour, any
>>> suggestions on a path to bisect, or should I just do the whole tree?
>>
>> I tried 2.6.31-rc8 from hpa's linux-2.6-allstable.git tree instead of
>> Linus [1] as I already had that tree, git describe says:
>>
>> v2.6.31-rc8-15-gadda766
>>
>> Testing this would be the same as testing Linus' blessed rc8 --
>> correct me I'm wrong. Contrary to what I expected this tree with the
>> same config works well!
>>
>> I have compiled a fresh checkout of wireless-testing origin/master to
>> double check the issue and it is indeed only present on
>> wireless-testing. A diff stat between John's merge of 2.6.31-rc8 and
>> current master branch on wireless-testing [2] doesn't reveal much
>> other than wireless specific stuff, as expected, so it seems this may
>> after all be introduced in a recent patches in wireless-testing. I
>> still find this a bit odd given I see no others reporting major
>> issues. My boot doesn't go very far, it stalls for a while after input
>> devices are being detected, then it spits out a kmemleak warning about
>> 13 kmemleaks. Here's a picture [3]. I didn't bother waiting as I did
>> last time for X to try to come up, something is really wrong. I'll
>> bisect wireless-testing in the morning, starting with a good marker at
>> merge-2009-08-28 as that is when John pulled 2.6.31-rc8 (and I confirm
>> a diff stat between that and v2.6.31-rc8 yields nothing as it should)
>> and current master as the bad marker. I have 9 steps to go, will leave
>> first step compiling overnight.
>>
>> [1] git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-allstable.git
>> [2] git diff --stat merge-2009-08-28..HEAD
>> [3] http://bombadil.infradead.org/~mcgrof/images/2009/08/lag-wl-2009-08-31.jpg
>> [4] git diff --stat merge-2009-08-28..v2.6.31-rc8
>
> Hah, well this makes no sense:
>
> mcgrof@tux ~/wireless-testing (git::(no branch))$ git bisect bad
> a4e774ca75e5f2d8347b4d9746a2e0a9a4fc521b is first bad commit
> commit a4e774ca75e5f2d8347b4d9746a2e0a9a4fc521b
> Author: John W. Linville <linville@tuxdriver.com>
> Date: Wed Feb 27 16:04:18 2008 -0500
>
> Add localversion-wireless to identify builds from this tree.
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
>
> :000000 100644 0000000000000000000000000000000000000000
> 6a05d60db3b21d9c0a0b93b831c6ea453dc98785 A localversion-wireless
>
> I'll try a fresh branch on merge-2009-08-28 ..
OK I tried this, I even 'rm -rf * ; git checkout -f' and ..
merge-2009-08-28 tag yields the same issues, long lag upon bootup with
some kmemleaks I cannot even get to check. So somehow something is
different between merge-2009-08-28 and Linus' rc8. This is just
bizarre so to be even safer I'm just going to do a fresh git clone on
wireless-testing.
Luis
^ permalink raw reply
* Re: rtl8187b Problem with tx level
From: Hin-Tak Leung @ 2009-08-31 18:32 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Tobias Schlemmer, linux-wireless
In-Reply-To: <43e72e890908311102q2ed9e8b3q8f1f15d45a29b2f1@mail.gmail.com>
On Mon, Aug 31, 2009 at 7:02 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> On Mon, Aug 31, 2009 at 10:55 AM, Hin-Tak Leung<hintak.leung@gmail.com> wrote:
>> On Sun, Aug 30, 2009 at 9:44 PM, Tobias
>> Schlemmer<keinstein_junior@gmx.net> wrote:
>>> Hi,
>>>
>>> I have some problem with my rtl8187b device. It is included in my laptop
>>> running Ubuntu linux 2.6.28. I've tested several compat-wireless releases
>>> including 2.6.30 and 2.6.31-rc7.
>>
>> Hmm, are compat-wireless versioned against kernels?
>
> The stable ones are:
>
> http://wireless.kernel.org/en/users/Download/stable/
>
> Luis
>
Thanks - it is new addition to the web-site :-), I see. Anyway, Larry
and Herton have made more changes/improvements in rtl8187 in
latest-and-greatest than 2.6.31-rc7...
^ permalink raw reply
* Re: zd1211rw on ppc (iBook G4)
From: Hin-Tak Leung @ 2009-08-31 18:26 UTC (permalink / raw)
To: Leonardo H. Souza Hamada; +Cc: linux-wireless
In-Reply-To: <4A9C0ADC.6050607@ufra.edu.br>
On Mon, Aug 31, 2009 at 6:39 PM, Leonardo H. Souza
Hamada<leonardo.hamada@ufra.edu.br> wrote:
> Hin-Tak Leung wrote:
>> On Mon, Aug 31, 2009 at 5:39 PM, Leonardo H. Souza
>> Hamada<leonardo.hamada@ufra.edu.br> wrote:
>>
>>> Hi list,
>>>
>>> On linux-2.6.24-gentoo-r3, the zd1211rw driver was working as eth1.
>>>
>>> This is a big-endian machine.
>>>
>>> On 2.6.30-gentoo-r5, 'ifconfig -a' shows the relevant entries below:
>>>
>>
>>
>>> Likely is a issue similar reported previously:
>>> http://marc.info/?l=linux-wireless&m=124906700820860&w=2
>>>
>>> Quick peek at the source diffs between previous version reveals some
>>> changes.
>>>
>>
>> Are you talking about a regression - i.e. it used to work *on the same
>> architecture*, but not any more? If that's the case you can probably
>> start with 2.6.24 and various compat-wireless on to narrow down which
>> changes break. The post you referred to is different - vendor driver
>> vs rw driver.
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
>> It used to work *on the same architecture*, but not any more.
>
> This is the case.
>
>>The post you referred to is different - vendor driver vs rw driver.
>
> The post i referred to, as I interpret, is a illustrative that the
> vendor driver is working on the same hardware which the rw is not working.
>
> Thanks for the reply anyway .
>
I just had a quick look - the rw driver from 2.6.24 to 2.6.30 actually
went through the ieee80211 to mac80211 change.
('git diff v2.6.24:drivers/net/wireless/zd1211rw/
v2.6.30:drivers/net/wireless/zd1211rw/' for those who has
wireless-testing).
I have a bunch of patches which bring the 2.22 vendor driver up to
2.6.29 and 3.0 the vendor driver up to 2.6.30:
http://htl10.users.sourceforge.net/patchsets/
It doesn't fix the rw driver, but might be good enough for you? I
didn't spent any more time on the 2.22 vendor driver after 2.6.29
because 3.0 was released then. The 3.0 vendor driver can be had from:
http://www.kernel.org/pub/linux/kernel/people/mcgrof/zd1211/
It would appear that the rw driver's ieee80211->mac80211 conversion
has broken big- endian platforms, at a first guess.
( I still maintain that
http://marc.info/?l=linux-wireless&m=124906700820860&w=2 is a bit
different from your situation, since the other poster never had the rw
driver working on bigendian platforms). In any case, it might be
interesting to hear from others if recent versions of the rw driver
can be confirmed to work on bigendian platforms.
^ permalink raw reply
* Re: rtl8187b Problem with tx level
From: Luis R. Rodriguez @ 2009-08-31 18:02 UTC (permalink / raw)
To: Hin-Tak Leung; +Cc: Tobias Schlemmer, linux-wireless
In-Reply-To: <3ace41890908311055s5c49a25fjf69ca48024579d44@mail.gmail.com>
On Mon, Aug 31, 2009 at 10:55 AM, Hin-Tak Leung<hintak.leung@gmail.com> wrote:
> On Sun, Aug 30, 2009 at 9:44 PM, Tobias
> Schlemmer<keinstein_junior@gmx.net> wrote:
>> Hi,
>>
>> I have some problem with my rtl8187b device. It is included in my laptop
>> running Ubuntu linux 2.6.28. I've tested several compat-wireless releases
>> including 2.6.30 and 2.6.31-rc7.
>
> Hmm, are compat-wireless versioned against kernels?
The stable ones are:
http://wireless.kernel.org/en/users/Download/stable/
Luis
^ 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