* Re: compat-wireless tracepoint error Re: [Ndiswrapper-general] Need help to create driver for Netgear WN111v2
From: Hin-Tak Leung @ 2009-09-30 0:57 UTC (permalink / raw)
To: Malte Gell; +Cc: linux-wireless
In-Reply-To: <200909300017.20949.malte.gell@gmx.de>
On Tue, Sep 29, 2009 at 11:17 PM, Malte Gell <malte.gell@gmx.de> wrote:
>
> "Hin-Tak Leung" <hintak.leung@gmail.com> wrote
>
>>
>> Argh... try changing this line in config.mk
>>
>> ifndef CONFIG_COMPAT_WIRELESS_28
>>
>> to ...27.
>
> Hello,
>
> it was a pain with my Kernel 2.6.27.29 I now updated to kernel 2.6.31-44 (from
> openSUSE) and voila, it now works like a charm! I compiled the bleeding edge
> compat-wireless and it just works fine now! As I initially suspected, 2.6.27
> only made trouble.
>
> Regards
> Malte
>
Glad to hear.
Hin-Tak
^ permalink raw reply
* Re: driver_nl80211 broken again
From: Maxim Levitsky @ 2009-09-30 1:19 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Jouni Malinen, hostap@lists.shmoo.com
In-Reply-To: <1252443260.16422.5.camel@maxim-laptop>
>
> Sure!
> Very soon will do
>
So I didn't do the testing that soon...
Got swamped by many bugs present in ubuntu 9.10.
Now I have attempted same patch on top of wpa_supplicant, and it works.
diff --git a/wpa_supplicant/wpa_supplicant.c b/wpa_supplicant/wpa_supplicant.c
index 37a1927..a0098b9 100644
--- a/wpa_supplicant/wpa_supplicant.c
+++ b/wpa_supplicant/wpa_supplicant.c
@@ -1302,8 +1302,10 @@ void wpa_supplicant_disassociate(struct wpa_supplicant *wpa_s,
if (!is_zero_ether_addr(wpa_s->bssid)) {
if (wpa_s->drv_flags & WPA_DRIVER_FLAGS_USER_SPACE_MLME)
ieee80211_sta_disassociate(wpa_s, reason_code);
- else
+ else {
wpa_drv_disassociate(wpa_s, wpa_s->bssid, reason_code);
+ wpa_drv_deauthenticate(wpa_s, wpa_s->bssid, reason_code);
+ }
addr = wpa_s->bssid;
}
wpa_clear_keys(wpa_s, addr);
Would that be enough, or this is too hacky, and we need to audit each callsite of wpa_supplicant_disassociate
and see if we need to send deauth frame too?
Best regards,
Maxim Levitsky
^ permalink raw reply related
* Re: cannot compile compate-wirless snapshots
From: Hin-Tak Leung @ 2009-09-30 1:19 UTC (permalink / raw)
To: Gábor Stefanik; +Cc: Malte Gell, Hauke Mehrtens, linux-wireless
In-Reply-To: <69e28c910909291127x3be75be0r3ceef7367d05f9c3@mail.gmail.com>
2009/9/29 Gábor Stefanik <netrolller.3d@gmail.com>:
> On Tue, Sep 29, 2009 at 11:00 AM, Hin-Tak Leung <hintak.leung@gmail.com> wrote:
>> The relevant config is probably /boot/config-`uname -r`, but, please
>> do *not* modify it.
>>
>
> It should be in /proc/config.gz. (/boot/config-* is an Ubuntuism.)
John pointed out Fedora & RHEL does /boot/config-* . (and don't
provide /proc/config.gz). I don't know which distro does
/proc/config.gz Obviously neither Ubuntu nor Fedora/RHEL; maybe one of
Mandriva/Debian/Suse?
As a point of interest, /boot also contains the init ramdisk, the
kernel symbol map besides the kernel image (beside some
grub/boot-loader files), so it isn't too much to have another kernel
related file. For the purist, building the kernel to have
self-knowledge of its own config under /proc is a neat thing, but
OTOH, it uses kernel memory to provide what is very static unchanging
info under /proc, which is unwise.
^ permalink raw reply
* Re: [ath5k-devel] Ath5k and proprietary extensions
From: Aditya @ 2009-09-30 3:11 UTC (permalink / raw)
Cc: ath5k-devel, linux-wireless
In-Reply-To: <1251837101.14862.32.camel@mj>
Hi,
I am working on a research project which needs to change the channel
width to 5,10 and 40MHz. Ive been looking through the mailing lists and
there seems to be some interest in having an API built for this.
Would it be possible for someone to please outline the steps needed to
enable 5,10,40 MHz channels? I am not looking for a clean implemented
API, just whatever hack is required to change the PLL clock, modify
PHY/RF settings (as mentioned in the thread below) in order to get this
to work.
Thanks very much for your help
regards,
Aditya Bhave
Pavel Roskin wrote:
> On Sat, 2009-08-29 at 07:51 +0300, Nick Kossifidis wrote:
>
>
>> a) X.R.: eXtended Range is a set of proprietary rates and some extra
>> techniques (various hw tweaks etc) to enable long distance, low
>> bandwidth links.
>>
>
> I'm not interested because it's ugly and we don't have a good reference
> implementation. Besides, there must be a reason why it's not in the
> FreeBSD HAL. Either it's patented or Atheros was ashamed to expose that
> code.
>
>
>> b) OFDM-only g settings for AR5211: AR5211 chips have support for
>> draft-g (eg. no dynamic CCK/OFDM modulation, only OFDM). I don't know
>> if we want to support it or not, removing the settings will save us
>> some space and since it's a draft g implementation i don't think there
>> are many compatible APs out there. Is there any possibility to support
>> draft-g on mac80211/cfg80211 ? If not we can just drop it else it's
>> just some extra data, no big deal.
>>
>
> If there is a simple way to support it, let's do it. I think having
> "pure G" may be a good idea in some situations, regardless of the
> hardware limitations. But that's something that should be done in
> mac80211.
>
> I would keep the initialization code for now.
>
> That said, AR5210 and AR5211 are so rare, that we might consider
> splitting them into separate drivers that would not be actively
> maintained.
>
>
>> c) Half/quarter rate channels (10/5MHz width) and turbo mode (double
>> rate - 40MHz width): Hw can transmit with different channel width
>> allowing us to operate on half, quarter or double rate (also called
>> turbo mode).
>>
>
> It would be nice to be able to receive on wide and narrow channels, at
> least in the monitor mode. Generally, "be liberal in what you accept,
> and conservative in what you send".
>
> We'll need some API to set the bandwidth and radiotap flags to
> communicate the bandwidth to the recipient.
>
>
>> d) Fast frames: Hw can tx/rx jumbo frames of 3kbytes+ so fast frame
>> aggregation is a way to make use of that hw feature by sending 2
>> frames together (for more infos check out super ag white paper).
>>
>
> Likewise, it would be nice to receive them.
>
>
>> e) Compression: Hw can do on-chip compression/decompression using
>> standard Lempel Ziv algorithm per tx queue, MadWiFi implements this
>> and uses a vendor IE to let others know that it supports this feature
>> (same IE is used for all capabilities, fast frames, XR etc).
>>
>
> Same thing here, as long as we can reuse the existing kernel code for
> decompression.
>
>
^ permalink raw reply
* [.32-rc1/2] ath5k: has become unreliable with .32-rc1
From: Frans Pop @ 2009-09-30 7:52 UTC (permalink / raw)
To: linux-wireless; +Cc: linux-kernel, Bob Copeland
[-- Attachment #1: Type: text/plain, Size: 6178 bytes --]
This is on a laptop I don't use much, but with .31 wireless has always
been (and still is) reliable (.31-rc5 is the last kernel I built for it).
On my other laptop wireless (iwlagn) works fine with .32-rc1.
The first time I booted .32-rc1 (reboot from .31-rc5), wireless came up
without problems, but failed to come back after suspend to RAM. I could
only get wireless back by ejecting and re-inserting the PCMCIA card.
The second and third time I booted .32-rc1 (to write this report; a cold
boot and a ".32 to .32" reboot), wireless did not come up at all.
See attached dmesg. The last part is after 'ifup ath0'. It seems to
associate, but then for some reason immediately deauthenticates again.
Ejecting/reinserting the PCMCIA card or unloading/reloading the driver
does not help.
After that I tried .31-rc5 again and wireless came up fine. And when I
then rebooted into .32, wireless came up OK as well, same as the first
boot.
So the difference looks to be how I boot: if I do a *cold* boot directly
into .32, wireless fails; if I *reboot* from .31 into .32, wireless
comes up correctly. Reboot from .32 to .32 fails too.
I think the "wireless after boot" problem and the "resume" problem could
very well be separate issues. The resume problem looks similar to
http://bugzilla.kernel.org/show_bug.cgi?id=13948.
System: Toshiba Satellite A40; i386, Pentium 4, Debian stable ("Lenny")
01:0b.0 CardBus bridge [0607]: Toshiba America Info Systems ToPIC100
PCI to Cardbus Bridge with ZV Support [1179:0617] (rev 33)
02:00.0 Ethernet controller [0200]: Atheros Communications Inc.
AR5212/AR5213 Multiprotocol MAC/baseband processor [168c:0013] (rev 01)
From ath_info:
-==Device Information==-
MAC Version: 5212 (0x50)
MAC Revision: 5213A (0x59)
Device type: 1
dmesg diff showing resume with .31-rc5 and .32-rc1. Note that the "late"
config restore seems to have disappeared.
--- ../strider/2.6.31-rc5+resume 2009-09-30 03:42:21.000000000 +0200
+++ ../strider/2.6.32-rc1+resume 2009-09-30 03:38:54.000000000 +0200
Back to C!
CPU0: Thermal LVT vector (0xfa) already installed
ACPI: Waking up from system sleep state S3
pci 0000:00:02.1: restoring config space at offset 0x5 (was 0x0, writing 0x2c000000)
pci 0000:00:02.1: restoring config space at offset 0x4 (was 0x8, writing 0x20000008)
uhci_hcd 0000:00:1d.1: restoring config space at offset 0xf (was 0x2ff, writing 0x20b)
-ehci_hcd 0000:00:1d.7: PME# disabled
PIIX_IDE 0000:00:1f.1: restoring config space at offset 0xf (was 0x1ff, writing 0x10b)
PIIX_IDE 0000:00:1f.1: restoring config space at offset 0x1 (was 0x2800003, writing 0x2800007)
e100 0000:01:08.0: restoring config space at offset 0xf (was 0x380801ff, writing 0x3808010b)
e100 0000:01:08.0: restoring config space at offset 0x1 (was 0x2900003, writing 0x2900007)
ath5k 0000:02:00.0: restoring config space at offset 0xf (was 0xffffffff, writing 0x1c0a0112)
ath5k 0000:02:00.0: restoring config space at offset 0xe (was 0xffffffff, writing 0x0)
ath5k 0000:02:00.0: restoring config space at offset 0xd (was 0xffffffff, writing 0x44)
ath5k 0000:02:00.0: restoring config space at offset 0xc (was 0xffffffff, writing 0x0)
ath5k 0000:02:00.0: restoring config space at offset 0xb (was 0xffffffff, writing 0x710316ab)
ath5k 0000:02:00.0: restoring config space at offset 0xa (was 0xffffffff, writing 0x5001)
ath5k 0000:02:00.0: restoring config space at offset 0x9 (was 0xffffffff, writing 0x0)
ath5k 0000:02:00.0: restoring config space at offset 0x8 (was 0xffffffff, writing 0x0)
ath5k 0000:02:00.0: restoring config space at offset 0x7 (was 0xffffffff, writing 0x0)
ath5k 0000:02:00.0: restoring config space at offset 0x6 (was 0xffffffff, writing 0x0)
ath5k 0000:02:00.0: restoring config space at offset 0x5 (was 0xffffffff, writing 0x0)
ath5k 0000:02:00.0: restoring config space at offset 0x4 (was 0xffffffff, writing 0x30000000)
ath5k 0000:02:00.0: restoring config space at offset 0x3 (was 0xffffffff, writing 0xa808)
ath5k 0000:02:00.0: restoring config space at offset 0x2 (was 0xffffffff, writing 0x2000001)
ath5k 0000:02:00.0: restoring config space at offset 0x1 (was 0xffffffff, writing 0x2900006)
ath5k 0000:02:00.0: restoring config space at offset 0x0 (was 0xffffffff, writing 0x13168c)
-pci 0000:00:02.0: PME# disabled
-pci 0000:00:02.1: PME# disabled
uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
uhci_hcd 0000:00:1d.0: setting latency timer to 64
uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 19 (level, low) -> IRQ 19
uhci_hcd 0000:00:1d.1: setting latency timer to 64
-ehci_hcd 0000:00:1d.7: PME# disabled
ehci_hcd 0000:00:1d.7: PCI INT D -> GSI 23 (level, low) -> IRQ 23
ehci_hcd 0000:00:1d.7: setting latency timer to 64
pci 0000:00:1e.0: setting latency timer to 64
PIIX_IDE 0000:00:1f.1: PCI INT A -> GSI 18 (level, low) -> IRQ 18
PIIX_IDE 0000:00:1f.1: setting latency timer to 64
Intel ICH 0000:00:1f.5: PCI INT B -> GSI 17 (level, low) -> IRQ 17
Intel ICH 0000:00:1f.5: setting latency timer to 64
Intel ICH Modem 0000:00:1f.6: PCI INT B -> GSI 17 (level, low) -> IRQ 17
Intel ICH Modem 0000:00:1f.6: setting latency timer to 64
-e100 0000:01:08.0: PME# disabled
parport_pc 00:09: activated
hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
hda: UDMA/100 mode selected
hdc: host max PIO4 wanted PIO255(auto-tune) selected PIO4
hdc: UDMA/33 mode selected
-ath5k 0000:02:00.0: restoring config space at offset 0xf (was 0x1c0a0100, writing 0x1c0a0112)
-ath5k 0000:02:00.0: restoring config space at offset 0x4 (was 0x0, writing 0x30000000)
-ath5k 0000:02:00.0: restoring config space at offset 0x3 (was 0x0, writing 0xa808)
-ath5k 0000:02:00.0: restoring config space at offset 0x1 (was 0x2900000, writing 0x2900006)
+ath5k 0000:02:00.0: enabling device (0000 -> 0002)
ath5k 0000:02:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
+ath5k phy0: failed to wakeup the MAC Chip
+ath5k phy0: can't reset hardware (-5)
+ath5k phy0: failed to wakeup the MAC Chip
+ath5k phy0: can't reset hardware (-5)
Restarting tasks ... done.
[-- Attachment #2: dmesg.32-rc1 --]
[-- Type: text/plain, Size: 28464 bytes --]
Linux version 2.6.32-rc1 (root@aragorn) (gcc version 4.3.4 (Debian 4.3.4-3) ) #4 SMP Wed Sep 30 02:43:52 CEST 2009
KERNEL supported cpus:
Intel GenuineIntel
AMD AuthenticAMD
NSC Geode by NSC
Cyrix CyrixInstead
Centaur CentaurHauls
Transmeta GenuineTMx86
Transmeta TransmetaCPU
UMC UMC UMC UMC
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e0000 - 00000000000eee00 (reserved)
BIOS-e820: 00000000000eee00 - 00000000000ef000 (ACPI NVS)
BIOS-e820: 00000000000ef000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000001ef40000 (usable)
BIOS-e820: 000000001ef40000 - 000000001ef50000 (ACPI data)
BIOS-e820: 000000001ef50000 - 000000001f000000 (reserved)
BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
BIOS-e820: 00000000fec10000 - 00000000fec20000 (reserved)
BIOS-e820: 00000000feda0000 - 00000000fedc0000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000ffb00000 - 00000000ffc00000 (reserved)
BIOS-e820: 00000000ffe80000 - 0000000100000000 (reserved)
DMI 2.3 present.
last_pfn = 0x1ef40 max_arch_pfn = 0x100000
MTRR default type: uncachable
MTRR fixed ranges enabled:
00000-9FFFF write-back
A0000-BFFFF uncachable
C0000-CFFFF write-protect
D0000-DFFFF uncachable
E0000-E7FFF write-protect
E8000-EFFFF write-back
F0000-FFFFF write-protect
MTRR variable ranges enabled:
0 base 0FEDA0000 mask FFFFE0000 write-back
1 base 01F000000 mask FFF000000 uncachable
2 base 0FFF00000 mask FFFF00000 uncachable
3 base 000000000 mask FE0000000 write-back
4 disabled
5 disabled
6 disabled
7 disabled
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
e820 update range: 000000001f000000 - 00000000feda0000 (usable) ==> (reserved)
initial memory mapped : 0 - 01800000
init_memory_mapping: 0000000000000000-000000001ef40000
0000000000 - 0000400000 page 4k
0000400000 - 001ec00000 page 2M
001ec00000 - 001ef40000 page 4k
kernel direct mapping tables up to 1ef40000 @ 7000-c000
RAMDISK: 1eb5c000 - 1ef2f3ff
ACPI: RSDP 000f0180 00014 (v00 TOSHIB)
ACPI: RSDT 1ef40000 00038 (v01 TOSHIB 750 00970814 TASM 04010000)
ACPI: FACP 1ef40060 00084 (v02 TOSHIB 750 20030101 TASM 04010000)
ACPI: DSDT 1ef40558 04B72 (v01 TOSHIB A000C 20031216 MSFT 0100000E)
ACPI: FACS 000eee00 00040
ACPI: SSDT 1ef402ca 00082 (v01 TOSHIB A000C 20030917 MSFT 0100000E)
ACPI: DBGP 1ef400e4 00034 (v01 TOSHIB 750 00970814 TASM 04010000)
ACPI: BOOT 1ef40038 00028 (v01 TOSHIB 750 00970814 TASM 04010000)
ACPI: APIC 1ef40118 00062 (v01 TOSHIB 750 00970814 TASM 04010000)
ACPI: Local APIC address 0xfee00000
0MB HIGHMEM available.
495MB LOWMEM available.
mapped low ram: 0 - 1ef40000
low ram: 0 - 1ef40000
node 0 low ram: 00000000 - 1ef40000
node 0 bootmap 00002000 - 00005de8
(9 early reservations) ==> bootmem [0000000000 - 001ef40000]
#0 [0000000000 - 0000001000] BIOS data page ==> [0000000000 - 0000001000]
#1 [0000001000 - 0000002000] EX TRAMPOLINE ==> [0000001000 - 0000002000]
#2 [0000006000 - 0000007000] TRAMPOLINE ==> [0000006000 - 0000007000]
#3 [0001000000 - 000143a26c] TEXT DATA BSS ==> [0001000000 - 000143a26c]
#4 [001eb5c000 - 001ef2f3ff] RAMDISK ==> [001eb5c000 - 001ef2f3ff]
#5 [000009fc00 - 0000100000] BIOS reserved ==> [000009fc00 - 0000100000]
#6 [000143b000 - 00014411b0] BRK ==> [000143b000 - 00014411b0]
#7 [0000007000 - 0000008000] PGTABLE ==> [0000007000 - 0000008000]
#8 [0000002000 - 0000006000] BOOTMAP ==> [0000002000 - 0000006000]
Zone PFN ranges:
DMA 0x00000000 -> 0x00001000
Normal 0x00001000 -> 0x0001ef40
HighMem 0x0001ef40 -> 0x0001ef40
Movable zone start PFN for each node
early_node_map[2] active PFN ranges
0: 0x00000000 -> 0x0000009f
0: 0x00000100 -> 0x0001ef40
On node 0 totalpages: 126687
free_area_init_node: node 0, pgdat c1377f60, node_mem_map c1443000
DMA zone: 32 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 3967 pages, LIFO batch:0
Normal zone: 959 pages used for memmap
Normal zone: 121729 pages, LIFO batch:31
Using APIC driver default
ACPI: PM-Timer IO Port: 0xd808
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] disabled)
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Enabling APIC mode: Flat. Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
SMP: Allowing 2 CPUs, 1 hotplug CPUs
nr_irqs_gsi: 24
PM: Registered nosave memory: 000000000009f000 - 00000000000a0000
PM: Registered nosave memory: 00000000000a0000 - 00000000000e0000
PM: Registered nosave memory: 00000000000e0000 - 00000000000ee000
PM: Registered nosave memory: 00000000000ee000 - 00000000000ef000
PM: Registered nosave memory: 00000000000ef000 - 0000000000100000
Allocating PCI resources starting at 1f000000 (gap: 1f000000:dfc00000)
NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:2 nr_node_ids:1
PERCPU: Embedded 11 pages/cpu @c1c00000 s21720 r0 d23336 u2097152
pcpu-alloc: s21720 r0 d23336 u2097152 alloc=1*4194304
pcpu-alloc: [0] 0 1
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 125696
Kernel command line: root=/dev/mapper/strider-root ro vga=791 quiet
PID hash table entries: 2048 (order: 1, 8192 bytes)
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
Initializing HighMem for node 0 (00000000:00000000)
Memory: 493532k/507136k available (2348k kernel code, 12780k reserved, 1221k data, 324k init, 0k highmem)
virtual kernel memory layout:
fixmap : 0xfff1f000 - 0xfffff000 ( 896 kB)
pkmap : 0xff800000 - 0xffc00000 (4096 kB)
vmalloc : 0xdf740000 - 0xff7fe000 ( 512 MB)
lowmem : 0xc0000000 - 0xdef40000 ( 495 MB)
.init : 0xc137d000 - 0xc13ce000 ( 324 kB)
.data : 0xc124b0f1 - 0xc137c5d0 (1221 kB)
.text : 0xc1000000 - 0xc124b0f1 (2348 kB)
Checking if this processor honours the WP bit even in supervisor mode...Ok.
Hierarchical RCU implementation.
NR_IRQS:512
Console: colour dummy device 80x25
console [tty0] enabled
Fast TSC calibration using PIT
Detected 2792.798 MHz processor.
Calibrating delay loop (skipped), value calculated using timer frequency.. 5585.59 BogoMIPS (lpj=11171192)
Security Framework initialized
SELinux: Disabled at boot.
Mount-cache hash table entries: 512
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Hyper-Threading is disabled
mce: CPU supports 4 MCE banks
CPU0: Thermal monitoring enabled (TM1)
Checking 'hlt' instruction... OK.
SMP alternatives: switching to UP code
ACPI: Core revision 20090903
..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
CPU0: Mobile Intel(R) Pentium(R) 4 CPU 2.80GHz stepping 09
Brought up 1 CPUs
Total of 1 processors activated (5585.59 BogoMIPS).
CPU0 attaching NULL sched-domain.
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xfd2fe, last bus=3
PCI: Using configuration type 1 for base access
bio: create slab <bio-0> at 0
ACPI: EC: Look up EC in DSDT
ACPI Warning: Package List length (0xF) larger than NumElements count (0x2), truncated
(20090903/dsobject-515)
ACPI: Interpreter enabled
ACPI: (supports S0 S3 S4 S5)
ACPI: Using IOAPIC for interrupt routing
ACPI: Enumerating devices from [\]
[Firmware Bug]: ACPI: ACPI brightness control misses _BQC function
ACPI: No dock devices found.
ACPI: PCI Root Bridge [PCI0] (0000:00)
pci 0000:00:02.0: reg 10 32bit mmio pref: [0xd8000000-0xdfffffff]
pci 0000:00:02.0: reg 14 32bit mmio: [0xd0000000-0xd007ffff]
pci 0000:00:02.0: reg 18 io port: [0xeff8-0xefff]
pci 0000:00:02.0: supports D1
pci 0000:00:02.1: reg 10 32bit mmio pref: [0x000000-0x7ffffff]
pci 0000:00:02.1: reg 14 32bit mmio: [0x000000-0x07ffff]
pci 0000:00:02.1: supports D1
pci 0000:00:1d.0: reg 20 io port: [0xcfe0-0xcfff]
pci 0000:00:1d.1: reg 20 io port: [0xcf80-0xcf9f]
pci 0000:00:1d.7: reg 10 32bit mmio: [0x000000-0x0003ff]
pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold
pci 0000:00:1d.7: PME# disabled
pci 0000:00:1f.0: quirk: region d800-d87f claimed by ICH4 ACPI/GPIO/TCO
pci 0000:00:1f.0: quirk: region eec0-eeff claimed by ICH4 GPIO
pci 0000:00:1f.1: reg 10 io port: [0xbff8-0xbfff]
pci 0000:00:1f.1: reg 14 io port: [0xbff4-0xbff7]
pci 0000:00:1f.1: reg 18 io port: [0xbfe8-0xbfef]
pci 0000:00:1f.1: reg 1c io port: [0xbfe4-0xbfe7]
pci 0000:00:1f.1: reg 20 io port: [0xbfa0-0xbfaf]
pci 0000:00:1f.1: reg 24 32bit mmio: [0x000000-0x0003ff]
pci 0000:00:1f.5: reg 10 io port: [0x00-0xff]
pci 0000:00:1f.5: reg 14 io port: [0x00-0x3f]
pci 0000:00:1f.5: reg 18 32bit mmio: [0x000000-0x0001ff]
pci 0000:00:1f.5: reg 1c 32bit mmio: [0x000000-0x0000ff]
pci 0000:00:1f.5: PME# supported from D0 D3hot D3cold
pci 0000:00:1f.5: PME# disabled
pci 0000:00:1f.6: reg 10 io port: [0x00-0xff]
pci 0000:00:1f.6: reg 14 io port: [0x00-0x7f]
pci 0000:00:1f.6: PME# supported from D0 D3hot D3cold
pci 0000:00:1f.6: PME# disabled
pci 0000:01:08.0: reg 10 32bit mmio: [0xcffff000-0xcfffffff]
pci 0000:01:08.0: reg 14 io port: [0xcf40-0xcf7f]
pci 0000:01:08.0: supports D1 D2
pci 0000:01:08.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:01:08.0: PME# disabled
pci 0000:01:0b.0: reg 10 32bit mmio: [0x000000-0x000fff]
pci 0000:00:1e.0: transparent bridge
pci 0000:00:1e.0: bridge io port: [0xc000-0xcfff]
pci 0000:00:1e.0: bridge 32bit mmio: [0xcff00000-0xcfffffff]
pci_bus 0000:00: on NUMA node 0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIB._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs *10)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 *11)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *11)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *11)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 *11)
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 *11)
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 *11)
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 *11)
ACPI: Power Resource [PFAN] (off)
vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none
vgaarb: loaded
PCI: Using ACPI for IRQ routing
pci 0000:00:1d.0: BAR 4: address space collision on of device [0xcfe0-0xcfff]
pci 0000:00:1d.0: BAR 4: can't allocate resource
pci 0000:00:1d.1: BAR 4: address space collision on of device [0xcf80-0xcf9f]
pci 0000:00:1d.1: BAR 4: can't allocate resource
Switching to clocksource tsc
pnp: PnP ACPI init
ACPI: bus type pnp registered
pnp 00:08: io resource (0x10-0x1f) overlaps 0000:00:1d.0 BAR 4 (0x0-0x1f), disabling
pnp 00:08: io resource (0x10-0x1f) overlaps 0000:00:1d.1 BAR 4 (0x0-0x1f), disabling
pnp: PnP ACPI: found 10 devices
ACPI: ACPI bus type pnp unregistered
PnPBIOS: Disabled by ACPI PNP
system 00:00: iomem range 0x0-0x9ffff could not be reserved
(The fact that a range could not be reserved is generally harmless.)
system 00:00: iomem range 0xe0000-0xeffff could not be reserved
system 00:00: iomem range 0xf0000-0xfffff could not be reserved
system 00:00: iomem range 0x100000-0x1ef3ffff could not be reserved
system 00:00: iomem range 0x1ef40000-0x1ef4ffff could not be reserved
system 00:00: iomem range 0x1ef50000-0x1effffff has been reserved
system 00:00: iomem range 0xfec10000-0xfec1ffff has been reserved
system 00:00: iomem range 0xfeda0000-0xfedbffff has been reserved
system 00:00: iomem range 0xfec00000-0xfec00fff could not be reserved
system 00:00: iomem range 0xfee00000-0xfee00fff has been reserved
system 00:00: iomem range 0xffb00000-0xffbfffff has been reserved
system 00:00: iomem range 0xffe80000-0xffffffff has been reserved
system 00:08: ioport range 0x1e0-0x1ef has been reserved
system 00:08: ioport range 0x480-0x48f has been reserved
system 00:08: ioport range 0x680-0x6ff has been reserved
system 00:08: ioport range 0x800-0x80f has been reserved
system 00:08: ioport range 0xd800-0xd87f has been reserved
system 00:08: ioport range 0xd880-0xd89f has been reserved
system 00:08: ioport range 0xd8a0-0xd8bf has been reserved
system 00:08: ioport range 0xe000-0xe07f has been reserved
system 00:08: ioport range 0xe080-0xe0ff has been reserved
system 00:08: ioport range 0xe400-0xe47f has been reserved
system 00:08: ioport range 0xe480-0xe4ff has been reserved
system 00:08: ioport range 0xe800-0xe87f has been reserved
system 00:08: ioport range 0xe880-0xe8ff has been reserved
system 00:08: ioport range 0xec00-0xec7f has been reserved
system 00:08: ioport range 0xec80-0xecff has been reserved
system 00:08: ioport range 0xeeac-0xeeac has been reserved
system 00:08: ioport range 0xeeb0-0xeebf has been reserved
system 00:08: ioport range 0xeec0-0xeeff has been reserved
system 00:08: ioport range 0x4d0-0x4d1 has been reserved
pci 0000:01:0b.0: CardBus bridge, secondary bus 0000:02
pci 0000:01:0b.0: IO window: 0x00c000-0x00c0ff
pci 0000:01:0b.0: IO window: 0x00c400-0x00c4ff
pci 0000:01:0b.0: PREFETCH window: 0x28000000-0x2bffffff
pci 0000:01:0b.0: MEM window: 0x30000000-0x33ffffff
pci 0000:00:1e.0: PCI bridge, secondary bus 0000:01
pci 0000:00:1e.0: IO window: 0xc000-0xcfff
pci 0000:00:1e.0: MEM window: 0xcff00000-0xcfffffff
pci 0000:00:1e.0: PREFETCH window: 0x28000000-0x2bffffff
pci 0000:00:1e.0: setting latency timer to 64
pci 0000:01:0b.0: enabling device (0000 -> 0003)
pci 0000:01:0b.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
pci_bus 0000:00: resource 0 io: [0x00-0xffff]
pci_bus 0000:00: resource 1 mem: [0x000000-0xffffffff]
pci_bus 0000:01: resource 0 io: [0xc000-0xcfff]
pci_bus 0000:01: resource 1 mem: [0xcff00000-0xcfffffff]
pci_bus 0000:01: resource 2 pref mem [0x28000000-0x2bffffff]
pci_bus 0000:01: resource 3 io: [0x00-0xffff]
pci_bus 0000:01: resource 4 mem: [0x000000-0xffffffff]
pci_bus 0000:02: resource 0 io: [0xc000-0xc0ff]
pci_bus 0000:02: resource 1 io: [0xc400-0xc4ff]
pci_bus 0000:02: resource 2 pref mem [0x28000000-0x2bffffff]
pci_bus 0000:02: resource 3 mem: [0x30000000-0x33ffffff]
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 5, 131072 bytes)
TCP bind hash table entries: 16384 (order: 5, 131072 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
TCP reno registered
NET: Registered protocol family 1
Trying to unpack rootfs image as initramfs...
Freeing initrd memory: 3916k freed
Simple Boot Flag at 0x7c set to 0x1
audit: initializing netlink socket (disabled)
type=2000 audit(1254294277.285:1): initialized
VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
msgmni has been set to 972
alg: No test for stdrng (krng)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
pci 0000:00:02.0: Boot video device
pci 0000:01:08.0: Firmware left e100 interrupts enabled; disabling
vesafb: framebuffer at 0xd8000000, mapped to 0xdf780000, using 3072k, total 16192k
vesafb: mode is 1024x768x16, linelength=2048, pages=9
vesafb: scrolling: redraw
vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
Console: switching to colour frame buffer device 128x48
fb0: VESA VGA frame buffer device
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
serial 0000:00:1f.6: power state changed by ACPI to D0
serial 0000:00:1f.6: enabling device (0000 -> 0001)
serial 0000:00:1f.6: PCI INT B -> GSI 17 (level, low) -> IRQ 17
serial 0000:00:1f.6: PCI INT B disabled
brd: module loaded
e100: Intel(R) PRO/100 Network Driver, 3.5.24-k2-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
e100 0000:01:08.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
e100 0000:01:08.0: PME# disabled
e100: eth0: e100_probe: addr 0xcffff000, irq 20, MAC addr 00:08:0d:17:bf:f5
console [netcon0] enabled
netconsole: network logging started
PNP: PS/2 Controller [PNP0303:KBC,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
cpuidle: using governor ladder
cpuidle: using governor menu
TCP bic registered
NET: Registered protocol family 17
Using IPI No-Shortcut mode
Freeing unused kernel memory: 324k freed
input: AT Translated Set 2 keyboard as /class/input/input0
fan PNP0C0B:00: registered as cooling_device0
ACPI: Fan [FAN] (off)
thermal LNXTHERM:01: registered as thermal_zone0
ACPI: Thermal Zone [THRM] (43 C)
Switched to high resolution mode on CPU 0
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Uniform Multi-Platform E-IDE driver
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci_hcd 0000:00:1d.7: enabling device (0000 -> 0002)
ehci_hcd 0000:00:1d.7: PCI INT D -> GSI 23 (level, low) -> IRQ 23
ehci_hcd 0000:00:1d.7: setting latency timer to 64
ehci_hcd 0000:00:1d.7: EHCI Host Controller
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:1d.7: debug port 1
ehci_hcd 0000:00:1d.7: cache line size of 128 is not supported
ehci_hcd 0000:00:1d.7: irq 23, io mem 0x2c080000
ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 6 ports detected
piix 0000:00:1f.1: IDE controller (0x8086:0x24ca rev 0x03)
PIIX_IDE 0000:00:1f.1: PCI INT A -> GSI 18 (level, low) -> IRQ 18
piix 0000:00:1f.1: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xbfa0-0xbfa7
ide1: BM-DMA at 0xbfa8-0xbfaf
Probing IDE interface ide0...
uhci_hcd: USB Universal Host Controller Interface driver
hda: HTS541080G9AT00, ATA DISK drive
hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
hda: UDMA/100 mode selected
Probing IDE interface ide1...
hdc: TOSHIBA DVD-ROM SD-R6112, ATAPI CD/DVD-ROM drive
hdc: host max PIO4 wanted PIO255(auto-tune) selected PIO4
hdc: UDMA/33 mode selected
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
uhci_hcd 0000:00:1d.0: setting latency timer to 64
uhci_hcd 0000:00:1d.0: UHCI Host Controller
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:1d.0: irq 16, io base 0x000018c0
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 19 (level, low) -> IRQ 19
uhci_hcd 0000:00:1d.1: setting latency timer to 64
uhci_hcd 0000:00:1d.1: UHCI Host Controller
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:1d.1: irq 19, io base 0x000018e0
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
SCSI subsystem initialized
libata version 3.00 loaded.
ide-gd driver 1.18
hda: max request size: 512KiB
ide-cd driver 5.00
hda: 156301488 sectors (80026 MB) w/7539KiB Cache, CHS=16383/255/63
hda: cache flushes supported
hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 >
ide-cd: hdc: ATAPI 24X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache
Uniform CD-ROM driver Revision: 3.20
device-mapper: ioctl: 4.15.0-ioctl (2009-04-01) initialised: dm-devel@redhat.com
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
udevd version 125 started
Marking TSC unstable due to TSC halts in idle
processor LNXCPU:00: registered as cooling_device1
Switching to clocksource acpi_pm
input: Lid Switch as /class/input/input1
ACPI: Lid Switch [LID]
input: Power Button as /class/input/input2
ACPI: Power Button [PWRB]
input: Power Button as /class/input/input3
ACPI: Power Button [PWRF]
Linux agpgart interface v0.103
ACPI: AC Adapter [ADP1] (on-line)
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
ACPI Warning for \_SB_.BAT1._BIF: Converted Buffer to expected String at index 9 (20090903/nsrepair-132)
ACPI Warning for \_SB_.BAT1._BIF: Converted Buffer to expected String at index 10 (20090903/nsrepair-132)
ACPI Warning for \_SB_.BAT1._BIF: Converted Buffer to expected String at index 11 (20090903/nsrepair-132)
ACPI Warning for \_SB_.BAT1._BIF: Return Package type mismatch at index 12 - found Integer, expected String (20090903/nspredef-1012)
agpgart-intel 0000:00:00.0: Intel 855GM Chipset
agpgart-intel 0000:00:00.0: detected 16252K stolen memory
agpgart-intel 0000:00:00.0: AGP aperture is 128M @ 0xd8000000
ACPI: Battery Slot [BAT1] (battery present)
shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[Firmware Bug]: ACPI: ACPI brightness control misses _BQC function
acpi device:0d: registered as cooling_device2
input: Video Bus as /class/input/input4
ACPI: Video Device [VGA] (multi-head: yes rom: yes post: no)
input: Toshiba input device as /class/input/input5
toshiba_acpi: Toshiba Laptop ACPI Extras version 0.19
toshiba_acpi: HCI method: \_SB_.VALZ.GHCI
parport_pc 00:09: activated
parport_pc 00:09: reported by Plug and Play ACPI
parport0: PC-style at 0x378 (0x778), irq 7, dma 1 [PCSPP,TRISTATE,COMPAT,ECP,DMA]
input: PC Speaker as /class/input/input6
Driver 'rtc_cmos' needs updating - please use bus_type methods
rtc_cmos 00:07: RTC can wake from S4
rtc_cmos 00:07: rtc core: registered rtc_cmos as rtc0
rtc0: alarms up to one year, 114 bytes nvram
yenta_cardbus 0000:01:0b.0: CardBus bridge found [1179:0001]
yenta_cardbus 0000:01:0b.0: ISA IRQ mask 0x0c38, PCI irq 18
yenta_cardbus 0000:01:0b.0: Socket status: 30000020
yenta_cardbus 0000:01:0b.0: pcmcia: parent PCI bridge I/O window: 0xc000 - 0xcfff
pcmcia_socket pcmcia_socket0: cs: IO port probe 0xc000-0xcfff: clean.
yenta_cardbus 0000:01:0b.0: pcmcia: parent PCI bridge Memory window: 0xcff00000 - 0xcfffffff
yenta_cardbus 0000:01:0b.0: pcmcia: parent PCI bridge Memory window: 0x28000000 - 0x2bffffff
Intel ICH 0000:00:1f.5: power state changed by ACPI to D0
Intel ICH 0000:00:1f.5: enabling device (0000 -> 0003)
Intel ICH 0000:00:1f.5: PCI INT B -> GSI 17 (level, low) -> IRQ 17
Intel ICH 0000:00:1f.5: setting latency timer to 64
input: PS/2 Mouse as /class/input/input7
input: AlpsPS/2 ALPS GlidePoint as /class/input/input8
pcmcia_socket pcmcia_socket0: pccard: CardBus card inserted into slot 0
pci 0000:02:00.0: reg 10 32bit mmio: [0x000000-0x00ffff]
cfg80211: Using static regulatory domain info
cfg80211: Regulatory domain: EU
(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
(2402000 KHz - 2482000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
(5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
(5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
(5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
(5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
(5490000 KHz - 5710000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
cfg80211: Calling CRDA for country: EU
cfg80211: Calling CRDA for country: EU
pcmcia_socket pcmcia_socket0: cs: IO port probe 0x100-0x3af: clean.
pcmcia_socket pcmcia_socket0: cs: IO port probe 0x3e0-0x4ff: clean.
pcmcia_socket pcmcia_socket0: cs: IO port probe 0x820-0x8ff: clean.
pcmcia_socket pcmcia_socket0: cs: IO port probe 0xc00-0xcf7: clean.
pcmcia_socket pcmcia_socket0: cs: IO port probe 0xa00-0xaff: clean.
ath5k 0000:02:00.0: enabling device (0000 -> 0002)
ath5k 0000:02:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
ath5k 0000:02:00.0: registered as 'phy0'
ath: EEPROM regdomain: 0x30
ath: EEPROM indicates we should expect a direct regpair map
ath: Country alpha2 being used: AM
ath: Regpair used: 0x30
phy0: Selected rate control algorithm 'minstrel'
ath5k phy0: Atheros AR5213A chip found (MAC: 0x59, PHY: 0x43)
ath5k phy0: RF2112B 2GHz radio found (0x46)
cfg80211: Calling CRDA for country: AM
udev: renamed network interface wlan0 to ath0
intel8x0_measure_ac97_clock: measured 55296 usecs (2664 samples)
intel8x0: clocking to 48000
Intel ICH Modem 0000:00:1f.6: PCI INT B -> GSI 17 (level, low) -> IRQ 17
Intel ICH Modem 0000:00:1f.6: setting latency timer to 64
EXT3 FS on dm-1, internal journal
padlock: VIA PadLock not detected.
padlock: VIA PadLock Hash Engine not detected.
loop: module loaded
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
kjournald starting. Commit interval 5 seconds
EXT3 FS on dm-7, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on dm-5, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on dm-2, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on dm-3, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
Adding 1048568k swap on /dev/mapper/strider-swap_crypt. Priority:-1 extents:1 across:1048568k
ADDRCONF(NETDEV_UP): ath0: link is not ready
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
lp0: using parport0 (interrupt-driven).
ppdev: user-space parallel port driver
ADDRCONF(NETDEV_UP): eth0: link is not ready
ADDRCONF(NETDEV_UP): eth0: link is not ready
CPUFREQ: Per core ondemand sysfs interface is deprecated - up_threshold
CPUFREQ: Per core ondemand sysfs interface is deprecated - ignore_nice_load
ADDRCONF(NETDEV_UP): ath0: link is not ready
ath0: deauthenticating by local choice (reason=3)
ath0: direct probe to AP 00:14:c1:38:e5:15 (try 1)
ath0: direct probe to AP 00:14:c1:38:e5:15 (try 2)
ath0 direct probe responded
ath0: authenticate with AP 00:14:c1:38:e5:15 (try 1)
ath0: authenticated
ath0: associate with AP 00:14:c1:38:e5:15 (try 1)
ath0: RX AssocResp from 00:14:c1:38:e5:15 (capab=0x411 status=0 aid=2)
ath0: associated
ADDRCONF(NETDEV_CHANGE): ath0: link becomes ready
ath0: deauthenticating by local choice (reason=3)
ath0: direct probe to AP 00:14:c1:38:e5:15 (try 1)
ath0 direct probe responded
ath0: authenticate with AP 00:14:c1:38:e5:15 (try 1)
ath0: authenticated
ath0: associate with AP 00:14:c1:38:e5:15 (try 1)
ath0: RX ReassocResp from 00:14:c1:38:e5:15 (capab=0x411 status=0 aid=2)
ath0: associated
ath0: deauthenticating by local choice (reason=3)
ath0: direct probe to AP 00:14:c1:38:e5:15 (try 1)
ath0 direct probe responded
ath0: authenticate with AP 00:14:c1:38:e5:15 (try 1)
ath0: authenticated
ath0: associate with AP 00:14:c1:38:e5:15 (try 1)
ath0: RX ReassocResp from 00:14:c1:38:e5:15 (capab=0x411 status=0 aid=2)
ath0: associated
ath0: deauthenticating by local choice (reason=3)
ath0: direct probe to AP 00:14:c1:38:e5:15 (try 1)
ath0 direct probe responded
ath0: authenticate with AP 00:14:c1:38:e5:15 (try 1)
ath0: authenticated
ath0: associate with AP 00:14:c1:38:e5:15 (try 1)
ath0: RX ReassocResp from 00:14:c1:38:e5:15 (capab=0x411 status=0 aid=2)
ath0: associated
ath0: deauthenticating by local choice (reason=3)
ath0: direct probe to AP 00:14:c1:38:e5:15 (try 1)
ath0 direct probe responded
ath0: authenticate with AP 00:14:c1:38:e5:15 (try 1)
ath0: authenticated
ath0: associate with AP 00:14:c1:38:e5:15 (try 1)
ath0: RX ReassocResp from 00:14:c1:38:e5:15 (capab=0x411 status=0 aid=2)
ath0: associated
ath0: deauthenticating by local choice (reason=3)
ath0: direct probe to AP 00:14:c1:38:e5:15 (try 1)
ath0 direct probe responded
ath0: authenticate with AP 00:14:c1:38:e5:15 (try 1)
ath0: authenticated
ath0: associate with AP 00:14:c1:38:e5:15 (try 1)
ath0: RX ReassocResp from 00:14:c1:38:e5:15 (capab=0x411 status=0 aid=2)
ath0: associated
ath0: deauthenticating by local choice (reason=3)
ath0: direct probe to AP 00:14:c1:38:e5:15 (try 1)
ath0 direct probe responded
ath0: authenticate with AP 00:14:c1:38:e5:15 (try 1)
ath0: authenticated
ath0: associate with AP 00:14:c1:38:e5:15 (try 1)
ath0: RX ReassocResp from 00:14:c1:38:e5:15 (capab=0x411 status=0 aid=2)
ath0: associated
ath0: deauthenticating by local choice (reason=3)
^ permalink raw reply
* ar9170usb and Fritz! USB: LEDs are confused
From: Malte Gell @ 2009-09-30 9:55 UTC (permalink / raw)
To: linux-wireless
Hi there!
Thanx for your work, finally my Firtz! USB n stick works now.
But, just one little, very minor thing. The LEDs are confused ;-) This stick
has two LEDs, a green one and a orange one. The green says "connected and
working", the orange only flashes when data is being transmitted.
But, with compat-wireless-2009-09-29 it is just vice very :-) The orange LED
is always on and the green one flashes when data is transmitted :-) It should
be the other way.
It's not very important, just wanted to say it.
Thanx
Malte
^ permalink raw reply
* Re: Disassociating atheros wlan with 2.6.31
From: Kristoffer Ericson @ 2009-09-30 10:53 UTC (permalink / raw)
To: Justin P. Mattock
Cc: Stefan Lippers-Hollmann, linux-wireless,
linux-kernel@vger.kernel.org
In-Reply-To: <4ABBD170.6060702@gmail.com>
On Thu, 24 Sep 2009 13:07:12 -0700
"Justin P. Mattock" <justinmattock@gmail.com> wrote:
> Stefan Lippers-Hollmann wrote:
> > Hi
> >
> > CCing linux-wireless@vger.kernel.org, as it's not very likely to get
> > noticed here by wireless developers.
> >
> > On Thursday 24 September 2009, Justin P. Mattock wrote:
> >
> >> Kristoffer Ericson wrote:
> >>
> >>> Greetings,
> >>>
> >>> When moving from vanilla 2.6.30->2.6.31 I noticed that I get dissasociated from
> >>> my wlan hub with regular intervalls. This did not happen on 2.6.30.
> >>> I cant see any pattern aside from that it happens at regular intervalls
> >>> (around 10-15mins). It works again when I re-identifies myself.
> >>>
> >>> Got an Asus 1000HE with Atheros chipset.
> >>> Havent had time to bisect it, just wanted to check
> >>> if this is an known issue. Ive ruled out faulty wlan hub
> >>> since everything works fine when going back to 2.6.30.
> >>>
> >>> nothing much on dmesg:
> >>> uhci_hcd 0000:00:1d.1: UHCI Host Controller
> >>> uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
> >>> uhci_hcd 0000:00:1d.1: irq 19, io base 0x0000d480
> >>> usb usb3: configuration #1 chosen from 1 choice
> >>> hub 3-0:1.0: USB hub found
> >>> hub 3-0:1.0: 2 ports detected
> >>> uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
> >>> uhci_hcd 0000:00:1d.2: setting latency timer to 64
> >>> uhci_hcd 0000:00:1d.2: UHCI Host Controller
> >>> uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
> >>> uhci_hcd 0000:00:1d.2: irq 18, io base 0x0000d800
> >>> usb usb4: configuration #1 chosen from 1 choice
> >>> hub 4-0:1.0: USB hub found
> >>> hub 4-0:1.0: 2 ports detected
> >>> uhci_hcd 0000:00:1d.3: PCI INT D -> GSI 16 (level, low) -> IRQ 16
> >>> uhci_hcd 0000:00:1d.3: setting latency timer to 64
> >>> uhci_hcd 0000:00:1d.3: UHCI Host Controller
> >>> uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 5
> >>> uhci_hcd 0000:00:1d.3: irq 16, io base 0x0000d880
> >>> usb usb5: configuration #1 chosen from 1 choice
> >>> hub 5-0:1.0: USB hub found
> >>> hub 5-0:1.0: 2 ports detected
> >>> input: ETPS/2 Elantech Touchpad as /devices/platform/i8042/serio1/input/input7
> >>> usb 1-4: new high speed USB device using ehci_hcd and address 3
> >>> usb 1-4: configuration #1 chosen from 1 choice
> >>> hub 1-4:1.0: USB hub found
> >>> hub 1-4:1.0: 4 ports detected
> >>> usb 1-5: new high speed USB device using ehci_hcd and address 4
> >>> usb 1-5: configuration #1 chosen from 1 choice
> >>> usb 1-8: new high speed USB device using ehci_hcd and address 6
> >>> usb 1-8: configuration #1 chosen from 1 choice
> >>> Initializing USB Mass Storage driver...
> >>> scsi4 : SCSI emulation for USB Mass Storage devices
> >>> usbcore: registered new interface driver usb-storage
> >>> USB Mass Storage support registered.
> >>> usb-storage: device found at 4
> >>> usb-storage: waiting for device to settle before scanning
> >>> HDA Intel 0000:00:1b.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
> >>> HDA Intel 0000:00:1b.0: setting latency timer to 64
> >>> usb 2-2: new full speed USB device using uhci_hcd and address 2
> >>> ath9k 0000:01:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
> >>> ath9k 0000:01:00.0: setting latency timer to 64
> >>> usb 2-2: configuration #1 chosen from 1 choice
> >>> input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:1b.0/input/input8
> >>> usbcore: registered new interface driver usbserial
> >>> USB Serial support registered for generic
> >>> usb 5-1: new full speed USB device using uhci_hcd and address 2
> >>> usb 5-1: configuration #1 chosen from 1 choice
> >>> usb 1-4.1: new full speed USB device using ehci_hcd and address 7
> >>> ath: EEPROM regdomain: 0x60
> >>> ath: EEPROM indicates we should expect a direct regpair map
> >>> ath: Country alpha2 being used: 00
> >>> ath: Regpair used: 0x60
> >>> Bluetooth: Core ver 2.15
> >>> NET: Registered protocol family 31
> >>> Bluetooth: HCI device and connection manager initialized
> >>> Bluetooth: HCI socket layer initialized
> >>> Bluetooth: Generic Bluetooth USB driver ver 0.5
> >>> usb 1-4.1: configuration #1 chosen from 1 choice
> >>> usb 1-4.2: new low speed USB device using ehci_hcd and address 8
> >>> usb 1-4.2: configuration #1 chosen from 1 choice
> >>> usb 1-4.4: new low speed USB device using ehci_hcd and address 9
> >>> usbcore: registered new interface driver hiddev
> >>> input: HID 04d9:1203 as /devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4.2/1-4.2:1.0/input/input9
> >>> generic-usb 0003:04D9:1203.0001: input,hidraw0: USB HID v1.11 Keyboard [HID 04d9:1203] on usb-0000:00:1d.7-4.2/input0
> >>> input: HID 04d9:1203 as /devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4.2/1-4.2:1.1/input/input10
> >>> generic-usb 0003:04D9:1203.0002: input,hidraw1: USB HID v1.11 Device [HID 04d9:1203] on usb-0000:00:1d.7-4.2/input1
> >>> usbcore: registered new interface driver usbhid
> >>> usbhid: v2.6:USB HID core driver
> >>> usb 1-4.4: configuration #1 chosen from 1 choice
> >>> input: B16_b_02 USB-PS/2 Optical Mouse as /devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4.4/1-4.4:1.0/input/input11
> >>> generic-usb 0003:046D:C025.0003: input,hidraw2: USB HID v1.10 Mouse [B16_b_02 USB-PS/2 Optical Mouse] on usb-0000:00:1d.7-4.4/input0
> >>> usbcore: registered new interface driver btusb
> >>> usbcore: registered new interface driver usbserial_generic
> >>> usbserial: USB Serial Driver core
> >>> USB Serial support registered for GSM modem (1-port)
> >>> option 2-2:1.0: GSM modem (1-port) converter detected
> >>> usb 2-2: GSM modem (1-port) converter now attached to ttyUSB0
> >>> option 2-2:1.1: GSM modem (1-port) converter detected
> >>> usb 2-2: GSM modem (1-port) converter now attached to ttyUSB1
> >>> usbcore: registered new interface driver option
> >>> option: v0.7.2:USB Driver for GSM modems
> >>> USB Serial support registered for pl2303
> >>> pl2303 1-4.1:1.0: pl2303 converter detected
> >>> usb 1-4.1: pl2303 converter now attached to ttyUSB2
> >>> usbcore: registered new interface driver pl2303
> >>> pl2303: Prolific PL2303 USB to serial adaptor driver
> >>> phy0: Selected rate control algorithm 'ath9k_rate_control'
> >>> Registered led device: ath9k-phy0::radio
> >>> Registered led device: ath9k-phy0::assoc
> >>> Registered led device: ath9k-phy0::tx
> >>> Registered led device: ath9k-phy0::rx
> >>> phy0: Atheros AR9280 MAC/BB Rev:2 AR5133 RF Rev:d0: mem=0xf8880000, irq=19
> >>> scsi 4:0:0:0: Direct-Access Single Flash Reader 1.00 PQ: 0 ANSI: 0
> >>> sd 4:0:0:0: Attached scsi generic sg1 type 0
> >>> sd 4:0:0:0: [sdb] 15954944 512-byte logical blocks: (8.16 GB/7.60 GiB)
> >>> usb-storage: device scan complete
> >>> sd 4:0:0:0: [sdb] Write Protect is off
> >>> sd 4:0:0:0: [sdb] Mode Sense: 03 00 00 00
> >>> sd 4:0:0:0: [sdb] Assuming drive cache: write through
> >>> sd 4:0:0:0: [sdb] Assuming drive cache: write through
> >>> sdb: sdb1
> >>> sd 4:0:0:0: [sdb] Assuming drive cache: write through
> >>> sd 4:0:0:0: [sdb] Attached SCSI removable disk
> >>> EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
> >>> EXT3 FS on sda1, internal journal
> >>> Bluetooth: L2CAP ver 2.13
> >>> Bluetooth: L2CAP socket layer initialized
> >>> Bluetooth: SCO (Voice Link) ver 0.6
> >>> Bluetooth: SCO socket layer initialized
> >>> Bluetooth: BNEP (Ethernet Emulation) ver 1.3
> >>> Bridge firewalling registered
> >>> Bluetooth: RFCOMM TTY layer initialized
> >>> Bluetooth: RFCOMM socket layer initialized
> >>> Bluetooth: RFCOMM ver 1.11
> >>> ATL1E 0000:03:00.0: irq 27 for MSI/MSI-X
> >>> fuse init (API version 7.12)
> >>> ip_tables: (C) 2000-2006 Netfilter Core Team
> >>> nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
> >>> CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use
> >>> nf_conntrack.acct=1 kernel parameter, acct=1 nf_conntrack module option or
> >>> sysctl net.netfilter.nf_conntrack_acct=1 to enable it.
> >>> wlan0: authenticate with AP 00:14:7c:ae:d1:90
> >>> wlan0: authenticated
> >>> wlan0: associate with AP 00:14:7c:ae:d1:90
> >>> wlan0: RX AssocResp from 00:14:7c:ae:d1:90 (capab=0x431 status=0 aid=5)
> >>> wlan0: associated
> >>> PPP generic driver version 2.4.2
> >>> NET: Registered protocol family 10
> >>> lo: Disabled Privacy Extensions
> >>> ADDRCONF(NETDEV_UP): eth0: link is not ready
> >>> PPP BSD Compression module registered
> >>> PPP Deflate Compression module registered
> >>> wlan0: no IPv6 routers present
> >>> CE: hpet increasing min_delta_ns to 15000 nsec
> >>> wlan0: no probe response from AP 00:14:7c:ae:d1:90 - disassociating
> >>> wlan0: authenticate with AP 00:14:7c:ae:d1:90
> >>> wlan0: authenticated
> >>> wlan0: associate with AP 00:14:7c:ae:d1:90
> >>> wlan0: RX AssocResp from 00:14:7c:ae:d1:90 (capab=0x431 status=0 aid=5)
> >>> wlan0: associated
> >>> wlan0: authenticate with AP 00:14:7c:ae:d1:90
> >>> wlan0: authenticated
> >>> wlan0: associate with AP 00:14:7c:ae:d1:90
> >>> wlan0: RX AssocResp from 00:14:7c:ae:d1:90 (capab=0x431 status=0 aid=5)
> >>> wlan0: associated
> >>> [kristoffer@boggieman wine.git]$
> >>>
> >>>
> >>>
> >>>
> >> yeah I'm seeing this with my macbook pro(ath9k)
> >> while streaming music, all of a sudden things just crap out.
> >> (not sure if this is why, or something else).
> >>
> >> Justin P. Mattock
> >>
> >
> > I'm getting similar reports for iwl3945 and 2.6.31.[01], but can't confirm
> > this on my own (non-iwl{3945,agn}, non-ath9k) hardware yet.
> >
> > Regards
> > Stefan Lippers-Hollmann
> >
> >
> I don't mind doing a bisect from 30 - present, but first I need to
> do some other stuff.
>
Just tried 2.6.31.1 and getting same issues as I got from
2.6.31. Interesting is also that at first disassociation I can
re-activate it by authorizing again with the hub. The second time
around though that doesnt work.
> Justin P. Mattock
--
Kristoffer Ericson <kristoffer.ericson@gmail.com>
^ permalink raw reply
* B43 Module on Compaq HP615 Laptop
From: Reiner Schmidt @ 2009-09-30 11:04 UTC (permalink / raw)
To: linux-wireless
Hello,
I am trying to install the newest compat-wireless package (from 30.09.2009)
onto this notebook. It has a Broadcom 4312 compatible WLAN device on it .
Its id is:14e4:4315.
I use s debian sidux distribution with an 2.6.29-4 liquorix-kernel.
Unfortunately I can currently use newer kernels on this notebook because it
wouldn't boot up. Tried several 2.6.30 and -31 kernels up too 2.6.31-1.
Compiling the package works so far but when loading the module b43 manually or
via /etc/modules it complains heavily about ssb-related issues.
> b43: disagrees about version of symbol ssb_device_is_enabled
> b43: Unknown symbol ssb_device_is_enabled
> b43: Unknown symbol ssb_pmu_set_ldo_paref
> b43: disagrees about version of symbol ssb_pcicore_dev_irqvecs_enable
> b43: Unknown symbol ssb_pcicore_dev_irqvecs_enable
> b43: disagrees about version of symbol ssb_bus_may_powerdown
> b43: Unknown symbol ssb_bus_may_powerdown
> b43: disagrees about version of symbol ssb_dma_free_consistent
> b43: Unknown symbol ssb_dma_free_consistent
> b43: disagrees about version of symbol ssb_bus_suspend
> b43: Unknown symbol ssb_bus_suspend
> b43: disagrees about version of symbol ssb_bus_unregister
> b43: Unknown symbol ssb_bus_unregister
> b43: disagrees about version of symbol ssb_bus_resume
> b43: Unknown symbol ssb_bus_resume
> b43: disagrees about version of symbol ssb_set_devtypedata
> b43: Unknown symbol ssb_set_devtypedata
> b43: disagrees about version of symbol ssb_device_disable
> b43: Unknown symbol ssb_device_disable
> b43: Unknown symbol ssb_pmu_set_ldo_voltage
> b43: disagrees about version of symbol ssb_dma_alloc_consistent
> b43: Unknown symbol ssb_dma_alloc_consistent
> b43: disagrees about version of symbol ssb_dma_set_mask
> b43: Unknown symbol ssb_dma_set_mask
> b43: disagrees about version of symbol ssb_device_enable
> b43: Unknown symbol ssb_device_enable
> b43: disagrees about version of symbol ssb_driver_unregister
> b43: Unknown symbol ssb_driver_unregister
> b43: disagrees about version of symbol __ssb_driver_register
> b43: Unknown symbol __ssb_driver_register
> b43: disagrees about version of symbol ssb_bus_pcmciabus_register
> b43: Unknown symbol ssb_bus_pcmciabus_register
> b43: disagrees about version of symbol ssb_bus_powerup
> b43: Unknown symbol ssb_bus_powerup
> b43: disagrees about version of symbol ssb_dma_translation
> b43: Unknown symbol ssb_dma_translation
Is this a real bug or do Ihave to submit additional prameter for the module
when I load it?
If so, where can I find those otions ?
Kind regards
Reiner Schmidt
^ permalink raw reply
* Re: B43 Module on Compaq HP615 Laptop
From: Gábor Stefanik @ 2009-09-30 11:18 UTC (permalink / raw)
To: Reiner Schmidt; +Cc: linux-wireless
In-Reply-To: <200909301304.33903.schmidtreiner@gmx.net>
You need to unload the old ssb prior to loading b43 (which loads an
updated ssb).
On Wed, Sep 30, 2009 at 1:04 PM, Reiner Schmidt <schmidtreiner@gmx.net> wrote:
> Hello,
> I am trying to install the newest compat-wireless package (from 30.09.2009)
> onto this notebook. It has a Broadcom 4312 compatible WLAN device on it .
> Its id is:14e4:4315.
> I use s debian sidux distribution with an 2.6.29-4 liquorix-kernel.
> Unfortunately I can currently use newer kernels on this notebook because it
> wouldn't boot up. Tried several 2.6.30 and -31 kernels up too 2.6.31-1.
Please report any error messages it prints.
>
> Compiling the package works so far but when loading the module b43 manually or
> via /etc/modules it complains heavily about ssb-related issues.
>
>
>> b43: disagrees about version of symbol ssb_device_is_enabled
>> b43: Unknown symbol ssb_device_is_enabled
>> b43: Unknown symbol ssb_pmu_set_ldo_paref
>> b43: disagrees about version of symbol ssb_pcicore_dev_irqvecs_enable
>> b43: Unknown symbol ssb_pcicore_dev_irqvecs_enable
>> b43: disagrees about version of symbol ssb_bus_may_powerdown
>> b43: Unknown symbol ssb_bus_may_powerdown
>> b43: disagrees about version of symbol ssb_dma_free_consistent
>> b43: Unknown symbol ssb_dma_free_consistent
>> b43: disagrees about version of symbol ssb_bus_suspend
>> b43: Unknown symbol ssb_bus_suspend
>> b43: disagrees about version of symbol ssb_bus_unregister
>> b43: Unknown symbol ssb_bus_unregister
>> b43: disagrees about version of symbol ssb_bus_resume
>> b43: Unknown symbol ssb_bus_resume
>> b43: disagrees about version of symbol ssb_set_devtypedata
>> b43: Unknown symbol ssb_set_devtypedata
>> b43: disagrees about version of symbol ssb_device_disable
>> b43: Unknown symbol ssb_device_disable
>> b43: Unknown symbol ssb_pmu_set_ldo_voltage
>> b43: disagrees about version of symbol ssb_dma_alloc_consistent
>> b43: Unknown symbol ssb_dma_alloc_consistent
>> b43: disagrees about version of symbol ssb_dma_set_mask
>> b43: Unknown symbol ssb_dma_set_mask
>> b43: disagrees about version of symbol ssb_device_enable
>> b43: Unknown symbol ssb_device_enable
>> b43: disagrees about version of symbol ssb_driver_unregister
>> b43: Unknown symbol ssb_driver_unregister
>> b43: disagrees about version of symbol __ssb_driver_register
>> b43: Unknown symbol __ssb_driver_register
>> b43: disagrees about version of symbol ssb_bus_pcmciabus_register
>> b43: Unknown symbol ssb_bus_pcmciabus_register
>> b43: disagrees about version of symbol ssb_bus_powerup
>> b43: Unknown symbol ssb_bus_powerup
>> b43: disagrees about version of symbol ssb_dma_translation
>> b43: Unknown symbol ssb_dma_translation
>
> Is this a real bug or do Ihave to submit additional prameter for the module
> when I load it?
> If so, where can I find those otions ?
>
> Kind regards
>
> Reiner Schmidt
> --
> 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
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: mac80211: NOHZ: local_softirq_pending 08
From: Oliver Hartkopp @ 2009-09-30 11:56 UTC (permalink / raw)
To: John W. Linville
Cc: Michael Buesch, Kalle Valo, linux-wireless, netdev, Johannes Berg
In-Reply-To: <20090929192928.GF2678@tuxdriver.com>
John W. Linville wrote:
> On Sat, Sep 12, 2009 at 06:41:12PM +0200, Oliver Hartkopp wrote:
>
>> i cooked a patch that introduces netif_rx_ti() and fixes up the problems in
>> mac80211 and the CAN subsystem.
>
> Oliver,
>
> Are you going to send this patch to Dave? If you want me to carry
> it instead, please resend it with a proper changelog including a
> Signed-off-by line. For that matter, Dave will most certainly want
> that as well...
Hello John,
as i wrote here
http://marc.info/?l=linux-netdev&m=125277885910179&w=2
there are currently only three occurrences of checks that use netif_rx() and
netif_rx_ni() depending on in_interrupt().
And regarding the suggested fix from Michael, that checked every(!) netif_rx()
whether it is in interrupt or not, i was unsure if a netif_tx_ti() would make
sense for only three cases?!?
If you think it makes sense, i can post a patch for that ... but:
Indeed it costs some additional investigation to prove whether netif_rx() or
netif_rx_ni() should be used in each case. But IMHO this has to be done before
providing a pump-gun function that solves the problem without thinking if we
are in irq-context or not. I want to avoid that people are using netif_rx_ti()
as some kind of default ...
I don't know how expensive in_interrupt() is, but it IMO should be avoided
when the context for a code section can be determined in another way.
Regards,
Oliver
^ permalink raw reply
* Re: [.32-rc1/2] ath5k: has become unreliable with .32-rc1
From: Bob Copeland @ 2009-09-30 12:24 UTC (permalink / raw)
To: Frans Pop; +Cc: linux-wireless, linux-kernel
In-Reply-To: <200909300952.29106.elendil@planet.nl>
On Wed, Sep 30, 2009 at 09:52:27AM +0200, Frans Pop wrote:
> This is on a laptop I don't use much, but with .31 wireless has always
> been (and still is) reliable (.31-rc5 is the last kernel I built for it).
> On my other laptop wireless (iwlagn) works fine with .32-rc1.
Although iwlagn works, I would think this kind of thing:
> ath0: authenticated
> ath0: associate with AP 00:14:c1:38:e5:15 (try 1)
> ath0: RX ReassocResp from 00:14:c1:38:e5:15 (capab=0x411 status=0 aid=2)
> ath0: associated
> ath0: deauthenticating by local choice (reason=3)
> ath0: direct probe to AP 00:14:c1:38:e5:15 (try 1)
> ath0 direct probe responded
> ath0: authenticate with AP 00:14:c1:38:e5:15 (try 1)
> ath0: authenticated
> ath0: associate with AP 00:14:c1:38:e5:15 (try 1)
> ath0: RX ReassocResp from 00:14:c1:38:e5:15 (capab=0x411 status=0 aid=2)
...is some kind of issue with userspace or wext rather than the driver.
Ath5k only had a dozen or so patches this time around, so it should be
easy to bisect if it's a problem in the driver. One possibility is
hardware CCMP support but I've been using it here for some time.
By the way, name it what you will, but the standard is wlan0 these days :)
> So the difference looks to be how I boot: if I do a *cold* boot directly
> into .32, wireless fails; if I *reboot* from .31 into .32, wireless
> comes up correctly. Reboot from .32 to .32 fails too.
Is that repeatable?
Rafael J. Wysocki has a patch floating around to fix PCMCIA resume,
linked here: http://bugzilla.kernel.org/show_bug.cgi?id=13092
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: ath5k suspend
From: Daniel J Blueman @ 2009-09-30 12:36 UTC (permalink / raw)
To: Gonsolo; +Cc: kernel-team, Linux Kernel, linux-wireless
In-Reply-To: <4AC22B64.8050909@googlemail.com>
Hi Gonsolo,
On Tue, Sep 29, 2009 at 4:44 PM, Gonsolo <gonsolo@gmail.com> wrote:
> Hi!
>
> Is it possible to add
> http://patchwork.kernel.org/patch/38550/
> to karmic? Otherwise karmic would be broken for me/my notebook/my
> wireless pccard.
Since Karmic tracks the 2.6.31 -stable kernels, it's worth reporting
this upstream (CC'd) instead, particularly if it's a regression from a
previous kernel version, using the same ath5k driver...?
Then, it'll be in Karmic in ~ a few weeks.
Daniel
--
Daniel J Blueman
^ permalink raw reply
* [iw PATCH] default install to $(PREFIX)/sbin
From: John W. Linville @ 2009-09-30 13:19 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, John W. Linville
The iw utility isn't generally useful to normal users, so move it to
$(PREFIX)/sbin with other system management executables.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
As "suggested" by Johannes... :-)
Makefile | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index cb5fcc1..68bef4d 100644
--- a/Makefile
+++ b/Makefile
@@ -3,7 +3,7 @@
MAKEFLAGS += --no-print-directory
PREFIX ?= /usr
-BINDIR ?= $(PREFIX)/bin
+SBINDIR ?= $(PREFIX)/sbin
MANDIR ?= $(PREFIX)/share/man
PKG_CONFIG ?= pkg-config
@@ -85,8 +85,8 @@ check:
install: iw iw.8.gz
@$(NQ) ' INST iw'
- $(Q)$(MKDIR) $(DESTDIR)$(BINDIR)
- $(Q)$(INSTALL) -m 755 -t $(DESTDIR)$(BINDIR) iw
+ $(Q)$(MKDIR) $(DESTDIR)$(SBINDIR)
+ $(Q)$(INSTALL) -m 755 -t $(DESTDIR)$(SBINDIR) iw
@$(NQ) ' INST iw.8'
$(Q)$(MKDIR) $(DESTDIR)$(MANDIR)/man8/
$(Q)$(INSTALL) -m 644 -t $(DESTDIR)$(MANDIR)/man8/ iw.8.gz
--
1.6.2.5
^ permalink raw reply related
* Re: ath5k suspend
From: Gonsolo @ 2009-09-30 13:26 UTC (permalink / raw)
To: Daniel J Blueman; +Cc: Gonsolo, kernel-team, Linux Kernel, linux-wireless
In-Reply-To: <6278d2220909300536u7934d7dan286d219b5cf7e5a@mail.gmail.com>
>> Is it possible to add
>> http://patchwork.kernel.org/patch/38550/
>> to karmic? Otherwise karmic would be broken for me/my notebook/my
>> wireless pccard.
>
> Since Karmic tracks the 2.6.31 -stable kernels, it's worth reporting
> this upstream (CC'd) instead, particularly if it's a regression from a
> previous kernel version, using the same ath5k driver...?
I did that, too. ;) Hopefully it will be in 2.6.31.2.
g
^ permalink raw reply
* Re: [rfkill PATCH] default install to $(PREFIX)/sbin
From: John W. Linville @ 2009-09-30 13:30 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1254258160.30589.21.camel@johannes.local>
On Tue, Sep 29, 2009 at 11:02:40PM +0200, Johannes Berg wrote:
> On Tue, 2009-09-29 at 17:00 -0400, John W. Linville wrote:
> > On Tue, Sep 29, 2009 at 10:34:37PM +0200, Johannes Berg wrote:
> > > On Tue, 2009-09-29 at 13:41 -0400, John W. Linville wrote:
> > > > The rfkill utility isn't generally useful to normal users, so move it to
> > > > /sbin with other system management executables.
> > >
> > > Seems to me that it's kinda useful, it should be possible for most users
> > > to use the event and query interface if the /dev/rfkill permissions are
> > > set up correctly.
> >
> > Sure, but (just like ip, ifconfig, or iwconfig) nothing stops people
> > from using them in /sbin or /usr/sbin. It is just a convention for
> > tools that are more for system management than for day-to-day use.
> >
> > Hopefully most people will stick with NM or whatever and may stay
> > completely unaware of the rfkill utility. :-)
>
> So are you going to send an iw patch too? :-)
As you wish...on it's way!
> FWIW I like tools in bin/ since the default paths on most systems for
> users don't include sbin/.
FWIW, Fedora has been including it for normal users for a few
releases now.
I agree that it /bin vs /sbin is not strictly necessary, but it is
standard practice. I guess it does enable some users to either drop
those tools completely from their path or to order their path to
select alternate versions of tools for whatever reason. Whatever...
I think Fedora will move iw and rfkill to /sbin in any case.
This enables them to be used before /usr is mounted and makes sure
root has them early in his path. The posted patches are not strictly
necessary for that, but they slightly simplify the install process.
Plus, I think they are more compliant with standard practices.
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: ath5k suspend
From: John W. Linville @ 2009-09-30 14:09 UTC (permalink / raw)
To: Gonsolo; +Cc: Daniel J Blueman, kernel-team, Linux Kernel, linux-wireless
In-Reply-To: <4AC35CA0.5070401@googlemail.com>
On Wed, Sep 30, 2009 at 03:26:56PM +0200, Gonsolo wrote:
>>> Is it possible to add
>>> http://patchwork.kernel.org/patch/38550/
>>> to karmic? Otherwise karmic would be broken for me/my notebook/my
>>> wireless pccard.
>>
>> Since Karmic tracks the 2.6.31 -stable kernels, it's worth reporting
>> this upstream (CC'd) instead, particularly if it's a regression from a
>> previous kernel version, using the same ath5k driver...?
>
> I did that, too. ;) Hopefully it will be in 2.6.31.2.
Maybe I missed it, but did you actually request the -stable team to
take the patch? -stable helps more than just Ubuntu... :-)
Greg (or Chris or...), the patch in question is here:
commit edd7fc7003f31da48d06e215a93ea966a22c2a03
Author: Nick Kossifidis <mick@madwifi-project.org>
Date: Mon Aug 10 03:29:02 2009 +0300
ath5k: Wakeup fixes
* Don't put chip to full sleep because there are problems during
wakeup. Instead hold MAC/Baseband on warm reset state via a new
function ath5k_hw_on_hold.
* Minor cleanups
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Tested-by: Ben Greear <greearb@candelatech.com>
Tested-by: Johannes Stezenbach <js@sig21.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
--
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: ath5k suspend
From: Gonsolo @ 2009-09-30 14:25 UTC (permalink / raw)
To: John W. Linville
Cc: Gonsolo, Daniel J Blueman, kernel-team, Linux Kernel,
linux-wireless
In-Reply-To: <20090930140905.GA3193@tuxdriver.com>
Am 30.09.2009 16:09, schrieb John W. Linville:
> On Wed, Sep 30, 2009 at 03:26:56PM +0200, Gonsolo wrote:
>>>> Is it possible to add
>>>> http://patchwork.kernel.org/patch/38550/
>>>> to karmic? Otherwise karmic would be broken for me/my notebook/my
>>>> wireless pccard.
>>>
>>> Since Karmic tracks the 2.6.31 -stable kernels, it's worth reporting
>>> this upstream (CC'd) instead, particularly if it's a regression from a
>>> previous kernel version, using the same ath5k driver...?
>>
>> I did that, too. ;) Hopefully it will be in 2.6.31.2.
>
> Maybe I missed it, but did you actually request the -stable team to
> take the patch? -stable helps more than just Ubuntu... :-)
I requested it in Ubuntu and stable in two separate emails, just to be
sure it will be there when I am going to upgrade. ;)
I apologize if I caused confusion or doubled your amount of work.
Maybe I should have done this in one email to both parties.
g
^ permalink raw reply
* Re: ath5k suspend
From: John W. Linville @ 2009-09-30 14:29 UTC (permalink / raw)
To: Gonsolo; +Cc: Daniel J Blueman, kernel-team, Linux Kernel, linux-wireless
In-Reply-To: <4AC36A46.7010209@googlemail.com>
On Wed, Sep 30, 2009 at 04:25:10PM +0200, Gonsolo wrote:
> Am 30.09.2009 16:09, schrieb John W. Linville:
>> On Wed, Sep 30, 2009 at 03:26:56PM +0200, Gonsolo wrote:
>>>>> Is it possible to add
>>>>> http://patchwork.kernel.org/patch/38550/
>>>>> to karmic? Otherwise karmic would be broken for me/my notebook/my
>>>>> wireless pccard.
>>>>
>>>> Since Karmic tracks the 2.6.31 -stable kernels, it's worth reporting
>>>> this upstream (CC'd) instead, particularly if it's a regression from a
>>>> previous kernel version, using the same ath5k driver...?
>>>
>>> I did that, too. ;) Hopefully it will be in 2.6.31.2.
>>
>> Maybe I missed it, but did you actually request the -stable team to
>> take the patch? -stable helps more than just Ubuntu... :-)
>
> I requested it in Ubuntu and stable in two separate emails, just to be
> sure it will be there when I am going to upgrade. ;)
> I apologize if I caused confusion or doubled your amount of work.
> Maybe I should have done this in one email to both parties.
Not really a big deal -- still, one email would tend to reduce confusion. :-)
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: mac80211: NOHZ: local_softirq_pending 08
From: Michael Buesch @ 2009-09-30 14:33 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: John W. Linville, Kalle Valo, linux-wireless, netdev,
Johannes Berg
In-Reply-To: <4AC3475C.7000403@hartkopp.net>
On Wednesday 30 September 2009 13:56:12 Oliver Hartkopp wrote:
> John W. Linville wrote:
> > On Sat, Sep 12, 2009 at 06:41:12PM +0200, Oliver Hartkopp wrote:
> >
> >> i cooked a patch that introduces netif_rx_ti() and fixes up the problems in
> >> mac80211 and the CAN subsystem.
> >
> > Oliver,
> >
> > Are you going to send this patch to Dave? If you want me to carry
> > it instead, please resend it with a proper changelog including a
> > Signed-off-by line. For that matter, Dave will most certainly want
> > that as well...
>
> Hello John,
>
> as i wrote here
>
> http://marc.info/?l=linux-netdev&m=125277885910179&w=2
>
> there are currently only three occurrences of checks that use netif_rx() and
> netif_rx_ni() depending on in_interrupt().
>
> And regarding the suggested fix from Michael, that checked every(!) netif_rx()
> whether it is in interrupt or not, i was unsure if a netif_tx_ti() would make
> sense for only three cases?!?
>
> If you think it makes sense, i can post a patch for that ... but:
>
> Indeed it costs some additional investigation to prove whether netif_rx() or
> netif_rx_ni() should be used in each case. But IMHO this has to be done before
> providing a pump-gun function that solves the problem without thinking if we
> are in irq-context or not. I want to avoid that people are using netif_rx_ti()
> as some kind of default ...
>
> I don't know how expensive in_interrupt() is, but it IMO should be avoided
> when the context for a code section can be determined in another way.
What if we just get the fix merged and discuss later whether it's worth to optimize a picosecond or not??
My patch fixes the _bug_. You can merge a more "efficient" fix later that saves one or two CPU cycles.
--
Greetings, Michael.
^ permalink raw reply
* Re: mac80211: NOHZ: local_softirq_pending 08
From: Kalle Valo @ 2009-09-30 14:47 UTC (permalink / raw)
To: Michael Buesch
Cc: Oliver Hartkopp, John W. Linville, linux-wireless, netdev,
Johannes Berg
In-Reply-To: <200909301633.04376.mb@bu3sch.de>
Michael Buesch <mb@bu3sch.de> writes:
>> I don't know how expensive in_interrupt() is, but it IMO should be
>> avoided when the context for a code section can be determined in
>> another way.
>
> What if we just get the fix merged and discuss later whether it's
> worth to optimize a picosecond or not?? My patch fixes the _bug_.
> You can merge a more "efficient" fix later that saves one or two CPU
> cycles.
I agree with Michael. The bug is real and I have verified that
Michael's patch fixes the issue. Better to apply the patch now, it's
trivial to change the implementation if/when the network stack has
support for this.
--
Kalle Valo
^ permalink raw reply
* Re: mac80211: NOHZ: local_softirq_pending 08
From: Johannes Berg @ 2009-09-30 14:54 UTC (permalink / raw)
To: Kalle Valo
Cc: Michael Buesch, Oliver Hartkopp, John W. Linville, linux-wireless,
netdev
In-Reply-To: <87ocosqykb.fsf@purkki.valot.fi>
[-- Attachment #1: Type: text/plain, Size: 489 bytes --]
On Wed, 2009-09-30 at 17:47 +0300, Kalle Valo wrote:
> I agree with Michael. The bug is real and I have verified that
> Michael's patch fixes the issue. Better to apply the patch now, it's
> trivial to change the implementation if/when the network stack has
> support for this.
FWIW, I think in mac80211 the in_interrupt() check can never return true
since we postpone all RX to the tasklet. But the tasklet seems to be ok
-- so should it really be in_interrupt()?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: B43 Module on Compaq HP615 Laptop
From: Larry Finger @ 2009-09-30 15:01 UTC (permalink / raw)
To: Reiner Schmidt; +Cc: linux-wireless
In-Reply-To: <200909301304.33903.schmidtreiner@gmx.net>
Reiner Schmidt wrote:
> Hello,
> I am trying to install the newest compat-wireless package (from 30.09.2009)
> onto this notebook. It has a Broadcom 4312 compatible WLAN device on it .
> Its id is:14e4:4315.
> I use s debian sidux distribution with an 2.6.29-4 liquorix-kernel.
> Unfortunately I can currently use newer kernels on this notebook because it
> wouldn't boot up. Tried several 2.6.30 and -31 kernels up too 2.6.31-1.
>
> Compiling the package works so far but when loading the module b43 manually or
> via /etc/modules it complains heavily about ssb-related issues.
Some distros include b44 and ssb in their initrd so that the box can
netboot. It is likely that yours is one of them. In this case, this
means that the wrong ssb is already loaded when you try to load b43.
The solution that Gabor gave you is correct; however if you rebuild
mkinitrd after building the compat modules, then it should work.
Larry
^ permalink raw reply
* Re: mac80211: NOHZ: local_softirq_pending 08
From: Michael Buesch @ 2009-09-30 15:10 UTC (permalink / raw)
To: Johannes Berg
Cc: Kalle Valo, Oliver Hartkopp, John W. Linville, linux-wireless,
netdev
In-Reply-To: <1254322466.3959.5.camel@johannes.local>
On Wednesday 30 September 2009 16:54:26 Johannes Berg wrote:
> On Wed, 2009-09-30 at 17:47 +0300, Kalle Valo wrote:
>
> > I agree with Michael. The bug is real and I have verified that
> > Michael's patch fixes the issue. Better to apply the patch now, it's
> > trivial to change the implementation if/when the network stack has
> > support for this.
>
> FWIW, I think in mac80211 the in_interrupt() check can never return true
> since we postpone all RX to the tasklet. But the tasklet seems to be ok
> -- so should it really be in_interrupt()?
I think a tasklet is also in_interrupt(), because it's a softirq.
in_interrupt() returns false in process context. The problem appeared when
the b43 driver started passing RX frames while being in process context (threaded IRQ).
It previously was in tasklet (= softirq) context.
--
Greetings, Michael.
^ permalink raw reply
* Re: mac80211: NOHZ: local_softirq_pending 08
From: Johannes Berg @ 2009-09-30 15:21 UTC (permalink / raw)
To: Michael Buesch
Cc: Kalle Valo, Oliver Hartkopp, John W. Linville, linux-wireless,
netdev
In-Reply-To: <200909301710.31082.mb@bu3sch.de>
[-- Attachment #1: Type: text/plain, Size: 773 bytes --]
On Wed, 2009-09-30 at 17:10 +0200, Michael Buesch wrote:
> On Wednesday 30 September 2009 16:54:26 Johannes Berg wrote:
> > On Wed, 2009-09-30 at 17:47 +0300, Kalle Valo wrote:
> >
> > > I agree with Michael. The bug is real and I have verified that
> > > Michael's patch fixes the issue. Better to apply the patch now, it's
> > > trivial to change the implementation if/when the network stack has
> > > support for this.
> >
> > FWIW, I think in mac80211 the in_interrupt() check can never return true
> > since we postpone all RX to the tasklet. But the tasklet seems to be ok
> > -- so should it really be in_interrupt()?
>
> I think a tasklet is also in_interrupt(), because it's a softirq.
Ah, yes, indeed, in_interrupt() vs. in_irq().
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [ath9k-devel] Possible to set MCS Index?
From: Luis R. Rodriguez @ 2009-09-30 16:48 UTC (permalink / raw)
To: Matt Tierney; +Cc: ath9k-devel@lists.ath9k.org, linux-wireless
In-Reply-To: <d355d36c0909300814w302f11a4rb5b23a80aee36c43@mail.gmail.com>
On Wed, Sep 30, 2009 at 08:14:57AM -0700, Matt Tierney wrote:
> This might be a naive question, but I was wondering if it's
> possible to set the MCS index either from a high level interface
> or through a hack in the ath9k code. I'd like to fix the MCS Index
> to 15 but I don't know where that is set or if I can 'force' it
> through modifying the ath9k code in wireless-testing. (It doesn't
> appear as if iw provides that sort of functionality and it wasn't
> clear that I could specify a HT rate in hostapd.conf.)
mac80211 rate control code is MCS rate unaware, but we do at least
let drivers pass the MCS rate for tx status reporting. ath9k
unfortunately reports back the wrong MCS rate though because
of the way ath9k rate control works... it seems correcting this
requires a rewrite of our ath9k rate control code and no one has
prioritized on that as its a non-functional fix.
The first step then is to make mac80211 rate controle code MCS
aware and adding MCS rate control support to minstrel, for example.
For ath9k it'd be nice to fix the rate control code to be able
to report the right MCS index, I really am not sure how involved
that is as I've tried to stay away from the rate control code.
A good step would be to get ath9k rate control to be switchable
to minstrel, for example. This can be done as a module parameter
to start but eventually I think it'd be nice to be able to switch
through iw on any given device. That would require quite a lot of
work though.
Once mac80211 is MCS rate control aware the next step would be to
add a commands to set an MCS rate.
The cheesy and quick way to this for ath9k would be through
ath9k/debufs.c
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