* Re: ath9k: BUG kmalloc-8192: Poison overwritten
From: Christoph Lameter @ 2010-05-14 16:12 UTC (permalink / raw)
To: Justin P. Mattock
Cc: Luis R. Rodriguez, Pekka Enberg, linux-wireless,
Linux Kernel Mailing List
In-Reply-To: <4BECDD5D.9010609@gmail.com>
On Thu, 13 May 2010, Justin P. Mattock wrote:
> I enable these options as well..
> (then see If I can(hopefully)re-create this
> then I'll bisect it).
Debugging causes a slowdown. You can switch debuggin on for a specific
slab.
f.e.
slub_debug=,kmalloc-8192
See also Documentation/vm/slub.txt
^ permalink raw reply
* compat-wireless
From: David H. Lynch Jr. @ 2010-05-14 16:17 UTC (permalink / raw)
To: linux-wireless
I am working with the carl9170 driver.
I have a working development environment based on wireless-testing.
I am going to need to support carl9170 with older linux versions.
I pullled the compat-wireless git tree and can not figure out how
to build from it.
Is there any step by step instructions to get from the raw git
tree to being able to build against a specific kernel source ?
I DL'd the compat-wireless tarball for 2.6.32. I was able to get
that working against ubuntu lucid kernel sources.
When I add the carl9170 driver I get a large collection of errors
building it.
While some of these appear to be very specific to this
driver many seem specific to differences between 2.6.32 compat-wireless
and wireless testing. I was hoping moving to the compat-wireless git
tree would fix that, but I can not figure out how to build from it.
In an altogether different project it would be useful use
compat-wireless to support a newer wifi driver with a 2.6.27 kernel.
That seems fairly standard. But I need to cross compile the kernel. As
best as I can tell compat-wireless is setup to work against your
current running kernel. Are there any pointers for cross-compiling with
compat-wireless, or for building against source other than that for the
running kernel ?
Thanks
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.587.7774 dhlii@dlasys.net http://www.dlasys.net
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: fix dma sync in rx path
From: Felix Fietkau @ 2010-05-14 16:19 UTC (permalink / raw)
To: Ming Lei; +Cc: lrodriguez, linux-wireless, linville
In-Reply-To: <AANLkTikVkBdTopPJlU2lGkafLIkiiviUHe8J-lTy67y9@mail.gmail.com>
On 2010-05-14 5:27 PM, Ming Lei wrote:
> 2010/5/14 Felix Fietkau <nbd@openwrt.org>:
>> On 2010-05-14 3:16 PM, tom.leiming@gmail.com wrote:
>>> From: Ming Lei <tom.leiming@gmail.com>
>>>
>>> If buffer is to be accessed by cpu after dma transfer is over, but
>>> between dma mapping and dma unmapping, we should use
>>> dma_sync_single_for_cpu to sync the buffer between cpu with
>>> device. And dma_sync_single_for_device is used to let
>>> device gain the buffer again.
>> I think this patch is wrong. On most MIPS devices,
>> dma_sync_single_for_cpu is a no-op. In fact, with this patch, the rx
>> path fails very quickly.
>
> Sorry for my bad email client.
>
> On most MIPS devices, dma_sync_single_for_cpu does same things
> almost with dma_unmap_single(plat_unmap_dma_mem is no-op). If
> dma_unmap_single is enough, dma_sync_single_for_cpu is certainly
> enough,
> isn't it?
Because I did some testing with these functions while writing the code,
I already know that dma_sync_single_for_cpu is not enough in this case.
Maybe we need to place the dma_sync_single_for_device call elsewhere and
then move the dma_sync_single_for_cpu call there afterwads, but simply
replacing this instance as is done in your patch *will* cause regressions.
- Felix
^ permalink raw reply
* Re: compat-wireless
From: Luis R. Rodriguez @ 2010-05-14 16:23 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: linux-wireless
In-Reply-To: <4BED77A2.7050105@dlasys.net>
On Fri, May 14, 2010 at 9:17 AM, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
> I am working with the carl9170 driver.
> I have a working development environment based on wireless-testing.
>
> I am going to need to support carl9170 with older linux versions.
> I pullled the compat-wireless git tree and can not figure out how to
> build from it.
> Is there any step by step instructions to get from the raw git tree
> to being able to build against a specific kernel source ?
>
> I DL'd the compat-wireless tarball for 2.6.32. I was able to get that
> working against ubuntu lucid kernel sources.
> When I add the carl9170 driver I get a large collection of errors
> building it.
> While some of these appear to be very specific to this driver
> many seem specific to differences between 2.6.32 compat-wireless and
> wireless testing. I was hoping moving to the compat-wireless git tree would
> fix that, but I can not figure out how to build from it.
compat-wireless uses linux-next as a source base tree, not
wireless-testing. Maybe that will help you.
> In an altogether different project it would be useful use compat-wireless
> to support a newer wifi driver with a 2.6.27 kernel. That seems fairly
> standard. But I need to cross compile the kernel. As best as I can tell
> compat-wireless is setup to work against your current running kernel. Are
> there any pointers for cross-compiling with compat-wireless, or for building
> against source other than that for the running kernel ?
Cross compilation is covered on the wiki pages for it, you modify KLIB
KLIB_BUILD.
Luis
^ permalink raw reply
* Re: ath9k: BUG kmalloc-8192: Poison overwritten
From: Luis R. Rodriguez @ 2010-05-14 16:53 UTC (permalink / raw)
To: Justin P. Mattock
Cc: Bruno Randolf, Luis Rodriguez, linux-wireless@vger.kernel.org,
Linux Kernel Mailing List
In-Reply-To: <4BED6F19.3040608@gmail.com>
On Fri, May 14, 2010 at 08:41:13AM -0700, Justin P. Mattock wrote:
> On 05/13/10 23:38, Bruno Randolf wrote:
> > On Friday 14 May 2010 15:31:26 Justin P. Mattock wrote:
> >> On 05/13/10 23:20, Bruno Randolf wrote:
> >>> On Friday 14 May 2010 15:16:22 Luis R. Rodriguez wrote:
> >>>> On Thu, May 13, 2010 at 9:44 PM, Justin P. Mattock
> >>>>
> >>>> <justinmattock@gmail.com> wrote:
> >>>>> On 05/13/10 21:01, Luis R. Rodriguez wrote:
> >>>>>> On Thu, May 13, 2010 at 7:14 PM, Justin P. Mattock
> >>>>>>
> >>>>>> <justinmattock@gmail.com> wrote:
> >>>>>>> what I can try, is(not at the convention, on eth0
> >>>>>>> at the moment), but when I get back to the convention
> >>>>>>> center place I can try your patch as well as the
> >>>>>>> modprobe option, to see if I can get any signs of
> >>>>>>> a recreation(if so I'll bisect there).
> >>>>>>
> >>>>>> The debug info I just need upon load of the module, I don't need you
> >>>>>> to run the debug stuff to try to reproduce. The debug print upon load
> >>>>>> will tell us the rxbuf size and cache line size.
> >>>>>>
> >>>>>> Luis
> >>>>>
> >>>>> o.k. it's not pretty due
> >>>>> to loads of avc's for SELinux:
> >>>>> (I run a rootless system).
> >>>>>
> >>>>> [ 84.172649] ath9k: Driver unloaded
> >>>>> [ 100.675300] audit_printk_skb: 6 callbacks suppressed
> >>>>> [ 100.675306] type=1400 audit(1273811633.675:20): avc: denied {
> >>>>> search } for pid=2168 comm="modprobe" name="modules" dev=sda3
> >>>>> ino=2500 scontext=name:staff_r:staff_sudo_t:s0
> >>>>> tcontext=system_u:object_r:modules_object_t:s0 tclass=dir
> >>>>> [ 100.675408] type=1400 audit(1273811633.675:20): avc: denied {
> >>>>> search } for pid=2168 comm="modprobe"
> >>>>> name="2.6.34-rc7-00057-gcdfda35" dev=sda3 ino=524392
> >>>>> scontext=name:staff_r:staff_sudo_t:s0
> >>>>> tcontext=name:object_r:modules_object_t:s0 tclass=dir
> >>>>> [ 100.675552] type=1400 audit(1273811633.675:20): avc: denied { read
> >>>>> } for pid=2168 comm="modprobe" name="modules.dep.bin" dev=sda3
> >>>>> ino=525251 scontext=name:staff_r:staff_sudo_t:s0
> >>>>> tcontext=name:object_r:modules_object_t:s0 tclass=file
> >>>>> [ 100.675598] type=1400 audit(1273811633.675:20): avc: denied { open
> >>>>> } for pid=2168 comm="modprobe" name="modules.dep.bin" dev=sda3
> >>>>> ino=525251 scontext=name:staff_r:staff_sudo_t:s0
> >>>>> tcontext=name:object_r:modules_object_t:s0 tclass=file
> >>>>> [ 100.675748] type=1300 audit(1273811633.675:20): arch=c000003e
> >>>>> syscall=2 success=yes exit=3 a0=60d140 a1=0 a2=1b6 a3=0 items=0
> >>>>> ppid=2080 pid=2168 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
> >>>>> sgid=0 fsgid=0 tty=pts0 ses=1 comm="modprobe" exe="/sbin/modprobe"
> >>>>> subj=name:staff_r:staff_sudo_t:s0 key=(null)
> >>>>> [ 100.675902] type=1400 audit(1273811633.675:21): avc: denied {
> >>>>> getattr } for pid=2168 comm="modprobe"
> >>>>> path="/lib/modules/2.6.34-rc7-00057-gcdfda35/modules.dep.bin" dev=sda3
> >>>>> ino=525251 scontext=name:staff_r:staff_sudo_t:s0
> >>>>> tcontext=name:object_r:modules_object_t:s0 tclass=file
> >>>>> [ 100.676052] type=1300 audit(1273811633.675:21): arch=c000003e
> >>>>> syscall=5 success=yes exit=0 a0=3 a1=7fffd2d1dd70 a2=7fffd2d1dd70 a3=0
> >>>>> items=0 ppid=2080 pid=2168 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0
> >>>>> egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="modprobe"
> >>>>> exe="/sbin/modprobe"
> >>>>> subj=name:staff_r:staff_sudo_t:s0 key=(null)
> >>>>> [ 100.698392] ath9k 0000:03:00.0: PCI INT A -> GSI 17 (level, low) ->
> >>>>> IRQ 17
> >>>>> [ 100.698409] ath9k 0000:03:00.0: setting latency timer to 64
> >>>>> [ 100.828787] ath: EEPROM regdomain: 0x64
> >>>>> [ 100.828790] ath: EEPROM indicates we should expect a direct regpair
> >>>>> map [ 100.828793] ath: Country alpha2 being used: 00
> >>>>> [ 100.828795] ath: Regpair used: 0x64
> >>>>> [ 100.848609] type=1400 audit(1273811633.678:22): avc: denied {
> >>>>> search } for pid=2168 comm="modprobe" name="ieee80211" dev=debugfs
> >>>>> ino=18 scontext=name:staff_r:staff_sudo_t:s0
> >>>>> tcontext=system_u:object_r:debugfs_t:s0 tclass=dir
> >>>>> [ 100.848788] phy1: Selected rate control algorithm
> >>>>> 'ath9k_rate_control' [ 100.850035] Registered led device:
> >>>>> ath9k-phy1::radio
> >>>>> [ 100.850488] Registered led device: ath9k-phy1::assoc
> >>>>> [ 100.851227] Registered led device: ath9k-phy1::tx
> >>>>> [ 100.851633] Registered led device: ath9k-phy1::rx
> >>>>> [ 100.851640] phy1: Atheros AR5418 MAC/BB Rev:2 AR5133 RF Rev:81
> >>>>> mem=0xffffc900005a0000, irq=17
> >>>>> [ 100.852240] type=1300 audit(1273811633.678:22): arch=c000003e
> >>>>> syscall=175 success=yes exit=0 a0=7f1e9d6ab010 a1=19580 a2=60d920 a3=0
> >>>>> items=0 ppid=2080 pid=2168 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0
> >>>>> egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="modprobe"
> >>>>> exe="/sbin/modprobe"
> >>>>> subj=name:staff_r:staff_sudo_t:s0 key=(null)
> >>>>>
> >>>>> but there you go dmesg of the debug info for you
> >>>>
> >>>> Justin, did you forget to use the debug parameter on modprobe ath9k?
> >>>>
> >>>> modprobe ath9k debug=0x0000020
> >>>>
> >>>> I do not see the output I expected.
> >>>
> >>> i think you have to do at least "ifconfig wlan0 up" to see it - (at least
> >>> for ath5k).
> >>>
> >>> bruno
> >>
> >> didn't think todo so, I'll redu
> >> again and see. BTW: the connection
> >> over here is dodgy(hotel) should I at-least
> >> find a stable access point? i.g. convetion
> >> center seemed semi somewhat there
> >
> > no that does not matter. just ifconfig up is enough. it's just initialization,
> > you don't need a connection for that.
> >
> > bruno
> >
> >> Justin P. Mattock
> >> --
> >> 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
> >
>
>
> here you go:
> (hopefully I did this correct)
>
> [ 84.172542] ath9k 0000:03:00.0: PCI INT A disabled
> [ 84.172649] ath9k: Driver unloaded
> [ 100.675300] audit_printk_skb: 6 callbacks suppressed
> [ 100.675306] type=1400 audit(1273811633.675:20): avc: denied {
> search } for pid=2168 comm="modprobe" name="modules" dev=sda3 ino=2500
> xt=name:staff_r:staff_sudo_t:s0
> tcontext=system_u:object_r:modules_object_t:s0 tclass=dir
> [ 100.675408] type=1400 audit(1273811633.675:20): avc: denied {
> search } for pid=2168 comm="modprobe" name="2.6.34-rc7-00057-gcdfda35"
> dev=sda3 ino=524392 scontext=name:staff_r:staff_sudo_t:s0
> tcontext=name:object_r:modules_object_t:s0 tclass=dir
> [ 100.675552] type=1400 audit(1273811633.675:20): avc: denied { read
> } for pid=2168 comm="modprobe" name="modules.dep.bin" dev=sda3
> ino=525251 scontext=name:staff_r:staff_sudo_t:s0
> tcontext=name:object_r:modules_object_t:s0 tclass=file
> [ 100.675598] type=1400 audit(1273811633.675:20): avc: denied { open
> } for pid=2168 comm="modprobe" name="modules.dep.bin" dev=sda3
> ino=525251 scontext=name:staff_r:staff_sudo_t:s0
> tcontext=name:object_r:modules_object_t:s0 tclass=file
> [ 100.675748] type=1300 audit(1273811633.675:20): arch=c000003e
> syscall=2 success=yes exit=3 a0=60d140 a1=0 a2=1b6 a3=0 items=0
> ppid=2080 pid=2168 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
> sgid=0 fsgid=0 tty=pts0 ses=1 comm="modprobe" exe="/sbin/modprobe"
> subj=name:staff_r:staff_sudo_t:s0 key=(null)
> [ 100.675902] type=1400 audit(1273811633.675:21): avc: denied {
> getattr } for pid=2168 comm="modprobe"
> path="/lib/modules/2.6.34-rc7-00057-gcdfda35/modules.dep.bin" dev=sda3
> ino=525251 scontext=name:staff_r:staff_sudo_t:s0
> tcontext=name:object_r:modules_object_t:s0 tclass=file
> [ 100.676052] type=1300 audit(1273811633.675:21): arch=c000003e
> syscall=5 success=yes exit=0 a0=3 a1=7fffd2d1dd70 a2=7fffd2d1dd70 a3=0
> items=0 ppid=2080 pid=2168 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0
> egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="modprobe"
> exe="/sbin/modprobe" subj=name:staff_r:staff_sudo_t:s0 key=(null)
> [ 100.698392] ath9k 0000:03:00.0: PCI INT A -> GSI 17 (level, low) ->
> IRQ 17
> [ 100.698409] ath9k 0000:03:00.0: setting latency timer to 64
> [ 100.828787] ath: EEPROM regdomain: 0x64
> [ 100.828790] ath: EEPROM indicates we should expect a direct regpair map
> [ 100.828793] ath: Country alpha2 being used: 00
> [ 100.828795] ath: Regpair used: 0x64
>
> [ 100.848609] type=1400 audit(1273811633.678:22): avc: denied {
> search } for pid=2168 comm="modprobe" name="ieee80211" dev=debugfs
> ino=18 scontext=name:staff_r:staff_sudo_t:s0
> tcontext=system_u:object_r:debugfs_t:s0 tclass=dir
> [ 100.848788] phy1: Selected rate control algorithm 'ath9k_rate_control'
> [ 100.850035] Registered led device: ath9k-phy1::radio
> [ 100.850488] Registered led device: ath9k-phy1::assoc
> [ 100.851227] Registered led device: ath9k-phy1::tx
> [ 100.851633] Registered led device: ath9k-phy1::rx
> [ 100.851640] phy1: Atheros AR5418 MAC/BB Rev:2 AR5133 RF Rev:81
> mem=0xffffc900005a0000, irq=17
> [ 100.852240] type=1300 audit(1273811633.678:22): arch=c000003e
> syscall=175 success=yes exit=0 a0=7f1e9d6ab010 a1=19580 a2=60d920 a3=0
> items=0 ppid=2080 pid=2168 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0
> egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="modprobe"
> exe="/sbin/modprobe" subj=name:staff_r:staff_sudo_t:s0 key=(null)
>
>
> let me know if you need more info.. I'll be off the grid in
> a few, then probably wont be back on till a while
> (since I aint got's no 99 big ones for intranet!!)
Your output still did not have the stuff I was looking for, just do:
dmesg | grep cachelsz
If nothing comes up it doesn't have the output I was looking for yet.
Luis
^ permalink raw reply
* Re: ath9k: BUG kmalloc-8192: Poison overwritten
From: Justin P. Mattock @ 2010-05-14 16:54 UTC (permalink / raw)
To: Christoph Lameter
Cc: Luis R. Rodriguez, Pekka Enberg, linux-wireless,
Linux Kernel Mailing List
In-Reply-To: <alpine.DEB.2.00.1005141110100.9466@router.home>
On 05/14/10 09:12, Christoph Lameter wrote:
> On Thu, 13 May 2010, Justin P. Mattock wrote:
>
>> I enable these options as well..
>> (then see If I can(hopefully)re-create this
>> then I'll bisect it).
>
> Debugging causes a slowdown. You can switch debuggin on for a specific
> slab.
>
> f.e.
>
> slub_debug=,kmalloc-8192
>
> See also Documentation/vm/slub.txt
>
>
Cool, thanks for this.. I'll have a look
also in slub.txt as well(never really did much
debugging with slub).
Justin P. Mattock
^ permalink raw reply
* Re: ath9k: BUG kmalloc-8192: Poison overwritten
From: Justin P. Mattock @ 2010-05-14 17:24 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Bruno Randolf, Luis Rodriguez, linux-wireless@vger.kernel.org,
Linux Kernel Mailing List
In-Reply-To: <20100514165325.GA28198@tux>
On 05/14/10 09:53, Luis R. Rodriguez wrote:
> On Fri, May 14, 2010 at 08:41:13AM -0700, Justin P. Mattock wrote:
>> On 05/13/10 23:38, Bruno Randolf wrote:
>>> On Friday 14 May 2010 15:31:26 Justin P. Mattock wrote:
>>>> On 05/13/10 23:20, Bruno Randolf wrote:
>>>>> On Friday 14 May 2010 15:16:22 Luis R. Rodriguez wrote:
>>>>>> On Thu, May 13, 2010 at 9:44 PM, Justin P. Mattock
>>>>>>
>>>>>> <justinmattock@gmail.com> wrote:
>>>>>>> On 05/13/10 21:01, Luis R. Rodriguez wrote:
>>>>>>>> On Thu, May 13, 2010 at 7:14 PM, Justin P. Mattock
>>>>>>>>
>>>>>>>> <justinmattock@gmail.com> wrote:
>>>>>>>>> what I can try, is(not at the convention, on eth0
>>>>>>>>> at the moment), but when I get back to the convention
>>>>>>>>> center place I can try your patch as well as the
>>>>>>>>> modprobe option, to see if I can get any signs of
>>>>>>>>> a recreation(if so I'll bisect there).
>>>>>>>>
>>>>>>>> The debug info I just need upon load of the module, I don't need you
>>>>>>>> to run the debug stuff to try to reproduce. The debug print upon load
>>>>>>>> will tell us the rxbuf size and cache line size.
>>>>>>>>
>>>>>>>> Luis
>>>>>>>
>>>>>>> o.k. it's not pretty due
>>>>>>> to loads of avc's for SELinux:
>>>>>>> (I run a rootless system).
>>>>>>>
>>>>>>> [ 84.172649] ath9k: Driver unloaded
>>>>>>> [ 100.675300] audit_printk_skb: 6 callbacks suppressed
>>>>>>> [ 100.675306] type=1400 audit(1273811633.675:20): avc: denied {
>>>>>>> search } for pid=2168 comm="modprobe" name="modules" dev=sda3
>>>>>>> ino=2500 scontext=name:staff_r:staff_sudo_t:s0
>>>>>>> tcontext=system_u:object_r:modules_object_t:s0 tclass=dir
>>>>>>> [ 100.675408] type=1400 audit(1273811633.675:20): avc: denied {
>>>>>>> search } for pid=2168 comm="modprobe"
>>>>>>> name="2.6.34-rc7-00057-gcdfda35" dev=sda3 ino=524392
>>>>>>> scontext=name:staff_r:staff_sudo_t:s0
>>>>>>> tcontext=name:object_r:modules_object_t:s0 tclass=dir
>>>>>>> [ 100.675552] type=1400 audit(1273811633.675:20): avc: denied { read
>>>>>>> } for pid=2168 comm="modprobe" name="modules.dep.bin" dev=sda3
>>>>>>> ino=525251 scontext=name:staff_r:staff_sudo_t:s0
>>>>>>> tcontext=name:object_r:modules_object_t:s0 tclass=file
>>>>>>> [ 100.675598] type=1400 audit(1273811633.675:20): avc: denied { open
>>>>>>> } for pid=2168 comm="modprobe" name="modules.dep.bin" dev=sda3
>>>>>>> ino=525251 scontext=name:staff_r:staff_sudo_t:s0
>>>>>>> tcontext=name:object_r:modules_object_t:s0 tclass=file
>>>>>>> [ 100.675748] type=1300 audit(1273811633.675:20): arch=c000003e
>>>>>>> syscall=2 success=yes exit=3 a0=60d140 a1=0 a2=1b6 a3=0 items=0
>>>>>>> ppid=2080 pid=2168 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
>>>>>>> sgid=0 fsgid=0 tty=pts0 ses=1 comm="modprobe" exe="/sbin/modprobe"
>>>>>>> subj=name:staff_r:staff_sudo_t:s0 key=(null)
>>>>>>> [ 100.675902] type=1400 audit(1273811633.675:21): avc: denied {
>>>>>>> getattr } for pid=2168 comm="modprobe"
>>>>>>> path="/lib/modules/2.6.34-rc7-00057-gcdfda35/modules.dep.bin" dev=sda3
>>>>>>> ino=525251 scontext=name:staff_r:staff_sudo_t:s0
>>>>>>> tcontext=name:object_r:modules_object_t:s0 tclass=file
>>>>>>> [ 100.676052] type=1300 audit(1273811633.675:21): arch=c000003e
>>>>>>> syscall=5 success=yes exit=0 a0=3 a1=7fffd2d1dd70 a2=7fffd2d1dd70 a3=0
>>>>>>> items=0 ppid=2080 pid=2168 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0
>>>>>>> egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="modprobe"
>>>>>>> exe="/sbin/modprobe"
>>>>>>> subj=name:staff_r:staff_sudo_t:s0 key=(null)
>>>>>>> [ 100.698392] ath9k 0000:03:00.0: PCI INT A -> GSI 17 (level, low) ->
>>>>>>> IRQ 17
>>>>>>> [ 100.698409] ath9k 0000:03:00.0: setting latency timer to 64
>>>>>>> [ 100.828787] ath: EEPROM regdomain: 0x64
>>>>>>> [ 100.828790] ath: EEPROM indicates we should expect a direct regpair
>>>>>>> map [ 100.828793] ath: Country alpha2 being used: 00
>>>>>>> [ 100.828795] ath: Regpair used: 0x64
>>>>>>> [ 100.848609] type=1400 audit(1273811633.678:22): avc: denied {
>>>>>>> search } for pid=2168 comm="modprobe" name="ieee80211" dev=debugfs
>>>>>>> ino=18 scontext=name:staff_r:staff_sudo_t:s0
>>>>>>> tcontext=system_u:object_r:debugfs_t:s0 tclass=dir
>>>>>>> [ 100.848788] phy1: Selected rate control algorithm
>>>>>>> 'ath9k_rate_control' [ 100.850035] Registered led device:
>>>>>>> ath9k-phy1::radio
>>>>>>> [ 100.850488] Registered led device: ath9k-phy1::assoc
>>>>>>> [ 100.851227] Registered led device: ath9k-phy1::tx
>>>>>>> [ 100.851633] Registered led device: ath9k-phy1::rx
>>>>>>> [ 100.851640] phy1: Atheros AR5418 MAC/BB Rev:2 AR5133 RF Rev:81
>>>>>>> mem=0xffffc900005a0000, irq=17
>>>>>>> [ 100.852240] type=1300 audit(1273811633.678:22): arch=c000003e
>>>>>>> syscall=175 success=yes exit=0 a0=7f1e9d6ab010 a1=19580 a2=60d920 a3=0
>>>>>>> items=0 ppid=2080 pid=2168 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0
>>>>>>> egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="modprobe"
>>>>>>> exe="/sbin/modprobe"
>>>>>>> subj=name:staff_r:staff_sudo_t:s0 key=(null)
>>>>>>>
>>>>>>> but there you go dmesg of the debug info for you
>>>>>>
>>>>>> Justin, did you forget to use the debug parameter on modprobe ath9k?
>>>>>>
>>>>>> modprobe ath9k debug=0x0000020
>>>>>>
>>>>>> I do not see the output I expected.
>>>>>
>>>>> i think you have to do at least "ifconfig wlan0 up" to see it - (at least
>>>>> for ath5k).
>>>>>
>>>>> bruno
>>>>
>>>> didn't think todo so, I'll redu
>>>> again and see. BTW: the connection
>>>> over here is dodgy(hotel) should I at-least
>>>> find a stable access point? i.g. convetion
>>>> center seemed semi somewhat there
>>>
>>> no that does not matter. just ifconfig up is enough. it's just initialization,
>>> you don't need a connection for that.
>>>
>>> bruno
>>>
>>>> Justin P. Mattock
>>>> --
>>>> 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
>>>
>>
>>
>> here you go:
>> (hopefully I did this correct)
>>
>> [ 84.172542] ath9k 0000:03:00.0: PCI INT A disabled
>> [ 84.172649] ath9k: Driver unloaded
>> [ 100.675300] audit_printk_skb: 6 callbacks suppressed
>> [ 100.675306] type=1400 audit(1273811633.675:20): avc: denied {
>> search } for pid=2168 comm="modprobe" name="modules" dev=sda3 ino=2500
>> xt=name:staff_r:staff_sudo_t:s0
>> tcontext=system_u:object_r:modules_object_t:s0 tclass=dir
>> [ 100.675408] type=1400 audit(1273811633.675:20): avc: denied {
>> search } for pid=2168 comm="modprobe" name="2.6.34-rc7-00057-gcdfda35"
>> dev=sda3 ino=524392 scontext=name:staff_r:staff_sudo_t:s0
>> tcontext=name:object_r:modules_object_t:s0 tclass=dir
>> [ 100.675552] type=1400 audit(1273811633.675:20): avc: denied { read
>> } for pid=2168 comm="modprobe" name="modules.dep.bin" dev=sda3
>> ino=525251 scontext=name:staff_r:staff_sudo_t:s0
>> tcontext=name:object_r:modules_object_t:s0 tclass=file
>> [ 100.675598] type=1400 audit(1273811633.675:20): avc: denied { open
>> } for pid=2168 comm="modprobe" name="modules.dep.bin" dev=sda3
>> ino=525251 scontext=name:staff_r:staff_sudo_t:s0
>> tcontext=name:object_r:modules_object_t:s0 tclass=file
>> [ 100.675748] type=1300 audit(1273811633.675:20): arch=c000003e
>> syscall=2 success=yes exit=3 a0=60d140 a1=0 a2=1b6 a3=0 items=0
>> ppid=2080 pid=2168 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
>> sgid=0 fsgid=0 tty=pts0 ses=1 comm="modprobe" exe="/sbin/modprobe"
>> subj=name:staff_r:staff_sudo_t:s0 key=(null)
>> [ 100.675902] type=1400 audit(1273811633.675:21): avc: denied {
>> getattr } for pid=2168 comm="modprobe"
>> path="/lib/modules/2.6.34-rc7-00057-gcdfda35/modules.dep.bin" dev=sda3
>> ino=525251 scontext=name:staff_r:staff_sudo_t:s0
>> tcontext=name:object_r:modules_object_t:s0 tclass=file
>> [ 100.676052] type=1300 audit(1273811633.675:21): arch=c000003e
>> syscall=5 success=yes exit=0 a0=3 a1=7fffd2d1dd70 a2=7fffd2d1dd70 a3=0
>> items=0 ppid=2080 pid=2168 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0
>> egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="modprobe"
>> exe="/sbin/modprobe" subj=name:staff_r:staff_sudo_t:s0 key=(null)
>> [ 100.698392] ath9k 0000:03:00.0: PCI INT A -> GSI 17 (level, low) ->
>> IRQ 17
>> [ 100.698409] ath9k 0000:03:00.0: setting latency timer to 64
>> [ 100.828787] ath: EEPROM regdomain: 0x64
>> [ 100.828790] ath: EEPROM indicates we should expect a direct regpair map
>> [ 100.828793] ath: Country alpha2 being used: 00
>> [ 100.828795] ath: Regpair used: 0x64
>>
>> [ 100.848609] type=1400 audit(1273811633.678:22): avc: denied {
>> search } for pid=2168 comm="modprobe" name="ieee80211" dev=debugfs
>> ino=18 scontext=name:staff_r:staff_sudo_t:s0
>> tcontext=system_u:object_r:debugfs_t:s0 tclass=dir
>> [ 100.848788] phy1: Selected rate control algorithm 'ath9k_rate_control'
>> [ 100.850035] Registered led device: ath9k-phy1::radio
>> [ 100.850488] Registered led device: ath9k-phy1::assoc
>> [ 100.851227] Registered led device: ath9k-phy1::tx
>> [ 100.851633] Registered led device: ath9k-phy1::rx
>> [ 100.851640] phy1: Atheros AR5418 MAC/BB Rev:2 AR5133 RF Rev:81
>> mem=0xffffc900005a0000, irq=17
>> [ 100.852240] type=1300 audit(1273811633.678:22): arch=c000003e
>> syscall=175 success=yes exit=0 a0=7f1e9d6ab010 a1=19580 a2=60d920 a3=0
>> items=0 ppid=2080 pid=2168 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0
>> egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="modprobe"
>> exe="/sbin/modprobe" subj=name:staff_r:staff_sudo_t:s0 key=(null)
>>
>>
>> let me know if you need more info.. I'll be off the grid in
>> a few, then probably wont be back on till a while
>> (since I aint got's no 99 big ones for intranet!!)
>
> Your output still did not have the stuff I was looking for, just do:
>
> dmesg | grep cachelsz
>
> If nothing comes up it doesn't have the output I was looking for yet.
>
> Luis
>
here you go:
(I was grabbing the info
after rmmod and modprobe)
[ 7.034242] ATH9K: cachelsz: 256
[ 69.175348] ATH9K: cachelsz: 256
Justin P. Mattock
^ permalink raw reply
* Re: ath9k: BUG kmalloc-8192: Poison overwritten
From: Luis R. Rodriguez @ 2010-05-14 17:29 UTC (permalink / raw)
To: Justin P. Mattock
Cc: Bruno Randolf, Luis Rodriguez, linux-wireless@vger.kernel.org,
Linux Kernel Mailing List
In-Reply-To: <4BED8765.8040307@gmail.com>
On Fri, May 14, 2010 at 10:24 AM, Justin P. Mattock
<justinmattock@gmail.com> wrote:
>
> here you go:
> (I was grabbing the info
> after rmmod and modprobe)
>
> [ 7.034242] ATH9K: cachelsz: 256
> [ 69.175348] ATH9K: cachelsz: 256
Close, so I without any patches applied, and by just running modprobe as below:
modprobe ath9k debug=0x00000200
ath_print(common, ATH_DBG_CONFIG, "cachelsz %u rxbufsize %u\n",
common->cachelsz, common->rx_bufsize);
This is already in the code so just please do this:
rmmod ath9k
modprobe ath9k debug=0x00000200
dmesg | grep cachelsz
^ permalink raw reply
* Re: kernel BUG in iwl-agn-rs.c:2076, WAS: iwlagn + some accesspoint == hardlock
From: Nils Radtke @ 2010-05-14 17:45 UTC (permalink / raw)
To: reinette.chatre; +Cc: linux-kernel, linux-wireless
In-Reply-To: <1273768269.2295.1144.camel@rchatre-DESK>
Hi Reinette,
Might be of interest:
[63099.789939] eth1: associated
[63166.919257] iwlagn 0000:03:00.0: expected_tpt should have been calculated by now
[63180.322024] Hangcheck: hangcheck value past margin!
[63190.664526] iwlagn 0000:03:00.0: expected_tpt should have been calculated by now
[63193.255873] iwlagn 0000:03:00.0: expected_tpt should have been calculated by now
[63194.941768] iwlagn 0000:03:00.0: expected_tpt should have been calculated by now
[63195.099286] iwlagn 0000:03:00.0: expected_tpt should have been calculated by now
[63196.524065] iwlagn 0000:03:00.0: expected_tpt should have been calculated by now
[63197.417740] iwlagn 0000:03:00.0: expected_tpt should have been calculated by now
[63199.767526] iwlagn 0000:03:00.0: iwl_tx_agg_start on ra = 00:1a:70:aa:aa:aa tid = 0
[63205.689184] iwlagn 0000:03:00.0: iwl_tx_agg_start on ra = 00:1a:70:aa:aa:aa tid = 0
[63210.821316] iwlagn 0000:03:00.0: iwl_tx_agg_start on ra = 00:1a:70:aa:aa:aa tid = 0
[63228.178530] iwlagn 0000:03:00.0: iwl_tx_agg_start on ra = 00:1a:70:aa:aa:aa tid = 0
Happened on site B, with high throughput (280-340k/s). So, it's happening w/ both, fast
and slow conn speed.
Yes, I noticed and had a look into the compat-wireless scripts but preferred to do
it manually. Thank you for your explanation.
Cheers,
Nils
^ permalink raw reply
* [PATCH 1/2] Revert "compat-wireless: fix 07-change-default-rate-alg.patch"
From: Hauke Mehrtens @ 2010-05-14 18:20 UTC (permalink / raw)
To: lrodriguez; +Cc: linux-wireless, mcgrof, Hauke Mehrtens
This reverts commit fc4ed11ef1265b43e14bb3aa5bb4c6bd788ba65a.
In the linux-next tree there is this line
kparam_unblock_sysfs_write(ieee80211_default_rc_algo);
it was introduced 2 days ago. In wireless-text this does not exist for now.
This patch was added because it was not clear that compat-wireless is build on
linux-next.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
patches/07-change-default-rate-alg.patch | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/patches/07-change-default-rate-alg.patch b/patches/07-change-default-rate-alg.patch
index f73a4c5..f0ccbce 100644
--- a/patches/07-change-default-rate-alg.patch
+++ b/patches/07-change-default-rate-alg.patch
@@ -10,9 +10,9 @@ and define CONFIG_COMPAT_MAC80211_RC_DEFAULT on config.mk.
Through the compat autoconf we then get it also defined there
at compilation time.
---- a/net/mac80211/rate.c 2010-05-12 16:27:02.245747971 +0900
-+++ b/net/mac80211/rate.c 2010-05-12 17:00:45.855748158 +0900
-@@ -23,7 +23,7 @@
+--- a/net/mac80211/rate.c
++++ b/net/mac80211/rate.c
+@@ -23,7 +23,7 @@ struct rate_control_alg {
static LIST_HEAD(rate_ctrl_algs);
static DEFINE_MUTEX(rate_ctrl_mutex);
@@ -21,7 +21,7 @@ at compilation time.
module_param(ieee80211_default_rc_algo, charp, 0644);
MODULE_PARM_DESC(ieee80211_default_rc_algo,
"Default rate control algorithm for mac80211 to use");
-@@ -118,8 +118,8 @@
+@@ -119,8 +119,8 @@ ieee80211_rate_control_ops_get(const cha
ops = ieee80211_try_rate_control_ops_get(ieee80211_default_rc_algo);
/* try built-in one if specific alg requested but not found */
@@ -29,6 +29,6 @@ at compilation time.
- ops = ieee80211_try_rate_control_ops_get(CONFIG_MAC80211_RC_DEFAULT);
+ if (!ops && strlen(CONFIG_COMPAT_MAC80211_RC_DEFAULT))
+ ops = ieee80211_try_rate_control_ops_get(CONFIG_COMPAT_MAC80211_RC_DEFAULT);
+ kparam_unblock_sysfs_write(ieee80211_default_rc_algo);
return ops;
- }
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/2] compat-wireless: Update Readme to reflect changes
From: Hauke Mehrtens @ 2010-05-14 18:20 UTC (permalink / raw)
To: lrodriguez; +Cc: linux-wireless, mcgrof, Hauke Mehrtens
In-Reply-To: <1273861216-12195-1-git-send-email-hauke@hauke-m.de>
* A description of the differences of the stable and the normal version
of compat wireless was added.
* Some outdated parts are now up to date
* replaceing the developing section with version in the wiki
These changes are needed because some people are tiring to build their
own compat-wireless version based on wireless-testing and some people
choose compat-wireless stable based on their currently running kernel
version.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
README | 181 ++++++++++++++++++++++++++++++++++++++++++++++++++++------------
1 files changed, 147 insertions(+), 34 deletions(-)
diff --git a/README b/README
index 88b16b4..62986e8 100644
--- a/README
+++ b/README
@@ -8,11 +8,6 @@ It is technically possible to support kernels < 2.6.25 but more
work is required for that.
It also provides Linux bluetooth subsystem enhancements for kernels 2.6.27 and above.
-If you'd like to keep the wireless-testing git repository local as well,
-please read out git-guide which explains how to achieve this:
-
-http://wireless.kernel.org/en/developers/git-guide
-
With a local git repository you can update the compatibility package yourself.
For more information on how to do this please refer the Developers section below.
@@ -30,13 +25,30 @@ Subscribe to the wiki page to get updates on the documentation.
Where to get the latest
-----------------------
-This package lets you build your own 'latest', all you need is a local git repository
-checkout of wireless-testing.git. However since not many users are expected to keep
-a local git repository of wireless-testing we provide daily snapshots of this
-package + the wireless subsystem code. You can find the latest snapshot at:
+This package lets you build your own 'latest', all you need is a local git
+repository. This way is documented in the Developers section of this document.
+However since not many users are expected to keep a local git repository we
+provide daily snapshots of this package + the wireless and bluetooth subsystem
+code. You can find the latest snapshot at:
+linux-next.git version:
http://wireless.kernel.org/en/users/Download
+stable version:
+http://wireless.kernel.org/en/users/Download/stable/
+
+Versions
+--------
+
+There are two different versions of this package available.
+ * Version based on latest linux-next.git tree named compat-wireless-YYYY-MM-DD.tar.bz2
+ * Version based on linux-2.6-stable.git tree named compat-wireless-2.6.CC.DD.tar.bz2
+
+Both versions should work for every kernel > 2.6.25. The differences are the
+code they are containing. The version based on linux-next.git contains the
+wireless and bluetooth subsystem out of linux-next.git and the stable version
+the wireless subsystem out of the corresponding linux stable version.
+
Selecting your driver
---------------------
@@ -72,7 +84,7 @@ Load:
Reboot unless you know what you are doing.
-Bluetooth modules can be seperately compiled and installed using below commands
+Bluetooth modules can be separately compiled and installed using below commands
Build:
make bt
@@ -130,7 +142,7 @@ Non-wireless drivers
--------------------
To support b43 ssb is also provided, and since ssb is also provided
-we provide b44 (the ethernet driverl).
+we provide b44 (the ethernet driver).
The new rfkill drivers also provided and backported.
@@ -156,7 +168,7 @@ Why?
For users or developers stuck on older kernels that want to help test or
patch wireless work. Additionally if you're on a recent kernel this lets
-you get the latest and greatest wireless-testing git work without much effort.
+you get the latest and greatest linux-next git work without much effort.
This may mean new drivers for some users. Last but not least we hope this
will encourage vendors and developers to post patches upstream first
rather than forking or maintaining their own mac80211 releases with
@@ -197,7 +209,7 @@ Here you see the list of changes to all wireless drivers, the wireless core and
http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=log;
-This views all the changes on the 'everything' branch of wireless-testing.git.
+This views all the changes on wireless-testing.git.
License
-------
@@ -211,38 +223,139 @@ Developers
----------
Compatibility work goes into compat/compat.[ch]. If using those files do
-not suffice additional actual code changes can go into compat/compat.diff.
+not suffice additional actual code changes can go into patches/*.patch.
-If you have your own wireless-testing git tree, before running admin-update.sh
-be sure to set your GIT_TREE variable. For example:
+An extended and more up to date version can be found at:
-export GIT_TREE=/home/mcgrof/wireless-testing/
+http://wireless.kernel.org/en/users/Download/hacking
-scripts/admin-clean.sh - Cleans the compat-wireless-2.6 tree
-scripts/admin-update.sh - Updates compat-wireless-2.6 with your git tree
-scripts/admin-refresh.sh - Does the above two
+This section deals with development details of compat-wireless and the other
+trees it uses. If you want to make your own compat-wireless tarballs, or if you
+see something busted with compat-wireless or just want to add something new or
+an enhancement this is the guide for you.
-TODO
-----
+Git trees you will need
+-----------------------
-* Compatibilty work for 2.6.18 --> 2.6.21
+compat-wireless backports both the bluetooth and 802.11 subsystems down to older
+kernels. To be able to synchronize backporting the latest and greatest the
+linux-next.git tree is used as its main source for kernel updates. General Linux
+kernel compatibility is addressed through a general kernel compatibility tree,
+compat.git. compat-wireless then has its own tree for specific wireless
+compatibility. You will then need to checkout three trees to start hacking on
+compat-wireless:
-Patches for compatibility work
-------------------------------
+git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
+git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/compat.git
+git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/compat-wireless-2.6.git
-Please send patches against:
+Linux next
+----------
-git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/compat-wireless-2.6.git
+The linux-next.git tree brings all subsystems being worked on for the next
+kernel release into one tree. So if the current rc kernel is 2.6.33-rc5, this
+means linux-next will have what people today are working on for the 2.6.34
+kernel release.
+
+compat.git
+----------
+
+The compat git tree is a general kernel compatibility layer which can be shared
+amongst different compatibility projects, or drivers. compat-wireless is just
+one of the kernel compatibility projects using compat.git. compat.git builds a
+general compatibility module, compat, and any additional modules to let you get
+new general kernel updates from future kernels on your old kernels.
-To: Luis R. Rodriguez <mcgrof@winlab.rutgers.edu>
-CC: linux-wireless@vger.kernel.org
-Subject: [PATCH] compat-2.6: backport foo
+compat.git modules
+------------------
-Patches for drivers
+compat.git provides a few modules and headers to help with general kernel
+compatibility.
+
+compat
+------
+
+Provides all exported symbols implemented in each respective kernel
+compat-2.6.xy.c files. Upon module load it just initializes the Linux kernel's
+''power management Quality Of Service'' (aka '''pm-qos''') Interface interface
+added as of the 2.6.24 kernel. No other things are initialized, the rest of the
+compat module just acts as a library of exported symbols.
+
+compat_firmware_class
+---------------------
+
+Another module which compat.git provides is a backport of the firmware_class
+module which got updated recently newer with a new request_firmware_nowait()
+to allow better asynchronous firmware uploading. This was added as of the 2.6.33
+kernel. The firmware_class module has been backported into a new module called
+compat_firmware_class. A separate module has been defined instead of a direct
+replacement for firmware_class since your system may have old drivers which use
+the old request_firmware_nowait() and would bust if they used the new
+request_firmware_nowait(). The compat_firmware_class module registers its own
+sysfs subsystem and as such also gets udev events sent through a separate
+subsystem. Because of this a new udev rules file is required and provided.
+
+compat-wireless.git
-------------------
-If you'd like to send patches for a driver though you can send it using our
-Submitting Patches guideline:
+Anything that is not general kernel compatibility but instead specific to 802.11
+or bluetooth goes into compat-wireless.git. After you've cloned all three trees,
+linux-next.git, compat.git and compat-wireless.git you need to change into the
+compat-wireless directory and tell compat-wireless where you linux-next and
+compat.git trees are. You do this with environment variables GIT_TREE and
+GIT_COMPAT_TREE. You can do for example:
+
+export GIT_TREE=/home/user/wireless-testing/
+export GIT_COMPAT_TREE=/home/users/compat.git/
+
+Then you can update your local sources based on these linux-next.git and
+compat.git trees:
+
+scripts/admin-clean.sh - Cleans the compat-wireless-2.6 tree
+scripts/admin-update.sh - Updates compat-wireless-2.6 with your git tree
+scripts/admin-refresh.sh - Does the above two
+
+Adding new drivers
+------------------
+
+Most new drivers are enabled for compilation. If see a driver you would like
+enabled try it into the mix, test them and if they work enable them and send
+the respective patches.
+
+Sending patches
+---------------
+
+Remember there are three trees. linux-next itself is a conglomeration of kernel
+git trees itself, so patches for linux-next.git should be sent to each
+respective subsystem for which the patches are targeted for. So for example for
+802.11 you will want to send them to John Linville and cc linux-wireless, for
+further guidelines on this see the Submitting Patches guidelines for 802.11.
+http://wireless.kernel.org/en/developers/Documentation/SubmittingPatches
+As another example, for bluetooth you will want to send them to Marcel
+Holtmann and cc the linux-bluetooth mailing list. If your patch touches on
+others areas of the kernel refer to the MAINTAINERS file on the kernel.
+
+For compat.git and compat-wireless.git please send patches against to:
-http://wireless.kernel.org/en/developers/SubmittingPatches
+To: Luis R. Rodriguez <mcgrof@kernel.org>
+CC: linux-wireless@vger.kernel.org, linux-bluetooth@vger.kernel.org
+Subject: [PATCH] compat-2.6: fix foo
+
+For patches for compat.git please use a subject like the following:
+
+Subject: [PATCH] compat: fix foo
+
+For compat-wireless.git please use a subject like the following:
+
+Subject: [PATCH] compat-wireless: fix foo
+
+Patches are preferred sent with a clear commit log entry, if unfamiliar with
+how to send patches please refer to
+http://wireless.kernel.org/en/developers/Documentation/git-guide.
+
+
+TODO
+-----
+ * Dialog (make menuconfig) option for this package
+ * Compatibility work for 2.6.18 --> 2.6.25
--
1.7.0.4
^ permalink raw reply related
* Re: ath9k: BUG kmalloc-8192: Poison overwritten
From: Justin P. Mattock @ 2010-05-14 19:04 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Bruno Randolf, Luis Rodriguez, linux-wireless@vger.kernel.org,
Linux Kernel Mailing List
In-Reply-To: <AANLkTiky103uOz38yZPlLypEQ8DnkdCk1X3zPl9014Yi@mail.gmail.com>
On May 14, 2010, at 10:29 AM, "Luis R. Rodriguez" <lrodriguez@atheros.com
> wrote:
> On Fri, May 14, 2010 at 10:24 AM, Justin P. Mattock
> <justinmattock@gmail.com> wrote:
>
>>
>> here you go:
>> (I was grabbing the info
>> after rmmod and modprobe)
>>
>> [ 7.034242] ATH9K: cachelsz: 256
>> [ 69.175348] ATH9K: cachelsz: 256
>
> Close, so I without any patches applied, and by just running
> modprobe as below:
>
>
> modprobe ath9k debug=0x00000200
>
> ath_print(common, ATH_DBG_CONFIG, "cachelsz %u
> rxbufsize %u\n",
> common->cachelsz, common->rx_bufsize);
>
>
> This is already in the code so just please do this:
>
> rmmod ath9k
> modprobe ath9k debug=0x00000200
> dmesg | grep cachelsz
O.k. I did a git reset to the origin
Then the above, unfortunantly nothing
Shows up when grepping
Any CONFIG options I might be missing?
Justin P. Mattock
^ permalink raw reply
* Re: RTL 8187b - naughty behaviour
From: seno @ 2010-05-14 20:12 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <4BE30879.4020008@lwfinger.net>
Larry Finger <Larry.Finger@...> writes:
> I do not understand the poor performance. I have a device with the
> rtl8187b chip - USB IDs 0bda:8187. That is an ID for an rtl8187, but it
> does have the B chip. I use tcpperf to measure the transmit speed. At 2
> m from the AP with an indicated signal of -17 dBm, my throughput is 13
> Mb/s. At 10 m with a signal of -49 dBm, the transmit speed is 3.5 Mb/s.
> On the download using speedtest.net, I got 11.3 Mb/s at 2 m, and 2.64 at
> 10 m. I got 0.49 Mb/s upload at both distances as that is the speed of
> my line.
>
> What happens if you use iwconfig to force a particular rate? At what
> setting is your throughput maximized. I don't think there is a problem
> with the rate setting mechanism, but that would test it.
>
> Larry
Hello,
it turns out that terms 'poor' or 'slow' performance on 8187b chipsets need to
be discussed more in detail.
If I would have never had a faster network, I would possibly not notice those
performance downturns.
I did some test on my notebook, once with mandriva 2010.0 and once with win 7.
The results:
windows:
@ 2 meters distance
rate : 54M
dBm : -46
speedtest: 9.9/0.98 Mbit/s (down/up)
DL file*: ~2.5 MByte/s
@ 10 meters distance
rate : 54M
dBm : -64
speedtest: 9.9/0.97 Mbit/s (down/up)
DL file*: ~1.25 MByte/s
linux:
@ 2 meters distance
rate : 36M
dBm : -30
speedtest: 9.9/1.00 Mbit/s (down/up)
DL file*: ~1.5 MByte/s
tcpperf output: 11769623 b/s (11769.62 kb/s 11.77 Mbit/s)
@ 10 meters distance
rate : 18M
dBm : -45
speedtest: 1.2/0.85 Mbit/s (down/up)
Dl file*: ~130 KByte/s (<---!!)
tcpperf output: 3663403 b/s (3663.40 kb/s 3.66 Mbit/s)
Dl file* = copy large file from a machine which is connected via 100mbit
ethernet to the router.
I did all tests several times to make sure to not report some random results.
Before I used pid algorithm as someone described above, but could not notice
any difference in network behavior.
If rate is set to auto, it _sometimes_ (~ twice a day) happens that connection
is up and iwconfig shows a rate of 24M, but I can not even ping the router.
Same happens if I set a fixed rate of 36 or 18, but it happens more often
(every 15 min) that the connection is up but no traffic is possible at all.
A fixed rate of 5.5M gives the most stable connection although the wireless
speed is as slow @ 10 meters with auto rate (130 KByte/s is FAR from 5.5M)
The rate settings apply to 10 meters distance, which is my typical situation
here at home.
On another PC with zw1211 wireless I set rate to 54M some time ago and there
the trick did it, connection is perfect and very fast.
^ permalink raw reply
* Re: ath9k: BUG kmalloc-8192: Poison overwritten
From: Luis R. Rodriguez @ 2010-05-14 20:13 UTC (permalink / raw)
To: Justin P. Mattock
Cc: Luis Rodriguez, Bruno Randolf, linux-wireless@vger.kernel.org,
Linux Kernel Mailing List
In-Reply-To: <67773379-350A-42D4-BEB5-DAC7D8277615@gmail.com>
On Fri, May 14, 2010 at 12:04:15PM -0700, Justin P. Mattock wrote:
>
>
> On May 14, 2010, at 10:29 AM, "Luis R. Rodriguez" <lrodriguez@atheros.com
> > wrote:
>
> > On Fri, May 14, 2010 at 10:24 AM, Justin P. Mattock
> > <justinmattock@gmail.com> wrote:
> >
> >>
> >> here you go:
> >> (I was grabbing the info
> >> after rmmod and modprobe)
> >>
> >> [ 7.034242] ATH9K: cachelsz: 256
> >> [ 69.175348] ATH9K: cachelsz: 256
> >
> > Close, so I without any patches applied, and by just running
> > modprobe as below:
> >
> >
> > modprobe ath9k debug=0x00000200
> >
> > ath_print(common, ATH_DBG_CONFIG, "cachelsz %u
> > rxbufsize %u\n",
> > common->cachelsz, common->rx_bufsize);
> >
> >
> > This is already in the code so just please do this:
> >
> > rmmod ath9k
> > modprobe ath9k debug=0x00000200
> > dmesg | grep cachelsz
>
> O.k. I did a git reset to the origin
> Then the above, unfortunantly nothing
> Shows up when grepping
> Any CONFIG options I might be missing?
CONFIG_ATH_DEBUG
Luis
^ permalink raw reply
* Re: [PATCH 2/2] compat-wireless: Update Readme to reflect changes
From: Luis R. Rodriguez @ 2010-05-14 20:18 UTC (permalink / raw)
To: Hauke Mehrtens; +Cc: linux-wireless, mcgrof
In-Reply-To: <1273861216-12195-2-git-send-email-hauke@hauke-m.de>
On Fri, May 14, 2010 at 11:20 AM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
> * A description of the differences of the stable and the normal version
> of compat wireless was added.
> * Some outdated parts are now up to date
> * replaceing the developing section with version in the wiki
>
> These changes are needed because some people are tiring to build their
> own compat-wireless version based on wireless-testing and some people
> choose compat-wireless stable based on their currently running kernel
> version.
>
> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
> ---
Thanks, both patches have been applied and pushed out.
Luis
^ permalink raw reply
* Re: RTL 8187b - naughty behaviour
From: seno @ 2010-05-14 20:20 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <4BE30879.4020008@lwfinger.net>
Larry, do you think there is some improvement possible with the driver from
here?
http://ubuntuforums.org/showthread.php?t=1446894
(rtl8187B_linux_26.1056.1112.2009.release.tar.gz )
This seems to be the latest realtek driver.
I downloaded, compiled and installed, but driver did not load correct, loads of
errors in dmesg (I'm not a linux pro, sorry)
^ permalink raw reply
* Re: ath9k: BUG kmalloc-8192: Poison overwritten
From: Justin P. Mattock @ 2010-05-14 20:21 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Luis Rodriguez, Bruno Randolf, linux-wireless@vger.kernel.org,
Linux Kernel Mailing List
In-Reply-To: <20100514201339.GB28198@tux>
Justin P. Mattock
On May 14, 2010, at 1:13 PM, "Luis R. Rodriguez"
<lrodriguez@atheros.com> wrote:
> On Fri, May 14, 2010 at 12:04:15PM -0700, Justin P. Mattock wrote:
>>
>>
>> On May 14, 2010, at 10:29 AM, "Luis R. Rodriguez" <lrodriguez@atheros.com
>>> wrote:
>>
>>> On Fri, May 14, 2010 at 10:24 AM, Justin P. Mattock
>>> <justinmattock@gmail.com> wrote:
>>>
>>>>
>>>> here you go:
>>>> (I was grabbing the info
>>>> after rmmod and modprobe)
>>>>
>>>> [ 7.034242] ATH9K: cachelsz: 256
>>>> [ 69.175348] ATH9K: cachelsz: 256
>>>
>>> Close, so I without any patches applied, and by just running
>>> modprobe as below:
>>>
>>>
>>> modprobe ath9k debug=0x00000200
>>>
>>> ath_print(common, ATH_DBG_CONFIG, "cachelsz %u
>>> rxbufsize %u\n",
>>> common->cachelsz, common->rx_bufsize);
>>>
>>>
>>> This is already in the code so just please do this:
>>>
>>> rmmod ath9k
>>> modprobe ath9k debug=0x00000200
>>> dmesg | grep cachelsz
>>
>> O.k. I did a git reset to the origin
>> Then the above, unfortunantly nothing
>> Shows up when grepping
>> Any CONFIG options I might be missing?
>
> CONFIG_ATH_DEBUG
>
> Luis
Eveything is on except ath5k
For debugging.
^ permalink raw reply
* Re: ath9k: BUG kmalloc-8192: Poison overwritten
From: Luis R. Rodriguez @ 2010-05-14 20:52 UTC (permalink / raw)
To: Justin P. Mattock
Cc: Luis Rodriguez, Bruno Randolf, linux-wireless@vger.kernel.org,
Linux Kernel Mailing List
In-Reply-To: <4638F7CF-1E00-411F-A086-BA30809E00BD@gmail.com>
On Fri, May 14, 2010 at 01:21:34PM -0700, Justin P. Mattock wrote:
> Eveything is on except ath5k
> For debugging.
Bleh, try this.
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 1ca42e5..3404198 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -129,7 +129,7 @@ int ath_rx_init(struct ath_softc *sc, int nbufs)
common->rx_bufsize = roundup(IEEE80211_MAX_MPDU_LEN,
min(common->cachelsz, (u16)64));
- ath_print(common, ATH_DBG_CONFIG, "cachelsz %u rxbufsize %u\n",
+ printk("ATH9K: cachelsz %u rxbufsize %u\n",
common->cachelsz, common->rx_bufsize);
/* Initialize rx descriptors */
Not sure why this is not printing, the common debug_mask should
already be set here prior to this. Anyway this would force the
print I want.
Luis
^ permalink raw reply related
* Re: ath9k: BUG kmalloc-8192: Poison overwritten
From: Justin P. Mattock @ 2010-05-14 20:58 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Luis Rodriguez, Bruno Randolf, linux-wireless@vger.kernel.org,
Linux Kernel Mailing List
In-Reply-To: <20100514205253.GC28198@tux>
Justin P. Mattock
On May 14, 2010, at 1:52 PM, "Luis R. Rodriguez"
<lrodriguez@atheros.com> wrote:
> On Fri, May 14, 2010 at 01:21:34PM -0700, Justin P. Mattock wrote:
>> Eveything is on except ath5k
>> For debugging.
>
> Bleh, try this.
>
> diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/
> wireless/ath/ath9k/recv.c
> index 1ca42e5..3404198 100644
> --- a/drivers/net/wireless/ath/ath9k/recv.c
> +++ b/drivers/net/wireless/ath/ath9k/recv.c
> @@ -129,7 +129,7 @@ int ath_rx_init(struct ath_softc *sc, int nbufs)
> common->rx_bufsize = roundup(IEEE80211_MAX_MPDU_LEN,
> min(common->cachelsz, (u16)64));
>
> - ath_print(common, ATH_DBG_CONFIG, "cachelsz %u rxbufsize %u\n",
> + printk("ATH9K: cachelsz %u rxbufsize %u\n",
> common->cachelsz, common->rx_bufsize);
>
> /* Initialize rx descriptors */
>
> Not sure why this is not printing, the common debug_mask should
> already be set here prior to this. Anyway this would force the
> print I want.
>
> Luis
Alright I'll try that
(Off topic kmemcheck seems to be
Lost with x86_64(wanted to try as many debug option as possible))
Anyways I'll throw in the print and see.
^ permalink raw reply
* Re: [PATCH] ath5k: consistently use rx_bufsize for RX DMA
From: Bruno Randolf @ 2010-05-14 22:05 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linville, linux-wireless, bob, ath5k-devel
In-Reply-To: <AANLkTik2XPwhtUkDo7gfJTVI401HG6qU_mYvGmKfEbG5@mail.gmail.com>
On Saturday 15 May 2010 01:04:34 Luis R. Rodriguez wrote:
> On Fri, May 14, 2010 at 12:50 AM, Bruno Randolf <br1@einfach.org> wrote:
> > We should use the same buffer size we set up for DMA also in the hardware
> > descriptor. Previously we used common->rx_bufsize for setting up the DMA
> > mapping, but skb_tailroom(skb) for the size we tell to the hardware in
> > the descriptor itself. The problem is that skb_tailroom(skb) can give us
> > a larger value than the size we set up for DMA before: In my case
> > rx_bufsize is 2528, and we allocated an skb of 2559 bytes length,
> > including padding for cache alignment, but sbk_tailroom() was 2592. Just
> > consistently use rx_bufsize for all RX DMA memory sizes.
> >
> > Also check the return value of setup function.
> >
> > Signed-off-by: Bruno Randolf <br1@einfach.org>
>
> Cc: stable?
might be useful. i just would like some review before that.
> Is that other bug reproducible, can the user test this to cure it?
not sure. seems like he can with running kismet for a few hours (i'm doing the
same over the weekend). i doubt that this is "the" bug though... a) because
the bug on ath5k and ath9k are so similar and b) because we see the beginning
of packets. rather looks like the next pointer of the descriptor is pointing
to somewhere it shouldnt, sometimes? (guessing)
bruno
^ permalink raw reply
* Re: ath9k: BUG kmalloc-8192: Poison overwritten
From: Justin P. Mattock @ 2010-05-14 22:32 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Luis Rodriguez, Bruno Randolf, linux-wireless@vger.kernel.org,
Linux Kernel Mailing List
In-Reply-To: <20100514205253.GC28198@tux>
On May 14, 2010, at 1:52 PM, "Luis R. Rodriguez"
<lrodriguez@atheros.com> wrote:
> On Fri, May 14, 2010 at 01:21:34PM -0700, Justin P. Mattock wrote:
>> Eveything is on except ath5k
>> For debugging.
>
> Bleh, try this.
>
> diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/
> wireless/ath/ath9k/recv.c
> index 1ca42e5..3404198 100644
> --- a/drivers/net/wireless/ath/ath9k/recv.c
> +++ b/drivers/net/wireless/ath/ath9k/recv.c
> @@ -129,7 +129,7 @@ int ath_rx_init(struct ath_softc *sc, int nbufs)
> common->rx_bufsize = roundup(IEEE80211_MAX_MPDU_LEN,
> min(common->cachelsz, (u16)64));
>
> - ath_print(common, ATH_DBG_CONFIG, "cachelsz %u rxbufsize %u\n",
> + printk("ATH9K: cachelsz %u rxbufsize %u\n",
> common->cachelsz, common->rx_bufsize);
>
> /* Initialize rx descriptors */
>
> Not sure why this is not printing, the common debug_mask should
> already be set here prior to this. Anyway this would force the
> print I want.
>
> Luis
O.k appologize for the delay
(had to play limo driver),
Anyways here is the grep info:
ATH9K: cachelsz 256 rxbufsize 3904
(messg is the same before and after
Rrmod/modprobing with debug options)
Justin P. Mattock
^ permalink raw reply
* [PATCH 1/2] wireless: rtl818x: rtl8180: add ids
From: Xose Vazquez Perez @ 2010-05-14 23:44 UTC (permalink / raw)
To: linux-wireless; +Cc: linville, herton, htl10, Larry.Finger, Xose Vazquez Perez
taken from windows inf file
Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
---
drivers/net/wireless/rtl818x/rtl8180_dev.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/rtl818x/rtl8180_dev.c b/drivers/net/wireless/rtl818x/rtl8180_dev.c
index 4801589..6d6140d 100644
--- a/drivers/net/wireless/rtl818x/rtl8180_dev.c
+++ b/drivers/net/wireless/rtl818x/rtl8180_dev.c
@@ -36,6 +36,7 @@ MODULE_LICENSE("GPL");
static DEFINE_PCI_DEVICE_TABLE(rtl8180_table) = {
/* rtl8185 */
+ { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8184) },
{ PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8185) },
{ PCI_DEVICE(PCI_VENDOR_ID_BELKIN, 0x700f) },
{ PCI_DEVICE(PCI_VENDOR_ID_BELKIN, 0x701f) },
@@ -45,6 +46,8 @@ static DEFINE_PCI_DEVICE_TABLE(rtl8180_table) = {
{ PCI_DEVICE(0x1799, 0x6001) },
{ PCI_DEVICE(0x1799, 0x6020) },
{ PCI_DEVICE(PCI_VENDOR_ID_DLINK, 0x3300) },
+ { PCI_DEVICE(PCI_VENDOR_ID_DLINK, 0x3301) },
+ { PCI_DEVICE(0x1432, 0x7106) },
{ }
};
--
1.6.6.1
^ permalink raw reply related
* [PATCH 2/2] wireless: rtl818x: rtl8187 add ids
From: Xose Vazquez Perez @ 2010-05-14 23:44 UTC (permalink / raw)
To: linux-wireless; +Cc: linville, herton, htl10, Larry.Finger, Xose Vazquez Perez
In-Reply-To: <1273880660-11072-1-git-send-email-xose.vazquez@gmail.com>
taken from windows inf file
Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
---
drivers/net/wireless/rtl818x/rtl8187_dev.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/rtl818x/rtl8187_dev.c b/drivers/net/wireless/rtl818x/rtl8187_dev.c
index b332c1e..f641bde 100644
--- a/drivers/net/wireless/rtl818x/rtl8187_dev.c
+++ b/drivers/net/wireless/rtl818x/rtl8187_dev.c
@@ -53,6 +53,7 @@ static struct usb_device_id rtl8187_table[] __devinitdata = {
{USB_DEVICE(0x0bda, 0x8189), .driver_info = DEVICE_RTL8187B},
{USB_DEVICE(0x0bda, 0x8197), .driver_info = DEVICE_RTL8187B},
{USB_DEVICE(0x0bda, 0x8198), .driver_info = DEVICE_RTL8187B},
+ {USB_DEVICE(0x0bda, 0x8199), .driver_info = DEVICE_RTL8187B},
/* Surecom */
{USB_DEVICE(0x0769, 0x11F2), .driver_info = DEVICE_RTL8187},
/* Logitech */
@@ -79,6 +80,10 @@ static struct usb_device_id rtl8187_table[] __devinitdata = {
{USB_DEVICE(0x1b75, 0x8187), .driver_info = DEVICE_RTL8187},
/* Linksys */
{USB_DEVICE(0x1737, 0x0073), .driver_info = DEVICE_RTL8187B},
+ /* Trust */
+ {USB_DEVICE(0x145f, 0x0161), .driver_info = DEVICE_RTL8187},
+ /* Edimax */
+ {USB_DEVICE(0x7392, 0x7612), .driver_info = DEVICE_RTL8187},
{}
};
--
1.6.6.1
^ permalink raw reply related
* Re: [PATCH 1/2] wireless: rtl818x: rtl8180: add ids
From: Hin-Tak Leung @ 2010-05-14 23:49 UTC (permalink / raw)
To: linux-wireless, Xose Vazquez Perez; +Cc: linville, herton, Larry.Finger
--- On Sat, 15/5/10, Xose Vazquez Perez <xose.vazquez@gmail.com> wrote:
> taken from windows inf file
>
> Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
Acked-by: Hin-Tak Leung <htl10@users.sourceforge.net>
You added 3 device ids - do you own one of them by any chance? We like to know who has what hardware sometimes - just in case they are slightly different.
Hin-Tak
^ permalink raw reply
* Re: [PATCH] ath5k: consistently use rx_bufsize for RX DMA
From: Luis R. Rodriguez @ 2010-05-15 0:34 UTC (permalink / raw)
To: Bruno Randolf
Cc: Luis Rodriguez, linville@tuxdriver.com,
linux-wireless@vger.kernel.org, bob@bobcopeland.com,
ath5k-devel@lists.ath5k.org
In-Reply-To: <201005150705.22887.br1@einfach.org>
On Fri, May 14, 2010 at 03:05:22PM -0700, Bruno Randolf wrote:
> On Saturday 15 May 2010 01:04:34 Luis R. Rodriguez wrote:
> > On Fri, May 14, 2010 at 12:50 AM, Bruno Randolf <br1@einfach.org> wrote:
> > > We should use the same buffer size we set up for DMA also in the hardware
> > > descriptor. Previously we used common->rx_bufsize for setting up the DMA
> > > mapping, but skb_tailroom(skb) for the size we tell to the hardware in
> > > the descriptor itself. The problem is that skb_tailroom(skb) can give us
> > > a larger value than the size we set up for DMA before: In my case
> > > rx_bufsize is 2528, and we allocated an skb of 2559 bytes length,
> > > including padding for cache alignment, but sbk_tailroom() was 2592. Just
> > > consistently use rx_bufsize for all RX DMA memory sizes.
> > >
> > > Also check the return value of setup function.
> > >
> > > Signed-off-by: Bruno Randolf <br1@einfach.org>
> >
> > Cc: stable?
>
> might be useful. i just would like some review before that.
FWIW
Reviewed-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> > Is that other bug reproducible, can the user test this to cure it?
>
> not sure. seems like he can with running kismet for a few hours (i'm doing the
> same over the weekend). i doubt that this is "the" bug though...
Oh I'm not assuming it is, but it still looks like a valid stable bug fix to me.
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