* BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0
From: Justin Mattock @ 2010-06-22 23:16 UTC (permalink / raw)
To: linux-wireless; +Cc: Linux Kernel Mailing List
I remember ipsec was able to work cleanly on my machines probably
about 4/6 months ago
now I get this:
[ 302.071077] BUG: unable to handle kernel NULL pointer dereference
at 00000000000000a0
[ 302.071084] IP: [<ffffffff81387e0b>] xfrm_bundle_ok+0x14f/0x2e9
[ 302.071094] PGD 13e695067 PUD 139c7e067 PMD 0
[ 302.071100] Oops: 0000 [#1] SMP
[ 302.071104] last sysfs file:
/sys/devices/pci0000:00/0000:00:15.0/0000:04:00.0/net/eth1/statistics/tx_bytes
[ 302.071109] CPU 0
[ 302.071111] Modules linked in: xfrm4_mode_transport sco xcbc bnep
rmd160 sha512_generic xt_tcpudp ipt_LOG iptable_nat nf_nat xt_state
nf_conntrack_ftp nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4
iptable_filter ip_tables x_tables firewire_ohci firewire_core evdev
lib80211_crypt_tkip uvcvideo videodev ohci1394 v4l1_compat button
thermal wl(P) nvidia(P) ohci_hcd forcedeth i2c_nforce2 aes_x86_64 lzo
lzo_compress ipcomp xfrm_ipcomp crypto_null sha256_generic cbc
des_generic cast5 blowfish serpent camellia twofish twofish_common ctr
ah4 esp4 authenc adm1021 raw1394 ieee1394 uhci_hcd ehci_hcd hci_uart
rfcomm btusb hidp l2cap bluetooth coretemp acpi_cpufreq processor
mperf appletouch applesmc
[ 302.071185]
[ 302.071189] Pid: 2603, comm: vncviewer Tainted: P
2.6.35-rc2-00001-g8dd40f7 #3 Mac-F2218FC8/iMac9,1
[ 302.071193] RIP: 0010:[<ffffffff81387e0b>] [<ffffffff81387e0b>]
xfrm_bundle_ok+0x14f/0x2e9
[ 302.071199] RSP: 0018:ffff880139f4db58 EFLAGS: 00010246
[ 302.071202] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[ 302.071206] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880139f48700
[ 302.071209] RBP: ffff880139f4dbc8 R08: 0000000000000000 R09: ffff8801389cc574
[ 302.071212] R10: dead000000200200 R11: ffff880139f4dc98 R12: ffff88012739a500
[ 302.071216] R13: ffff88012739a780 R14: 0000000000000000 R15: ffff88012ed266c0
[ 302.071220] FS: 00007f201be85740(0000) GS:ffff880001a00000(0000)
knlGS:0000000000000000
[ 302.071224] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 302.071227] CR2: 00000000000000a0 CR3: 000000013b2a6000 CR4: 00000000000406f0
[ 302.071230] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 302.071234] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 302.071238] Process vncviewer (pid: 2603, threadinfo
ffff880139f4c000, task ffff880131b1dc40)
[ 302.071240] Stack:
[ 302.071242] ffff8801389366c0 ffffffff8168ff08 000000000000001c
000000000000000c
[ 302.071248] <0> 0000000000000000 00000000004623c0 0000000000000000
0000000081606c40
[ 302.071253] <0> ffff8801389cc480 ffff88012739a500 ffff88012ef80780
0000000000000000
[ 302.071260] Call Trace:
[ 302.071265] [<ffffffff81387fba>] stale_bundle+0x15/0x1f
[ 302.071270] [<ffffffff81387fdc>] xfrm_dst_check+0x18/0x2e
[ 302.071275] [<ffffffff8131d02f>] __sk_dst_check+0x27/0x53
[ 302.071281] [<ffffffff8135172a>] ip_queue_xmit+0x3c/0x2ed
[ 302.071286] [<ffffffff8136405c>] ? tcp_connect+0x1d4/0x379
[ 302.071290] [<ffffffff8131eef3>] ? __skb_clone+0x29/0x100
[ 302.071295] [<ffffffff81363dc0>] tcp_transmit_skb+0x6e1/0x71f
[ 302.071300] [<ffffffff81364175>] tcp_connect+0x2ed/0x379
[ 302.071305] [<ffffffff81243739>] ? secure_tcp_sequence_number+0x55/0x6e
[ 302.071310] [<ffffffff813692ee>] tcp_v4_connect+0x3c4/0x419
[ 302.071316] [<ffffffff811952d2>] ? avc_has_perm+0x57/0x69
[ 302.071321] [<ffffffff81375030>] inet_stream_connect+0xa7/0x260
[ 302.071326] [<ffffffff8131aa26>] sys_connect+0x75/0x9b
[ 302.071332] [<ffffffff810e403c>] ? fd_install+0x52/0x5b
[ 302.071338] [<ffffffff81092983>] ? audit_syscall_entry+0x1b6/0x1e2
[ 302.071342] [<ffffffff8131a552>] ? sys_socket+0x3b/0x57
[ 302.071348] [<ffffffff81025f42>] system_call_fastpath+0x16/0x1b
[ 302.071350] Code: 7d 58 41 80 bf c0 00 00 00 02 0f 85 98 01 00 00
41 8b 87 a8 00 00 00 41 39 85 b8 01 00 00 0f 85 84 01 00 00 49 8b 85
90 01 00 00 <8b> 80 a0 00 00 00 41 39 85 bc 01 00 00 0f 85 6a 01 00 00
83 7d
[ 302.071400] RIP [<ffffffff81387e0b>] xfrm_bundle_ok+0x14f/0x2e9
[ 302.071405] RSP <ffff880139f4db58>
[ 302.071408] CR2: 00000000000000a0
[ 302.071414] ---[ end trace b4323dbb88295950 ]---
starting a bisect, but might take some time....
--
Justin P. Mattock
^ permalink raw reply
* Re: Recent results with BCM4312 on Netbook
From: Gábor Stefanik @ 2010-06-22 22:47 UTC (permalink / raw)
To: Larry Finger; +Cc: Michael Buesch, wireless, b43-dev
In-Reply-To: <4C20D884.3010501@lwfinger.net>
On Tue, Jun 22, 2010 at 5:36 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> Michael,
>
> I have some good news. The Netbook that came from John is suddenly
> developing DMA errors for the BCM4312, even though it does not have a
> Phoenix BIOS. I have no idea why it did not fail this way earlier, but at
> least I have a machine to debug that failure.
Suddenly developing DMA errors? Hmm... maybe it's a hardware issue
with the card, from which wl can silently recover?
>
> My first discovery is that if PIO mode is to be used, it is not sufficient
> to load the module with the "pio=1" option, but that both "qos=0" and
> "nohwcrypt=1" options must also be used, at least for WPA/WPA2 networks.
> No other combination works. In addition, the automatic failover to PIO
> mode does not work unless those two options were used when the module was
> loaded. Thus both of the following work:
>
> modprobe b43 pio=1 qos=0 nohwcrypt=1
> modprobe b43 qos=0 hwcrypt=1
>
> The second example gets a fatal DMA error and resets the controller before
> the network comes up. I tried setting the latter two options before the
> controller reset call in the failover, but that did not work.
>
> If you have suggestions on changes in the switch from DMA to PIO mode,
> please send them to me. In the meantime, I will be looking at differences
> in the MMIO traces between wl and b43 to try to fix the DMA problem at the
> source of the trouble.
>
> Larry
>
> _______________________________________________
> b43-dev mailing list
> b43-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/b43-dev
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: rt2500usb: WPA2 TKIP+AES does not work with HW encryption
From: Ondrej Zary @ 2010-06-22 21:46 UTC (permalink / raw)
To: Gertjan van Wingerde; +Cc: Ivo Van Doorn, rt2x00 Users List, linux-wireless
In-Reply-To: <4C211076.9060804@gmail.com>
On Tuesday 22 June 2010 21:35:18 Gertjan van Wingerde wrote:
> On 06/22/10 12:38, Ondrej Zary wrote:
> > Hello,
> > I'm (again) trying to solve (debug) a weird problem with Asus WL-167G:
> > 0b05:1706 ASUSTek Computer, Inc. WL-167G v1 802.11g Adapter [Ralink
> > RT2500USB]
> >
> > The problem only appears when HW encryption is enabled and connecting to
> > an AP configured as WPA2 TKIP+AES.
> >
> > HW encryption works when the AP is configured as TKIP-only or AES-only.
> > It also works when AP is configured as TKIP+AES but wpa_supplicant is
> > forced to use TKIP as pairwise cipher (pairwise=TKIP)
> >
> > SW encryption works always.
> >
> > The problem is that no packets are transmitted. I can't see DHCP
> > broadcasts on other machine using tcpdump. But when I run tcpdump on the
> > rt2500usb, I see broadcasts from the other machine, so receive seems to
> > work fine.
> >
> > Added some printk()s to the driver, 6 packets from unsuccessful DHCP:
> > [ 371.760073] rt2500usb_write_tx_desc: key_idx=0
> > [ 371.852062] rt2500usb_write_tx_desc: key_idx=0
> > [ 371.944054] rt2500usb_write_tx_desc: key_idx=0
> > [ 372.036068] rt2500usb_write_tx_desc: key_idx=0
> > [ 372.128056] rt2500usb_write_tx_desc: key_idx=0
> > [ 372.220053] rt2500usb_write_tx_desc: key_idx=0
> > [ 372.312053] rt2500usb_write_tx_desc: key_idx=0
> > [ 372.404055] rt2500usb_write_tx_desc: key_idx=0
> > [ 372.496101] rt2500usb_write_tx_desc: key_idx=0
> > [ 372.588077] rt2500usb_write_tx_desc: key_idx=0
> > [ 372.688073] rt2500usb_write_tx_desc: key_idx=0
> > [ 373.272513] wlan1: authenticate with 00:13:d4:0f:f3:19 (try 1)
> > [ 373.272552] rt2500usb_write_tx_desc: key_idx=0
> > [ 373.274533] wlan1: authenticated
> > [ 373.274564] wlan1: associate with 00:13:d4:0f:f3:19 (try 1)
> > [ 373.274581] rt2500usb_write_tx_desc: key_idx=0
> > [ 373.277696] wlan1: RX AssocResp from 00:13:d4:0f:f3:19 (capab=0x411
> > status=0 aid=1) [ 373.277704] wlan1: associated
> > [ 373.308247] rt2500usb_write_tx_desc: key_idx=0
> > [ 373.308392] rt2500usb_write_tx_desc: key_idx=0
> > [ 373.315999] rt2500usb_write_tx_desc: key_idx=0
> > [ 373.340306] rt2x00crypto_key_to_cipher: ALG_CCMP
> > [ 373.340318] rt2500usb_config_key key->hw_key_idx=0 SET_KEY hw_key_idx
> > = 0 OK [ 373.344521] rt2x00crypto_key_to_cipher: ALG_TKIP
> > [ 373.344527] rt2500usb_config_key key->hw_key_idx=0 SET_KEY hw_key_idx
> > = 1 OK [ 373.412083] rt2500usb_write_tx_desc: key_idx=0
> > [ 375.160233] rt2x00crypto_key_to_cipher: ALG_CCMP
> > [ 375.160246] rt2x00crypto_tx_overhead=8
> > [ 375.160254] rt2500usb_write_tx_desc: key_idx=0
> > [ 375.240078] rt2500usb_write_tx_desc: key_idx=0
> > [ 381.163494] rt2x00crypto_key_to_cipher: ALG_CCMP
> > [ 381.163507] rt2x00crypto_tx_overhead=8
> > [ 381.163515] rt2500usb_write_tx_desc: key_idx=0
> > [ 381.244066] rt2500usb_write_tx_desc: key_idx=0
> > [ 388.165180] rt2x00crypto_key_to_cipher: ALG_CCMP
> > [ 388.165194] rt2x00crypto_tx_overhead=8
> > [ 388.165201] rt2500usb_write_tx_desc: key_idx=0
> > [ 388.244069] rt2500usb_write_tx_desc: key_idx=0
> > [ 399.169468] rt2x00crypto_key_to_cipher: ALG_CCMP
> > [ 399.169481] rt2x00crypto_tx_overhead=8
> > [ 399.169489] rt2500usb_write_tx_desc: key_idx=0
> > [ 399.248067] rt2500usb_write_tx_desc: key_idx=0
> > [ 404.080428] rt2500usb_write_tx_desc: key_idx=0
> > [ 404.180066] rt2500usb_write_tx_desc: key_idx=0
> > [ 410.168836] rt2x00crypto_key_to_cipher: ALG_CCMP
> > [ 410.168850] rt2x00crypto_tx_overhead=8
> > [ 410.168858] rt2500usb_write_tx_desc: key_idx=0
> > [ 410.248068] rt2500usb_write_tx_desc: key_idx=0
> > [ 414.374545] rt2500usb_write_tx_desc: key_idx=0
> > [ 414.472061] rt2500usb_write_tx_desc: key_idx=0
> > [ 422.169686] rt2x00crypto_key_to_cipher: ALG_CCMP
> > [ 422.169699] rt2x00crypto_tx_overhead=8
> > [ 422.169706] rt2500usb_write_tx_desc: key_idx=0
> > [ 422.252069] rt2500usb_write_tx_desc: key_idx=0
> >
> > Seems that it's trying to use CCMP, which is good. I wonder if the keys
> > are properly handled in rt2500usb_config_key. They seem to be uploaded to
> > the HW correctly (one at index 0, one at 1) - but can't tell without any
> > HW docs.
> >
> > I did some framedumps before but don't know what to do with them (what to
> > look for):
> > http://www.rainbow-software.org/linux_files/rt2500usb/dump-wpa2-bad.txt
> > http://www.rainbow-software.org/linux_files/rt2500usb/dump-wpa2-good.txt
> >
> > Anything else I can try?
>
> Hi Ondrej,
>
> Did you also test what happens if you configure the AP to be TKIP+AES and
> force wpa-supplicant to use AES pairwise key?
> If my analysis below is correct then that may work as well.
That does not work - it's probably the same case as default options (TKIP
group key + AES pairwise key).
> If my reading of the rt2570 data sheet is correct, then the rt2570 will
> only support one encryption mechanism at the time. That means that it is
> not possible to upload 1 TKIP key and 1 AES key at the same time to the
> hardware. All the configured keys have to be of the same encryption
> algorithm.
> Presumably this is why the HW encryption engine fails, as the keys are set
> with mixed settings.
> Based on that, I don't think that rt2500usb can support this TKIP+AES
> setting on wpa-supplicant.
If this is true, then the driver should fall back to SW encryption in this
case.
--
Ondrej Zary
^ permalink raw reply
* Re: [PATCH] compat-wireless: "crap" code is "not yet posted", not "not yet merged"
From: Luis R. Rodriguez @ 2010-06-22 21:11 UTC (permalink / raw)
To: Pavel Roskin; +Cc: linux-wireless
In-Reply-To: <20100622204048.5228.76910.stgit@mj.roinet.com>
On Tue, Jun 22, 2010 at 1:40 PM, Pavel Roskin <proski@gnu.org> wrote:
>
> ---
> scripts/admin-update.sh | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/scripts/admin-update.sh b/scripts/admin-update.sh
> index 7592546..4eb7c3e 100755
> --- a/scripts/admin-update.sh
> +++ b/scripts/admin-update.sh
> @@ -85,7 +85,7 @@ nag_pending() {
>
> nag_crap() {
> printf "${RED}%10s${NORMAL} - Crap changes not yet posted\n" $2
> - printf "${RED}%10s${NORMAL} - Crap additions not yet merged\n" $3
> + printf "${RED}%10s${NORMAL} - Crap additions not yet posted\n" $3
> printf "${RED}%10s${NORMAL} - Crap deletions not yet posted\n" $4
> printf "${RED}%10s${NORMAL} - %% of crap code\n" $(perl -e 'printf("%.4f", 100 * '$2' / '$1');')
> }
>
applied, thanks!
Luis
^ permalink raw reply
* [PATCH] compat-wireless: "crap" code is "not yet posted", not "not yet merged"
From: Pavel Roskin @ 2010-06-22 20:40 UTC (permalink / raw)
To: Luis R. Rodriguez, linux-wireless
---
scripts/admin-update.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/scripts/admin-update.sh b/scripts/admin-update.sh
index 7592546..4eb7c3e 100755
--- a/scripts/admin-update.sh
+++ b/scripts/admin-update.sh
@@ -85,7 +85,7 @@ nag_pending() {
nag_crap() {
printf "${RED}%10s${NORMAL} - Crap changes not yet posted\n" $2
- printf "${RED}%10s${NORMAL} - Crap additions not yet merged\n" $3
+ printf "${RED}%10s${NORMAL} - Crap additions not yet posted\n" $3
printf "${RED}%10s${NORMAL} - Crap deletions not yet posted\n" $4
printf "${RED}%10s${NORMAL} - %% of crap code\n" $(perl -e 'printf("%.4f", 100 * '$2' / '$1');')
}
^ permalink raw reply related
* Re: [ath5k-devel] [PATCH v2] ath5k: disable ASPM
From: Luis R. Rodriguez @ 2010-06-22 19:38 UTC (permalink / raw)
To: Johannes Stezenbach
Cc: Matthew Garrett, Jussi Kivilinna, Maxim Levitsky, David Quan,
Bob Copeland, Luis R. Rodriguez, ath5k-devel, linux-wireless,
linux-kernel, Jonathan May, Tim Gardner
In-Reply-To: <AANLkTin1fAAgYTYegqaadkYIYP2NXRNRzCR48e-uIgYV@mail.gmail.com>
On Tue, Jun 22, 2010 at 12:37 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Tue, Jun 22, 2010 at 12:31 PM, Johannes Stezenbach <js@sig21.net> wrote:
>> On Tue, Jun 22, 2010 at 07:44:26PM +0100, Matthew Garrett wrote:
>>> On Tue, Jun 22, 2010 at 11:28:20AM -0700, Luis R. Rodriguez wrote:
>>> >
>>> > Heh, this whole patch and thread was started because Jussi tested
>>> > ath5k with pcie_aspm=force (on a pre PCIE 1.1 device (?)) . I have
>>> > been trying to explain all along why this is a terrible idea to the
>>> > point we should probably just remove that code from the kernel. Hence
>>> > my side rants and explanations to justify my reasonings.
>>>
>>> Well, there's two things here. If you use force then you might get
>>> inappropriate ASPM. But if your BIOS enables ASPM on an old device, then
>>> booting *without* CONFIG_PCIE_ASPM will leave it turned on, and booting
>>> *with* CONFIG_PCIE_ASPM will turn it off. The Kconfig description is
>>> confusing - reality is that CONFIG_PCIE_ASPM enables logic that allows
>>> the kernel to modify the BIOS default, and disabling it makes the
>>> assumption that your BIOS did something sensible.
>>
>> Does CONFIG_PCIEASPM provide a way for the user to modifiy
>> the settings at runtime?
>
> You can tune ASPM settings at runtime, regardless of CONFIG_PCIEASPM. See:
>
> http://kernel.org/pub/linux/kernel/people/mcgrof/aspm/enable-aspm
> http://wireless.kernel.org/en/users/Documentation/ASPM
>
>> I have a Samsung N130 netbook which has a BIOS setting
>> called "CPU Power Saving Mode". When enabled it activates
>> ASPM L1 and L0s for the ethernet chip (Realtek RTL8102e, 100Mbit)
>> and the PCIE bridge (with the BIOS setting off it's just L1).
>> The result is that the ethernet througput is reduced to 25Mbit/s.
>> (The BIOS setting does not activa L0s for the Atheros AR9285 WLAN.)
>>
>> 99,9% of the time I want to enjoy the power savings,
>> but occationally I have to transfer some bulk data and would
>> like to switch the setting for a few minutes.
>>
>> Or, well, ideally I'd like to have power savings _and_ performance
>> at the same time without any manual intervention. I'm not sure
>> if this is a quirk of the N130 or if ASPM L0s always causes
>> performance degradation?
>
> L0s is not going to buy you much gains, getting at least L1 will
> however. L0s is just a further enhancement. I recommend you test by
> enabling L1 and L0s, check how longer your battery lasts and then test
> again with just L1. Then test without both L1 and L0s.
So defaults should always be sane and you should not have to play with
this stuff, unless you're a hacker, or are testing something for
development purposes. Tweaking ASPM settings is not something a user
should have to worry about. Period.
Luis
^ permalink raw reply
* Re: [ath5k-devel] [PATCH v2] ath5k: disable ASPM
From: Luis R. Rodriguez @ 2010-06-22 19:37 UTC (permalink / raw)
To: Johannes Stezenbach
Cc: Matthew Garrett, Jussi Kivilinna, Maxim Levitsky, David Quan,
Bob Copeland, Luis R. Rodriguez, ath5k-devel, linux-wireless,
linux-kernel, Jonathan May, Tim Gardner
In-Reply-To: <20100622193143.GA17803@sig21.net>
On Tue, Jun 22, 2010 at 12:31 PM, Johannes Stezenbach <js@sig21.net> wrote:
> On Tue, Jun 22, 2010 at 07:44:26PM +0100, Matthew Garrett wrote:
>> On Tue, Jun 22, 2010 at 11:28:20AM -0700, Luis R. Rodriguez wrote:
>> >
>> > Heh, this whole patch and thread was started because Jussi tested
>> > ath5k with pcie_aspm=force (on a pre PCIE 1.1 device (?)) . I have
>> > been trying to explain all along why this is a terrible idea to the
>> > point we should probably just remove that code from the kernel. Hence
>> > my side rants and explanations to justify my reasonings.
>>
>> Well, there's two things here. If you use force then you might get
>> inappropriate ASPM. But if your BIOS enables ASPM on an old device, then
>> booting *without* CONFIG_PCIE_ASPM will leave it turned on, and booting
>> *with* CONFIG_PCIE_ASPM will turn it off. The Kconfig description is
>> confusing - reality is that CONFIG_PCIE_ASPM enables logic that allows
>> the kernel to modify the BIOS default, and disabling it makes the
>> assumption that your BIOS did something sensible.
>
> Does CONFIG_PCIEASPM provide a way for the user to modifiy
> the settings at runtime?
You can tune ASPM settings at runtime, regardless of CONFIG_PCIEASPM. See:
http://kernel.org/pub/linux/kernel/people/mcgrof/aspm/enable-aspm
http://wireless.kernel.org/en/users/Documentation/ASPM
> I have a Samsung N130 netbook which has a BIOS setting
> called "CPU Power Saving Mode". When enabled it activates
> ASPM L1 and L0s for the ethernet chip (Realtek RTL8102e, 100Mbit)
> and the PCIE bridge (with the BIOS setting off it's just L1).
> The result is that the ethernet througput is reduced to 25Mbit/s.
> (The BIOS setting does not activa L0s for the Atheros AR9285 WLAN.)
>
> 99,9% of the time I want to enjoy the power savings,
> but occationally I have to transfer some bulk data and would
> like to switch the setting for a few minutes.
>
> Or, well, ideally I'd like to have power savings _and_ performance
> at the same time without any manual intervention. I'm not sure
> if this is a quirk of the N130 or if ASPM L0s always causes
> performance degradation?
L0s is not going to buy you much gains, getting at least L1 will
however. L0s is just a further enhancement. I recommend you test by
enabling L1 and L0s, check how longer your battery lasts and then test
again with just L1. Then test without both L1 and L0s.
Luis
^ permalink raw reply
* Re: 2.6.35-rc3: Reported regressions 2.6.33 -> 2.6.34
From: Tim Gardner @ 2010-06-22 19:36 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Pavel Roskin, linux-wireless, Rafael J. Wysocki, j
In-Reply-To: <AANLkTilQSFWP7DABswlOqUOq1yjFQG6RwFzkOIY6zl4i@mail.gmail.com>
On 06/21/2010 06:26 PM, Luis R. Rodriguez wrote:
> On Mon, Jun 21, 2010 at 5:14 PM, Tim Gardner<tim.gardner@canonical.com> wrote:
>> On 06/21/2010 04:18 PM, Luis R. Rodriguez wrote:
>>>
>>> On Mon, Jun 21, 2010 at 3:01 PM, Pavel Roskin<proski@gnu.org> wrote:
>>>>
>>>> On Mon, 2010-06-21 at 11:32 -0700, Luis R. Rodriguez wrote:
>>>>
>>>>>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16111
>>>>>> Subject : hostap_pci: infinite registered netdevice wifi0
>>>>>> Submitter : Petr Pisar<petr.pisar@atlas.cz>
>>>>>> Date : 2010-06-02 20:55 (19 days old)
>>>>>
>>>>> The last entry on this one says we are not sure how to fix this...
>>>>
>>>> That was a patch posted for that by Tim Gardner:
>>>> https://patchwork.kernel.org/patch/105008/
>>>>
>>>> The patch is applied to wireless-testing
>>>> (d6a574ff6bfb842bdb98065da053881ff527be46)
>>>>
>>>> $ git describe d6a574ff6bfb842bdb98065da053881ff527be46
>>>> v2.6.34-4694-gd6a574f
>>>>
>>>> I understand it was applied after 2.6.34, so it should be backported to
>>>> 2.6.34 and whatever older kernels are affected.
>>>
>>> Tim can this be sent for stable?
>>>
>>> Luis, a stable whore
>>>
>>
>> Luis,
>>
>> The patch that I sent John is already Cc stable@kernel.org, though it may
>> not now apply after 56bf882230d2266a2e07b7f404dc96d157a65daa 'Revert
>> "wireless: hostap, fix oops due to early probing interrupt"'. I'll check in
>> the morning and craft a backported patch if necessary.
>
> Sweet thanks for the heads up!
>
> Luis
>
Hmm, looks like I'm gonna have to write some backport patches. I'll wait
until this appears in Linus' tree so I can feed stable the right SHA1 info.
rtg
--
Tim Gardner tim.gardner@canonical.com
^ permalink raw reply
* Re: rt2500usb: WPA2 TKIP+AES does not work with HW encryption
From: Gertjan van Wingerde @ 2010-06-22 19:35 UTC (permalink / raw)
To: Ondrej Zary; +Cc: Ivo Van Doorn, rt2x00 Users List, linux-wireless
In-Reply-To: <201006221238.32745.linux@rainbow-software.org>
On 06/22/10 12:38, Ondrej Zary wrote:
> Hello,
> I'm (again) trying to solve (debug) a weird problem with Asus WL-167G:
> 0b05:1706 ASUSTek Computer, Inc. WL-167G v1 802.11g Adapter [Ralink RT2500USB]
>
> The problem only appears when HW encryption is enabled and connecting to an AP
> configured as WPA2 TKIP+AES.
>
> HW encryption works when the AP is configured as TKIP-only or AES-only. It
> also works when AP is configured as TKIP+AES but wpa_supplicant is forced to
> use TKIP as pairwise cipher (pairwise=TKIP)
>
> SW encryption works always.
>
> The problem is that no packets are transmitted. I can't see DHCP broadcasts on
> other machine using tcpdump. But when I run tcpdump on the rt2500usb, I see
> broadcasts from the other machine, so receive seems to work fine.
>
> Added some printk()s to the driver, 6 packets from unsuccessful DHCP:
> [ 371.760073] rt2500usb_write_tx_desc: key_idx=0
> [ 371.852062] rt2500usb_write_tx_desc: key_idx=0
> [ 371.944054] rt2500usb_write_tx_desc: key_idx=0
> [ 372.036068] rt2500usb_write_tx_desc: key_idx=0
> [ 372.128056] rt2500usb_write_tx_desc: key_idx=0
> [ 372.220053] rt2500usb_write_tx_desc: key_idx=0
> [ 372.312053] rt2500usb_write_tx_desc: key_idx=0
> [ 372.404055] rt2500usb_write_tx_desc: key_idx=0
> [ 372.496101] rt2500usb_write_tx_desc: key_idx=0
> [ 372.588077] rt2500usb_write_tx_desc: key_idx=0
> [ 372.688073] rt2500usb_write_tx_desc: key_idx=0
> [ 373.272513] wlan1: authenticate with 00:13:d4:0f:f3:19 (try 1)
> [ 373.272552] rt2500usb_write_tx_desc: key_idx=0
> [ 373.274533] wlan1: authenticated
> [ 373.274564] wlan1: associate with 00:13:d4:0f:f3:19 (try 1)
> [ 373.274581] rt2500usb_write_tx_desc: key_idx=0
> [ 373.277696] wlan1: RX AssocResp from 00:13:d4:0f:f3:19 (capab=0x411 status=0 aid=1)
> [ 373.277704] wlan1: associated
> [ 373.308247] rt2500usb_write_tx_desc: key_idx=0
> [ 373.308392] rt2500usb_write_tx_desc: key_idx=0
> [ 373.315999] rt2500usb_write_tx_desc: key_idx=0
> [ 373.340306] rt2x00crypto_key_to_cipher: ALG_CCMP
> [ 373.340318] rt2500usb_config_key key->hw_key_idx=0 SET_KEY hw_key_idx = 0 OK
> [ 373.344521] rt2x00crypto_key_to_cipher: ALG_TKIP
> [ 373.344527] rt2500usb_config_key key->hw_key_idx=0 SET_KEY hw_key_idx = 1 OK
> [ 373.412083] rt2500usb_write_tx_desc: key_idx=0
> [ 375.160233] rt2x00crypto_key_to_cipher: ALG_CCMP
> [ 375.160246] rt2x00crypto_tx_overhead=8
> [ 375.160254] rt2500usb_write_tx_desc: key_idx=0
> [ 375.240078] rt2500usb_write_tx_desc: key_idx=0
> [ 381.163494] rt2x00crypto_key_to_cipher: ALG_CCMP
> [ 381.163507] rt2x00crypto_tx_overhead=8
> [ 381.163515] rt2500usb_write_tx_desc: key_idx=0
> [ 381.244066] rt2500usb_write_tx_desc: key_idx=0
> [ 388.165180] rt2x00crypto_key_to_cipher: ALG_CCMP
> [ 388.165194] rt2x00crypto_tx_overhead=8
> [ 388.165201] rt2500usb_write_tx_desc: key_idx=0
> [ 388.244069] rt2500usb_write_tx_desc: key_idx=0
> [ 399.169468] rt2x00crypto_key_to_cipher: ALG_CCMP
> [ 399.169481] rt2x00crypto_tx_overhead=8
> [ 399.169489] rt2500usb_write_tx_desc: key_idx=0
> [ 399.248067] rt2500usb_write_tx_desc: key_idx=0
> [ 404.080428] rt2500usb_write_tx_desc: key_idx=0
> [ 404.180066] rt2500usb_write_tx_desc: key_idx=0
> [ 410.168836] rt2x00crypto_key_to_cipher: ALG_CCMP
> [ 410.168850] rt2x00crypto_tx_overhead=8
> [ 410.168858] rt2500usb_write_tx_desc: key_idx=0
> [ 410.248068] rt2500usb_write_tx_desc: key_idx=0
> [ 414.374545] rt2500usb_write_tx_desc: key_idx=0
> [ 414.472061] rt2500usb_write_tx_desc: key_idx=0
> [ 422.169686] rt2x00crypto_key_to_cipher: ALG_CCMP
> [ 422.169699] rt2x00crypto_tx_overhead=8
> [ 422.169706] rt2500usb_write_tx_desc: key_idx=0
> [ 422.252069] rt2500usb_write_tx_desc: key_idx=0
>
> Seems that it's trying to use CCMP, which is good. I wonder if the keys are
> properly handled in rt2500usb_config_key. They seem to be uploaded to the HW
> correctly (one at index 0, one at 1) - but can't tell without any HW docs.
>
> I did some framedumps before but don't know what to do with them (what to
> look for):
> http://www.rainbow-software.org/linux_files/rt2500usb/dump-wpa2-bad.txt
> http://www.rainbow-software.org/linux_files/rt2500usb/dump-wpa2-good.txt
>
> Anything else I can try?
>
Hi Ondrej,
Did you also test what happens if you configure the AP to be TKIP+AES and force
wpa-supplicant to use AES pairwise key?
If my analysis below is correct then that may work as well.
If my reading of the rt2570 data sheet is correct, then the rt2570 will only
support one encryption mechanism at the time. That means that it is not possible
to upload 1 TKIP key and 1 AES key at the same time to the hardware. All the
configured keys have to be of the same encryption algorithm.
Presumably this is why the HW encryption engine fails, as the keys are set with
mixed settings.
Based on that, I don't think that rt2500usb can support this TKIP+AES setting on
wpa-supplicant.
---
Gertjan.
^ permalink raw reply
* Re: [ath5k-devel] [PATCH v2] ath5k: disable ASPM
From: Johannes Stezenbach @ 2010-06-22 19:31 UTC (permalink / raw)
To: Matthew Garrett
Cc: Luis R. Rodriguez, Jussi Kivilinna, Maxim Levitsky, David Quan,
Bob Copeland, Luis R. Rodriguez, ath5k-devel, linux-wireless,
linux-kernel, Jonathan May, Tim Gardner
In-Reply-To: <20100622184426.GA24546@srcf.ucam.org>
On Tue, Jun 22, 2010 at 07:44:26PM +0100, Matthew Garrett wrote:
> On Tue, Jun 22, 2010 at 11:28:20AM -0700, Luis R. Rodriguez wrote:
> >
> > Heh, this whole patch and thread was started because Jussi tested
> > ath5k with pcie_aspm=force (on a pre PCIE 1.1 device (?)) . I have
> > been trying to explain all along why this is a terrible idea to the
> > point we should probably just remove that code from the kernel. Hence
> > my side rants and explanations to justify my reasonings.
>
> Well, there's two things here. If you use force then you might get
> inappropriate ASPM. But if your BIOS enables ASPM on an old device, then
> booting *without* CONFIG_PCIE_ASPM will leave it turned on, and booting
> *with* CONFIG_PCIE_ASPM will turn it off. The Kconfig description is
> confusing - reality is that CONFIG_PCIE_ASPM enables logic that allows
> the kernel to modify the BIOS default, and disabling it makes the
> assumption that your BIOS did something sensible.
Does CONFIG_PCIEASPM provide a way for the user to modifiy
the settings at runtime?
I have a Samsung N130 netbook which has a BIOS setting
called "CPU Power Saving Mode". When enabled it activates
ASPM L1 and L0s for the ethernet chip (Realtek RTL8102e, 100Mbit)
and the PCIE bridge (with the BIOS setting off it's just L1).
The result is that the ethernet througput is reduced to 25Mbit/s.
(The BIOS setting does not activa L0s for the Atheros AR9285 WLAN.)
99,9% of the time I want to enjoy the power savings,
but occationally I have to transfer some bulk data and would
like to switch the setting for a few minutes.
Or, well, ideally I'd like to have power savings _and_ performance
at the same time without any manual intervention. I'm not sure
if this is a quirk of the N130 or if ASPM L0s always causes
performance degradation?
Thanks
Johannes
^ permalink raw reply
* Re: [ath5k-devel] [PATCH v2] ath5k: disable ASPM
From: Luis R. Rodriguez @ 2010-06-22 19:13 UTC (permalink / raw)
To: Matthew Garrett
Cc: Luis R. Rodriguez, linux-wireless@vger.kernel.org, David Quan,
Luis R. Rodriguez, linux-kernel, ath5k-devel@venema.h4ckr.net,
Jonathan May, Jussi Kivilinna, Tim Gardner
In-Reply-To: <20100622184426.GA24546@srcf.ucam.org>
On Tue, Jun 22, 2010 at 11:44:26AM -0700, Matthew Garrett wrote:
> On Tue, Jun 22, 2010 at 11:28:20AM -0700, Luis R. Rodriguez wrote:
> > On Tue, Jun 22, 2010 at 10:50 AM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> > > People who use "force" deserve whatever they get,
> >
> > Heh, this whole patch and thread was started because Jussi tested
> > ath5k with pcie_aspm=force (on a pre PCIE 1.1 device (?)) . I have
> > been trying to explain all along why this is a terrible idea to the
> > point we should probably just remove that code from the kernel. Hence
> > my side rants and explanations to justify my reasonings.
>
> Well, there's two things here. If you use force then you might get
> inappropriate ASPM. But if your BIOS enables ASPM on an old device, then
> booting *without* CONFIG_PCIE_ASPM will leave it turned on, and booting
> *with* CONFIG_PCIE_ASPM will turn it off. The Kconfig description is
> confusing - reality is that CONFIG_PCIE_ASPM enables logic that allows
> the kernel to modify the BIOS default, and disabling it makes the
> assumption that your BIOS did something sensible.
Agreed, given that you also mentioned you would put it under embeeded
how about something like this:
diff --git a/drivers/pci/pcie/Kconfig b/drivers/pci/pcie/Kconfig
index b8b494b..9c76b70 100644
--- a/drivers/pci/pcie/Kconfig
+++ b/drivers/pci/pcie/Kconfig
@@ -31,14 +31,29 @@ source "drivers/pci/pcie/aer/Kconfig"
# PCI Express ASPM
#
config PCIEASPM
- bool "PCI Express ASPM support(Experimental)"
- depends on PCI && EXPERIMENTAL && PCIEPORTBUS
- default n
+ bool "PCI Express ASPM sanity check support" if EMBEDDED
+ depends on PCI && PCIEPORTBUS
+ default y
help
- This enables PCI Express ASPM (Active State Power Management) and
- Clock Power Management. ASPM supports state L0/L0s/L1.
+ This enables some sanity checks for PCI Express ASPM.
+ ASPM supports the states L0/L0s/L1. The sanity checks are to
+ disable ASPM if:
+
+ a) the device is pre-1.1
+ b) the firmware has the FADT flag set to tell you not to
+ c) the firmware doesn't grant control via _OSC
+
+ Without this option your BIOS's defaults will be respected
+ and while although this should always be correct it typically
+ is not. If your ASPM settings are incorrect you may experience
+ odd hangs which are hard to debug. These sanity checks should
+ help avoid these odd hangs by only enabling ASPM if we are
+ sure we can enable it.
+
+ For more information you can refer to this documentation:
+
+ http://wireless.kernel.org/en/users/Documentation/ASPM
- When in doubt, say N.
config PCIEASPM_DEBUG
bool "Debug PCI Express ASPM"
depends on PCIEASPM
> > Where is "powersave"?
> >
> > I do see a "powersave" but its an ASPM policy string and it implies
> > you want to enable L1 and L0s when the device's LinkCap supports it,
> > see pcie_config_aspm_link() and its users. So in other words powersave
> > seems to imply you are using pcie_aspm=force, no?
>
> No. pcie_aspm=force will enable ASPM even if (a) the device is pre-1.1,
> (b) the firmware has the FADT flag set to tell you not to and (c) the
> firmware doesn't grant control via _OSC. The powersave policy will
> enable ASPM even if the BIOS didn't, but only if something else doesn't
> tell us not to.
So if any of the above (a) (b) or (c) are true powersave will keep
it disabled? Is pcie_aspm=forcepowersave this a new option with your
patches?
> > > Fedora's defaulted to that for a while now - we've hit
> > > issues with aacraid, but that's pretty much it in terms of cases where
> > > the heuristics don't work. Maxim's problems wouldn't be triggered
> > > because CONFIG_PCIE_ASPM disables it on pre-1.1 devices regardless of
> > > the BIOS setup.
> >
> > I don't expect all distributions to have CONFIG_PCIE_ASPM enabled, in
> > fact I was unaware of this sanity check being included as part of
> > CONFIG_PCIE_ASPM, I recommend we consider just enabling the sanity
> > check all the time. The fact that CONFIG_PCIE_ASPM is even an option
> > seems confusing to me given that apart from this sanity check the only
> > other thing that I see useful in it is the forcing of ASPM settings
> > and as I noted I think pcie_aspm=force is pretty dangerous.
>
> You're right, it shouldn't be an option. It's vital for making sure that
> ASPM is disabled when it should be. I'd be happy with pcie_aspm=force
> tainting the kernel.
:) !
> > > With the patch I've just sent, they should also all be used for Linux as
> > > well.
> >
> > Oh nice! It'll be part of 2.6.36?
>
> As long as Jesse picks it up.
Nice.
> > > If the same problems would appear under Windows then it's not a problem
> > > that I'm hugely concerned about as yet
> >
> > Yes, these issues would also be part of Windows. But should also note
> > this also means for those people working on their own BIOSes it means
> > you also have to take these things into more serious consideration.
>
> There's a standardised mechanism for BIOS authors to tell us not to
> touch their ASPM configuration, and people that ignore that really do
> deserve to have things break.
Oh, I was more concerned about open bios hackers. If a device requires
PCI host controller tweaks should *we* be doing those tweaks and sanity
checks oursevles upstream or should we rely on the open-bios guys to
do it accordingly in their code?
> > Me neither, ASPM should just work with default settings, which is why
> > I also do not like that the sanity check on the PCIE 1.1 spec is done
> > through CONFIG_PCIE_ASPM, it makes no sense given that ASPM *will*
> > work even if you do not have CONFIG_PCIE_ASPM but the device has
> > functional ASPM.
>
> I agree. I'll send a patch that moves it under CONFIG_EMBEDDED and
> defaults to on.
:D
> > I do think we should be depending on userspace to do development
> > testing and forcing ASPM on, because the only other alternative is
> > pcie_aspm=force and as noted this is just not a good idea unless you
> > *seriously* know what you are doing.
>
> If you set the powersave policy and ASPM doesn't get enabled, then
> that's because we've got a really strong belief that ASPM shouldn't be
> enabled. Is your concern just that pcie_aspm=force is too easy for users
> to get at?
Yes! I think people are starting to use it like to magically save
more power without taking into consideration the implications. This is
why I was suggesting maybe we nuke that option all together. Does it
*really* give us any benefit? The only benefit I see is if we *are*
100% sure our system should work with all our root complexes and
endpoints having ASPM enabled. That I do not see happening until
a few years from now.
Maybe we should have another type of module parameter type, a
I_know_what_Im_doing_module_parameter and taint whenever any of
those are on, not just pcie_aspm=force ? :)
Luis
^ permalink raw reply related
* Compat-wireless release for 2010-06-22 is baked
From: Compat-wireless cronjob account @ 2010-06-22 19:04 UTC (permalink / raw)
To: linux-wireless, linux-bluetooth
>From git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/compat-wireless-2.6
75bb510..7df472d master -> origin/master
3eaa500..8e2a8ea wl -> origin/wl
>From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next
fd729ff..41d99c6 history -> origin/history
+ 13f4704...d82e647 master -> origin/master (forced update)
* [new tag] next-20100622 -> next-20100622
compat-wireless code metrics
498619 - Total upstream lines of code being pulled
1410 - backport code changes
1177 - backport code additions
233 - backport code deletions
5748 - backport from compat module
7158 - total backport code
1.4356 - % of code consists of backport work
1218 - Crap changes not yet posted
1179 - Crap additions not yet merged
39 - Crap deletions not yet posted
0.2443 - % of crap code
Base tree: linux-next.git
Base tree version: next-20100622
compat-wireless release: compat-wireless-2010-06-17-3-g7df472d
^ permalink raw reply
* Re: [ath5k-devel] [PATCH v2] ath5k: disable ASPM
From: Matthew Garrett @ 2010-06-22 18:44 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Jussi Kivilinna, Maxim Levitsky, David Quan, Bob Copeland,
Luis R. Rodriguez, ath5k-devel, linux-wireless, linux-kernel,
Jonathan May, Tim Gardner
In-Reply-To: <AANLkTinE0BiOa5cpcIerbias7K-aDzj3x4qaeDpzy2CQ@mail.gmail.com>
On Tue, Jun 22, 2010 at 11:28:20AM -0700, Luis R. Rodriguez wrote:
> On Tue, Jun 22, 2010 at 10:50 AM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> > People who use "force" deserve whatever they get,
>
> Heh, this whole patch and thread was started because Jussi tested
> ath5k with pcie_aspm=force (on a pre PCIE 1.1 device (?)) . I have
> been trying to explain all along why this is a terrible idea to the
> point we should probably just remove that code from the kernel. Hence
> my side rants and explanations to justify my reasonings.
Well, there's two things here. If you use force then you might get
inappropriate ASPM. But if your BIOS enables ASPM on an old device, then
booting *without* CONFIG_PCIE_ASPM will leave it turned on, and booting
*with* CONFIG_PCIE_ASPM will turn it off. The Kconfig description is
confusing - reality is that CONFIG_PCIE_ASPM enables logic that allows
the kernel to modify the BIOS default, and disabling it makes the
assumption that your BIOS did something sensible.
> Where is "powersave"?
>
> I do see a "powersave" but its an ASPM policy string and it implies
> you want to enable L1 and L0s when the device's LinkCap supports it,
> see pcie_config_aspm_link() and its users. So in other words powersave
> seems to imply you are using pcie_aspm=force, no?
No. pcie_aspm=force will enable ASPM even if (a) the device is pre-1.1,
(b) the firmware has the FADT flag set to tell you not to and (c) the
firmware doesn't grant control via _OSC. The powersave policy will
enable ASPM even if the BIOS didn't, but only if something else doesn't
tell us not to.
> > Fedora's defaulted to that for a while now - we've hit
> > issues with aacraid, but that's pretty much it in terms of cases where
> > the heuristics don't work. Maxim's problems wouldn't be triggered
> > because CONFIG_PCIE_ASPM disables it on pre-1.1 devices regardless of
> > the BIOS setup.
>
> I don't expect all distributions to have CONFIG_PCIE_ASPM enabled, in
> fact I was unaware of this sanity check being included as part of
> CONFIG_PCIE_ASPM, I recommend we consider just enabling the sanity
> check all the time. The fact that CONFIG_PCIE_ASPM is even an option
> seems confusing to me given that apart from this sanity check the only
> other thing that I see useful in it is the forcing of ASPM settings
> and as I noted I think pcie_aspm=force is pretty dangerous.
You're right, it shouldn't be an option. It's vital for making sure that
ASPM is disabled when it should be. I'd be happy with pcie_aspm=force
tainting the kernel.
> > With the patch I've just sent, they should also all be used for Linux as
> > well.
>
> Oh nice! It'll be part of 2.6.36?
As long as Jesse picks it up.
> > If the same problems would appear under Windows then it's not a problem
> > that I'm hugely concerned about as yet
>
> Yes, these issues would also be part of Windows. But should also note
> this also means for those people working on their own BIOSes it means
> you also have to take these things into more serious consideration.
There's a standardised mechanism for BIOS authors to tell us not to
touch their ASPM configuration, and people that ignore that really do
deserve to have things break.
> Me neither, ASPM should just work with default settings, which is why
> I also do not like that the sanity check on the PCIE 1.1 spec is done
> through CONFIG_PCIE_ASPM, it makes no sense given that ASPM *will*
> work even if you do not have CONFIG_PCIE_ASPM but the device has
> functional ASPM.
I agree. I'll send a patch that moves it under CONFIG_EMBEDDED and
defaults to on.
> I do think we should be depending on userspace to do development
> testing and forcing ASPM on, because the only other alternative is
> pcie_aspm=force and as noted this is just not a good idea unless you
> *seriously* know what you are doing.
If you set the powersave policy and ASPM doesn't get enabled, then
that's because we've got a really strong belief that ASPM shouldn't be
enabled. Is your concern just that pcie_aspm=force is too easy for users
to get at?
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply
* Re: [PATCH 1/5 v2]wireless:hostap_main.c warning: variable 'iface' set but not used
From: Justin P. Mattock @ 2010-06-22 18:34 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20100622181320.GD2583@tuxdriver.com>
On 06/22/2010 11:13 AM, John W. Linville wrote:
> On Mon, Jun 21, 2010 at 03:02:13PM -0700, Justin P. Mattock wrote:
>> This is a resend from version one due to trying a different approach
>> than the original(probably important to leave netdev_priv() in).
>>
>> In any case have a look, if there's another approach let me know
>> and ill test it out. The below patch fixes a warning im seeing
>> when compiling with gcc 4.6.0
>>
>> CC [M] drivers/net/wireless/hostap/hostap_main.o
>> drivers/net/wireless/hostap/hostap_main.c: In function 'hostap_set_multicast_list_queue':
>> drivers/net/wireless/hostap/hostap_main.c:744:27: warning: variable 'iface' set but not used
>> Signed-off-by: Justin P. Mattock<justinmattock@gmail.com>
>
> I already applied the other version to wireless-next-2.6. I can't
> imagine what you mean to accomplish by leaving in a call to netdev_priv
> w/o assigning the result to something.
>
> John
alright..
as for the netdev_priv, I was getting confused on this one.
Thanks for taking the time to look at this.
Justin P. Mattock
^ permalink raw reply
* Re: [ath5k-devel] [PATCH v2] ath5k: disable ASPM
From: Luis R. Rodriguez @ 2010-06-22 18:28 UTC (permalink / raw)
To: Matthew Garrett
Cc: Jussi Kivilinna, Maxim Levitsky, David Quan, Bob Copeland,
Luis R. Rodriguez, ath5k-devel, linux-wireless, linux-kernel,
Jonathan May, Tim Gardner
In-Reply-To: <20100622175058.GA23499@srcf.ucam.org>
On Tue, Jun 22, 2010 at 10:50 AM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> On Tue, Jun 22, 2010 at 10:40:15AM -0700, Luis R. Rodriguez wrote:
>> On Tue, Jun 22, 2010 at 10:25 AM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
>> > Right, which we have to deal with by having drivers disable ASPM on
>> > broken devices.
>>
>> Agreed, but then the assumption would be drivers are ASPM bug free
>> which is expect to be false with Video and 802.11 given that only a
>> handful of vendors do actually get involved with their drivers
>> upstream. Safe thing of course is to just disable it, of course, but
>> if you are going to use pcie_aspm=force good luck!
>
> People who use "force" deserve whatever they get,
Heh, this whole patch and thread was started because Jussi tested
ath5k with pcie_aspm=force (on a pre PCIE 1.1 device (?)) . I have
been trying to explain all along why this is a terrible idea to the
point we should probably just remove that code from the kernel. Hence
my side rants and explanations to justify my reasonings.
> but "powersave" really ought to work.
Interesting, as per Documentation/kernel-parameters.txt we have:
pcie_aspm= [PCIE] Forcibly enable or disable PCIe Active
State Power
Management.
off Disable ASPM.
force Enable ASPM even on devices that claim not to
support it.
WARNING: Forcing ASPM on may cause system lockups.
I was unaware of a "powersave" option to the pcie_aspm kernel
parameter. In fact:
static int __init pcie_aspm_disable(char *str)
{
if (!strcmp(str, "off")) {
aspm_disabled = 1;
printk(KERN_INFO "PCIe ASPM is disabled\n");
} else if (!strcmp(str, "force")) {
aspm_force = 1;
printk(KERN_INFO "PCIe ASPM is forcedly enabled\n");
}
return 1;
}
__setup("pcie_aspm=", pcie_aspm_disable);
Where is "powersave"?
I do see a "powersave" but its an ASPM policy string and it implies
you want to enable L1 and L0s when the device's LinkCap supports it,
see pcie_config_aspm_link() and its users. So in other words powersave
seems to imply you are using pcie_aspm=force, no?
> Fedora's defaulted to that for a while now - we've hit
> issues with aacraid, but that's pretty much it in terms of cases where
> the heuristics don't work. Maxim's problems wouldn't be triggered
> because CONFIG_PCIE_ASPM disables it on pre-1.1 devices regardless of
> the BIOS setup.
I don't expect all distributions to have CONFIG_PCIE_ASPM enabled, in
fact I was unaware of this sanity check being included as part of
CONFIG_PCIE_ASPM, I recommend we consider just enabling the sanity
check all the time. The fact that CONFIG_PCIE_ASPM is even an option
seems confusing to me given that apart from this sanity check the only
other thing that I see useful in it is the forcing of ASPM settings
and as I noted I think pcie_aspm=force is pretty dangerous.
>> > Having looked into this, Windows will enable ASPM on external
>> > controllers unless there's some reason for it not to - where that may be
>> > either the appropriate bit in the FADT being set, the device not being
>> > PCIe 1.1 or later, there being no _OSC method on the appropriate root
>> > bridge or the _OSC method not giving it full control over PCIe, the
>> > driver disabling ASPM or the device not advertising it in the first
>> > place.
>>
>> I was unaware of all this root complex sanity checks on Windows,
>> thanks for sharing.
>
> With the patch I've just sent, they should also all be used for Linux as
> well.
Oh nice! It'll be part of 2.6.36?
>> I suspect these tweaks will go away as the industry produces cards
>> with both L1 and L0s enabled all the time (devices being produced
>> today), but for devices caught in that middle of time between whether
>> or not L0s would be *required* (last 2 years) I suspect we'll run
>> into these issues.
>
> If the same problems would appear under Windows then it's not a problem
> that I'm hugely concerned about as yet
Yes, these issues would also be part of Windows. But should also note
this also means for those people working on their own BIOSes it means
you also have to take these things into more serious consideration.
> - we'll wait a bit longer and
> then change the ASPM defaults to be more aggressive under Linux, and if
> it turns out to be a significant problem in the real world we'll have to
> reconsider it.
The problem is the tweaks in question are device specific. I can see
if I can get you concrete examples.
> But I don't think we should be depending on userspace
> bashing hardware registers in order to be able to enable power
> management.
Me neither, ASPM should just work with default settings, which is why
I also do not like that the sanity check on the PCIE 1.1 spec is done
through CONFIG_PCIE_ASPM, it makes no sense given that ASPM *will*
work even if you do not have CONFIG_PCIE_ASPM but the device has
functional ASPM.
I do think we should be depending on userspace to do development
testing and forcing ASPM on, because the only other alternative is
pcie_aspm=force and as noted this is just not a good idea unless you
*seriously* know what you are doing.
Luis
^ permalink raw reply
* Re: [PATCH 1/5 v2]wireless:hostap_main.c warning: variable 'iface' set but not used
From: John W. Linville @ 2010-06-22 18:13 UTC (permalink / raw)
To: Justin P. Mattock; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <1277157733-14071-1-git-send-email-justinmattock@gmail.com>
On Mon, Jun 21, 2010 at 03:02:13PM -0700, Justin P. Mattock wrote:
> This is a resend from version one due to trying a different approach
> than the original(probably important to leave netdev_priv() in).
>
> In any case have a look, if there's another approach let me know
> and ill test it out. The below patch fixes a warning im seeing
> when compiling with gcc 4.6.0
>
> CC [M] drivers/net/wireless/hostap/hostap_main.o
> drivers/net/wireless/hostap/hostap_main.c: In function 'hostap_set_multicast_list_queue':
> drivers/net/wireless/hostap/hostap_main.c:744:27: warning: variable 'iface' set but not used
> Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
I already applied the other version to wireless-next-2.6. I can't
imagine what you mean to accomplish by leaving in a call to netdev_priv
w/o assigning the result to something.
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: pull request: wireless-2.6 2010-06-22
From: David Miller @ 2010-06-22 17:54 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20100622174136.GC2583@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Tue, 22 Jun 2010 13:41:37 -0400
> Just a single fix this time, a patch for ath5k to avoid a null pointer
> dereference that can happen when executing certain operations against a
> newly created interface. This is, of course, intended for 2.6.35.
>
> Please let me know if there are problems!
Pulled, thanks John.
^ permalink raw reply
* Re: [ath5k-devel] [PATCH v2] ath5k: disable ASPM
From: Matthew Garrett @ 2010-06-22 17:50 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Jussi Kivilinna, Maxim Levitsky, David Quan, Bob Copeland,
Luis R. Rodriguez, ath5k-devel, linux-wireless, linux-kernel,
Jonathan May
In-Reply-To: <AANLkTilEHJ5qRD8ov0gIK0Zc4o-gJUPYkvHdyD1uZUon@mail.gmail.com>
On Tue, Jun 22, 2010 at 10:40:15AM -0700, Luis R. Rodriguez wrote:
> On Tue, Jun 22, 2010 at 10:25 AM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> > Right, which we have to deal with by having drivers disable ASPM on
> > broken devices.
>
> Agreed, but then the assumption would be drivers are ASPM bug free
> which is expect to be false with Video and 802.11 given that only a
> handful of vendors do actually get involved with their drivers
> upstream. Safe thing of course is to just disable it, of course, but
> if you are going to use pcie_aspm=force good luck!
People who use "force" deserve whatever they get, but "powersave" really
ought to work. Fedora's defaulted to that for a while now - we've hit
issues with aacraid, but that's pretty much it in terms of cases where
the heuristics don't work. Maxim's problems wouldn't be triggered
because CONFIG_PCIE_ASPM disables it on pre-1.1 devices regardless of
the BIOS setup.
> > Having looked into this, Windows will enable ASPM on external
> > controllers unless there's some reason for it not to - where that may be
> > either the appropriate bit in the FADT being set, the device not being
> > PCIe 1.1 or later, there being no _OSC method on the appropriate root
> > bridge or the _OSC method not giving it full control over PCIe, the
> > driver disabling ASPM or the device not advertising it in the first
> > place.
>
> I was unaware of all this root complex sanity checks on Windows,
> thanks for sharing.
With the patch I've just sent, they should also all be used for Linux as
well.
> I suspect these tweaks will go away as the industry produces cards
> with both L1 and L0s enabled all the time (devices being produced
> today), but for devices caught in that middle of time between whether
> or not L0s would be *required* (last 2 years) I suspect we'll run
> into these issues.
If the same problems would appear under Windows then it's not a problem
that I'm hugely concerned about as yet - we'll wait a bit longer and
then change the ASPM defaults to be more aggressive under Linux, and if
it turns out to be a significant problem in the real world we'll have to
reconsider it. But I don't think we should be depending on userspace
bashing hardware registers in order to be able to enable power
management.
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply
* pull request: wireless-2.6 2010-06-22
From: John W. Linville @ 2010-06-22 17:41 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
Dave,
Just a single fix this time, a patch for ath5k to avoid a null pointer
dereference that can happen when executing certain operations against a
newly created interface. This is, of course, intended for 2.6.35.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 25442e06d20aaba7d7b16438078a562b3e4cf19b:
stephen hemminger (1):
bridge: fdb cleanup runs too often
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
Bob Copeland (1):
ath5k: initialize ah->ah_current_channel
drivers/net/wireless/ath/ath5k/attach.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/attach.c b/drivers/net/wireless/ath/ath5k/attach.c
index e0c244b..31c0080 100644
--- a/drivers/net/wireless/ath/ath5k/attach.c
+++ b/drivers/net/wireless/ath/ath5k/attach.c
@@ -126,6 +126,7 @@ int ath5k_hw_attach(struct ath5k_softc *sc)
ah->ah_ant_mode = AR5K_ANTMODE_DEFAULT;
ah->ah_noise_floor = -95; /* until first NF calibration is run */
sc->ani_state.ani_mode = ATH5K_ANI_MODE_AUTO;
+ ah->ah_current_channel = &sc->channels[0];
/*
* Find the mac version
--
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 related
* Re: [ath5k-devel] [PATCH v2] ath5k: disable ASPM
From: Luis R. Rodriguez @ 2010-06-22 17:40 UTC (permalink / raw)
To: Matthew Garrett
Cc: Jussi Kivilinna, Maxim Levitsky, David Quan, Bob Copeland,
Luis R. Rodriguez, ath5k-devel, linux-wireless, linux-kernel,
Jonathan May
In-Reply-To: <20100622172545.GA22680@srcf.ucam.org>
On Tue, Jun 22, 2010 at 10:25 AM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> On Tue, Jun 22, 2010 at 10:17:11AM -0700, Luis R. Rodriguez wrote:
>> On Tue, Jun 22, 2010 at 9:52 AM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
>> > Why would you only want to enable ASPM for one device?
>>
>> ASPM doesn't always work for all devices even if they do advertise
>> ASPM capability so turning it on selectively by device is what I
>> recommend since otherwise you may get hangs and you will then have to
>> do the selective enabling.
>
> Right, which we have to deal with by having drivers disable ASPM on
> broken devices.
Agreed, but then the assumption would be drivers are ASPM bug free
which is expect to be false with Video and 802.11 given that only a
handful of vendors do actually get involved with their drivers
upstream. Safe thing of course is to just disable it, of course, but
if you are going to use pcie_aspm=force good luck!
>> Furthermore laptops tend to disable ASPM for cards not built-in to it,
>> an example is Cardbus slots or internal PCI-E slots. This is often
>> done because to enable ASPM for some cards you often need to tune the
>> host controller in addition to enabling ASPM for the endpoint, so this
>> will vary depending on vendor, chipset, and host controller
>> combination. This is documentation that the OEM / ODM typically end up
>> getting, but not end users.
>
> Having looked into this, Windows will enable ASPM on external
> controllers unless there's some reason for it not to - where that may be
> either the appropriate bit in the FADT being set, the device not being
> PCIe 1.1 or later, there being no _OSC method on the appropriate root
> bridge or the _OSC method not giving it full control over PCIe, the
> driver disabling ASPM or the device not advertising it in the first
> place.
I was unaware of all this root complex sanity checks on Windows,
thanks for sharing.
> Are you aware of any other cases where Windows will refuse to
> enable ASPM?
My point was not whether or not ASPM typically got enabled on Windows
Vs Linux, my point was more of the fact that for some endpoint devices
you may have to tweak the root complex to get ASPM properly working
and that these tweaks *are* implemented on the BIOS by the ODM / OEM
for those devices and that the documentation for such tweaks is not
typically public. So, if you are like me and cannot stand the internal
802.11 card on your laptop and want to replace it with something else
you are stuck to hoping such BIOS tweaks are either not required or
figuring out what the tweaks are yourself and doing them through
userspace for the root complex *prior* to enabling ASPM through
userspace as well for the endpoint.
I suspect these tweaks will go away as the industry produces cards
with both L1 and L0s enabled all the time (devices being produced
today), but for devices caught in that middle of time between whether
or not L0s would be *required* (last 2 years) I suspect we'll run
into these issues.
Luis
^ permalink raw reply
* Re: [ath5k-devel] [PATCH v2] ath5k: disable ASPM
From: Matthew Garrett @ 2010-06-22 17:25 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Jussi Kivilinna, Maxim Levitsky, David Quan, Bob Copeland,
Luis R. Rodriguez, ath5k-devel, linux-wireless, linux-kernel
In-Reply-To: <AANLkTikHLBBWrhCP_1f5Jv7zE9RKPvdsl5nSyfkeMfLl@mail.gmail.com>
On Tue, Jun 22, 2010 at 10:17:11AM -0700, Luis R. Rodriguez wrote:
> On Tue, Jun 22, 2010 at 9:52 AM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> > Why would you only want to enable ASPM for one device?
>
> ASPM doesn't always work for all devices even if they do advertise
> ASPM capability so turning it on selectively by device is what I
> recommend since otherwise you may get hangs and you will then have to
> do the selective enabling.
Right, which we have to deal with by having drivers disable ASPM on
broken devices.
> Furthermore laptops tend to disable ASPM for cards not built-in to it,
> an example is Cardbus slots or internal PCI-E slots. This is often
> done because to enable ASPM for some cards you often need to tune the
> host controller in addition to enabling ASPM for the endpoint, so this
> will vary depending on vendor, chipset, and host controller
> combination. This is documentation that the OEM / ODM typically end up
> getting, but not end users.
Having looked into this, Windows will enable ASPM on external
controllers unless there's some reason for it not to - where that may be
either the appropriate bit in the FADT being set, the device not being
PCIe 1.1 or later, there being no _OSC method on the appropriate root
bridge or the _OSC method not giving it full control over PCIe, the
driver disabling ASPM or the device not advertising it in the first
place. Are you aware of any other cases where Windows will refuse to
enable ASPM?
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply
* Re: [ath5k-devel] [PATCH v2] ath5k: disable ASPM
From: Luis R. Rodriguez @ 2010-06-22 17:17 UTC (permalink / raw)
To: Matthew Garrett
Cc: Jussi Kivilinna, Maxim Levitsky, David Quan, Bob Copeland,
Luis R. Rodriguez, ath5k-devel, linux-wireless, linux-kernel
In-Reply-To: <20100622165213.GA21842@srcf.ucam.org>
On Tue, Jun 22, 2010 at 9:52 AM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> On Tue, Jun 22, 2010 at 09:48:40AM -0700, Luis R. Rodriguez wrote:
>
>> Sure, I agree with that, but it also will enable ASPM for *all*
>> devices which have the capability which IMHO is a terrible idea for
>> users when all they want to do is enable ASPM for one device. Instead
>> I recommend users to enable ASPM for their devices selectively and
>> from userspace.
>
> Why would you only want to enable ASPM for one device?
ASPM doesn't always work for all devices even if they do advertise
ASPM capability so turning it on selectively by device is what I
recommend since otherwise you may get hangs and you will then have to
do the selective enabling. Furthermore laptops tend to disable ASPM
for cards not built-in to it, an example is Cardbus slots or internal
PCI-E slots. This is often done because to enable ASPM for some cards
you often need to tune the host controller in addition to enabling
ASPM for the endpoint, so this will vary depending on vendor, chipset,
and host controller combination. This is documentation that the OEM /
ODM typically end up getting, but not end users.
So given the complexity its best to be selective about it on each
platform until you verify ASPM works well for all devices present.
Luis
^ permalink raw reply
* Re: ASPM status for iwlwifi and power-management (in general)
From: reinette chatre @ 2010-06-22 17:12 UTC (permalink / raw)
To: sedat.dilek@gmail.com
Cc: wireless, Luis R. Rodriguez, Berg, Johannes, John Linville
In-Reply-To: <AANLkTilpqUnWG2CnMNZR7a45rY9cbqks3W-gkjsMbYOQ@mail.gmail.com>
On Tue, 2010-06-22 at 03:44 -0700, Sedat Dilek wrote:
> Before I will try 'pcie_aspm=force' cheat-code I wanted to ask about
> the status of iwlwifi and ASPM.
> Is there code available. yet? Which kernel has it - linux-next,
> wireless-testing GIT, iwlwifi GIT?
iwl3945 will disable L0s if L1 enabled, and enable L0s if L1 disabled.
Please see iwl_apm_init which is called by iwl3945_apm_init
Reinette
^ permalink raw reply
* Re: [ath5k-devel] [PATCH v2] ath5k: disable ASPM
From: Matthew Garrett @ 2010-06-22 16:52 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Jussi Kivilinna, Maxim Levitsky, David Quan, Bob Copeland,
Luis R. Rodriguez, ath5k-devel, linux-wireless, linux-kernel
In-Reply-To: <AANLkTikQkLFdpusfcLVOpyZHFrxwB5akr-ggFB7Fjm08@mail.gmail.com>
On Tue, Jun 22, 2010 at 09:48:40AM -0700, Luis R. Rodriguez wrote:
> Sure, I agree with that, but it also will enable ASPM for *all*
> devices which have the capability which IMHO is a terrible idea for
> users when all they want to do is enable ASPM for one device. Instead
> I recommend users to enable ASPM for their devices selectively and
> from userspace.
Why would you only want to enable ASPM for one device?
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply
* Re: [ath5k-devel] [PATCH v2] ath5k: disable ASPM
From: Luis R. Rodriguez @ 2010-06-22 16:48 UTC (permalink / raw)
To: Matthew Garrett
Cc: Jussi Kivilinna, Maxim Levitsky, David Quan, Bob Copeland,
Luis R. Rodriguez, ath5k-devel, linux-wireless, linux-kernel
In-Reply-To: <20100622163138.GD20668@srcf.ucam.org>
On Tue, Jun 22, 2010 at 9:31 AM, Matthew Garrett <mjg@redhat.com> wrote:
> On Mon, Jun 21, 2010 at 01:39:07PM -0700, Luis R. Rodriguez wrote:
>> Last I reviewed CONFIG_PCIEASPM won't buy you *anything* other than
>> debugging knobs. With it you can force all devices to enable ASPM
>> completely on or disable it. Both of which I think are not really
>> useful and instead should be done in userspace given that if you are
>> testing ASPM you likely want to test only one one device and its
>> respective root complex, not all at the same time.
>
> It buys you enabling of ASPM on devices that the BIOS hasn't configured,
> which is legitimate and useful.
Sure, I agree with that, but it also will enable ASPM for *all*
devices which have the capability which IMHO is a terrible idea for
users when all they want to do is enable ASPM for one device. Instead
I recommend users to enable ASPM for their devices selectively and
from userspace.
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