* Re: [PATCH] cfg80211: fix regression on beacon world roaming feature
From: Luis R. Rodriguez @ 2009-07-31 15:49 UTC (permalink / raw)
To: Johannes Berg; +Cc: linville, linux-wireless, Jouni Malinen
In-Reply-To: <1249026324.29587.15.camel@johannes.local>
On Fri, Jul 31, 2009 at 12:45 AM, Johannes
Berg<johannes@sipsolutions.net> wrote:
> On Thu, 2009-07-30 at 17:43 -0700, Luis R. Rodriguez wrote:
>
>> By doing so though we also disallowed beacon hints on devices
>> registering their wiphy with custom world regulatory domains
>> enabled, this happens to be currently ath5k, ath9k and ar9170.
>> The passive scan and beacon restrictions on those devices would
>> never be lifted even if we did find a beacon and the hardware did
>> support such enhancements when world roaming.
>
> I dislike this solution, it just adds proliferation of possible
> behaviours.
Agreed.
> Can't those devices
Which devices?
> just set the _flags_ in their reg
> notifier,
So if you mean devices that used custom reg stuff, the answer is no
because the patch which introduced the regression would prevent the
setting of the passive scan flag and beaconing restrictions so the
reg_notifier would never notice the difference.
If you mean iwlwifi devices then yes, this is possible but it also
means a big change and I'd like to see this regression fixed on
2.6.31.
> and clear the corresponding bit in the orig_flags?
iwlwifi would just have to touch flags, not orig_flags as orig_flags
should not be touched.
How about using the patch as is for now for wireless-testing and
2.6.31, and then have iwlwifi write their own reg_notifier() ?
Luis
^ permalink raw reply
* Re: [Linux Wireless] Update of "en/users/Download" by ReinetteChatre
From: Roman Macko @ 2009-07-31 14:36 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: reinette chatre, linux-wireless
In-Reply-To: <43e72e890907301831ped2ea3wd5173b95be54f912@mail.gmail.com>
ok, I'm going to do a patch of check_depmod script and I'll send it to you
as soon as I do it.
roman
Luis R. Rodriguez wrote:
> On Thu, Jul 30, 2009 at 6:20 PM, Roman Macko<rmacko72@gmail.com> wrote:
>
>> Hi Luis,
>>
>> I have version 3.6 of module-init-tools and this version reads /etc/depmod.d
>> directory too.
>>
>> But I wanted to understand how depmod reads config files, so I looked into
>> source codes (both version 3.6 and 3.10)
>> and finally found out how it works.
>>
>> Assume depmod is run without -C or --config option
>>
>> Version 3.6 reads firstly /etc/depmod.conf file and then it reads config
>> files in directory /etc/depmod.d.
>> Files in directory /etc/depmod.d are read and parsed in unpredictable order
>> by readdir function (this function uses
>> raw directory structures of filesystem)
>>
>> Version 3.10 reads /etc/depmod.conf firstly as well, but this config file is
>> considered as deprecated in this version
>> and prints out warning about that. Then it reads config files in directory
>> /etc/depmod.d by readdir function as well, but before it starts
>> to parse them, it sorts them accord to filename, so you know the order in
>> which they are going to be parsed
>> and this is very improtant!!! This behavior should be from version 3.7
>>
>> The same for both versions:
>> 1) List of directories to be searched is created from search commands from
>> all config files in order how particular
>> search commands are found in config files (so order of parsed config files
>> is important). If no search command is found,
>> updates directory is added before "built-in" directory.
>>
>> 2) As for override command, the last one found for particular module and
>> kernel in all config files wins,
>> so again the order of parsed config files is important.
>>
>> From this is evident, that both versions can work differently which depends
>> on the order of parsed config files from
>> /etc/depmod.d directory that is different in both versions.
>>
>> So solution would be:
>> 1) if there is no search command in any of config files (in /etc/depmod.conf
>> or those in /etc/depmod.d directory), do nothing.
>> 2) if there is a search command in any of config files and does not contain
>> updates directory before built-in add search command
>> "search updates" in
>> a) if system has version >=3.7, create config file in /etc/depmod.d
>> directory which name is alphabeticaly less than all you will find
>> in that directory
>> b) if system has version <=3.6 add search command "search updates" at the
>> begining of /etc/depmod.conf file
>>
>> But such adding of "search updates" can break depmod configuration in some
>> systems or it is not desirable to make search in
>> updates directory at all. So maybe it would be better to use another name
>> for directory than updates
>>
>> Or it would be also interesting to use override command for all modules
>> compiled in compat-wireless
>> and put it all to configuration file /etc/depmod.d/compat-wireless.conf and
>> not bothering with version of depmod nor
>> finding the search command in all configuration files, e.g
>>
>> compat-wireless.conf
>> ======================================
>> override iwlagn * updates/drivers/net/wireless/iwlwifi
>> override iwlcore * updates/drivers/net/wireless/iwlwifi
>> ....
>> ....
>> ....
>> ======================================
>>
>> it can make problem only when some other config file in /etc/depmod.d
>> directory contains override command for
>> any module from compat-wireless
>>
>>
>> I hope this help you
>>
>
> Thanks, since you have read this and can read code, mind putting
> together a patch for the script on compat-wireless?
>
> Luis
>
^ permalink raw reply
* RE: kernel panic ieee80211_agg_splice_packets+0x3d/0xc0 [mac80211]
From: Jack Lau @ 2009-07-31 14:26 UTC (permalink / raw)
To: proski; +Cc: linux-wireless
In-Reply-To: <1248821338.5206.12.camel@mj>
Dear Pavel,
As a follow-up to yesterday's email that I have sent, I have also tried a different Linux distribution (Arch Linux), 64-bit instead of 32-bit and on a different machine dedicated for this test.
I am still getting this crash!
Regards,
Jack
----------------------------------------
> Subject: RE: kernel panic ieee80211_agg_splice_packets+0x3d/0xc0 [mac80211]
> From: proski@gnu.org
> To: jackelectronics@hotmail.com
> CC: linux-wireless@vger.kernel.org
> Date: Tue, 28 Jul 2009 18:48:58 -0400
>
> On Tue, 2009-07-28 at 21:21 +0000, Jack Lau wrote:
>
>>> I have enabled debugging in config.mk and installed it.
>
> I didn't suggest that. I think it's irrelevant. Only the setting
> in .config is relevant.
>
> If you are using compat-wireless, I suggest that you try the current
> kernel from wireless-testing. It was quite unstable a few days ago, but
> it should be cleaned up by now. Since you are using the AP mode, you'll
> need this patch, it's still not applied as of now:
>
> http://marc.info/?l=linux-wireless&m=124871936602667&w=2
>
> compat-wireless is great if everything is working, but if something is
> broken, the first suspicion is that compat-wireless doesn't backport
> something correctly.
>
>> The kernel already has debugging enabled as I have examined the
>> source from Ubuntu.
>
> Please be specific what you found and where. I don't have Ubuntu
> around, but others could correct you if you are looking in a wrong
> place.
>
>>> When I load the gdb command, I just get no debugging symbols found
>> and with the l command I just get no symbol file now.
>
> Please don't rephrase tell the error messages, especially if you don't
> understand them fully. I cannot see from your words why there are no
> debugging symbols.
>
> Also please don't top-post, as it makes it harder to quote the
> discussion in a reasonable way.
>
> --
> Regards,
> Pavel Roskin
_________________________________________________________________
Celebrate a decade of Messenger with free winks, emoticons, display pics, and more.
http://clk.atdmt.com/UKM/go/157562755/direct/01/
^ permalink raw reply
* Re: RTL8192SE support status
From: Greg KH @ 2009-07-31 14:16 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: linux-kernel, linux-wireless
In-Reply-To: <200907311431.17043.bzolnier@gmail.com>
On Fri, Jul 31, 2009 at 02:31:16PM +0200, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> I've been getting some private mail regarding the status of RTL8192SE
> wireless chipset support (the chipset is used in some newer netbooks,
> i.e. Medion Akoya E1312) so the current situation is:
>
> * I'm not working on it and I don't know if/when the driver is coming.
>
> * Realtek has been queried about the issue two weeks ago but we haven't
> heard anything back yet.
>
> * rtl8192su driver present in staging area of the kernel is for RTL8192SU
> (USB version of the chipset) and never contained working/complete code
> for RTL8192SE (PCI-E version of the chipset) so there is no point in
> attempts of reverting some patches in hope that it will make the things
> magically work (it won't, please save your time).
Thanks for letting us know, this helps out a lot.
greg k-h
^ permalink raw reply
* Re: [PATCH] mac80211: use beacons for connection monitoring
From: Johannes Berg @ 2009-07-31 14:06 UTC (permalink / raw)
To: Maxim Levitsky; +Cc: Reinette Chatre, linville, linux-wireless
In-Reply-To: <1249048571.32395.6.camel@maxim-laptop>
[-- Attachment #1: Type: text/plain, Size: 2008 bytes --]
On Fri, 2009-07-31 at 16:56 +0300, Maxim Levitsky wrote:
> > That appears to be in the wrong place. Shouldn't that be in the
> > _set_associated function? Otherwise you're always setting it to 0 before
> > sending the probe?
> I thought about this too, but I think this is the right place.
> ieee80211_mgd_probe_ap is called to start a probe on an AP, it will
> ignore following calls till ether AP responds or we reconnect.
> What I did is not to fail after first timeout, but resend the assoc
> request once more, thus this function won't be called again.
Ok, that makes sense.
> > > + else if (ifmgd->probe_miss_count < IEEE80211_ASSOC_RETRIES) {
> > > +
> > > + printk(KERN_DEBUG "No probe response from AP %pM"
> >
> > and that one too
> same here
> >
> > > + " after %dms, try %d\n", bssid,
> > > + (1000 * IEEE80211_PROBE_WAIT)/HZ,
> > > + (int)ifmgd->probe_miss_count);
> > > +
> > > + ifmgd->probe_miss_count++;
> > > + ifmgd->probe_timeout = jiffies + IEEE80211_PROBE_WAIT;
> > > + run_again(ifmgd, ifmgd->probe_timeout);
> > > +
> > > + ssid = ieee80211_bss_get_ie(&ifmgd->associated->cbss, WLAN_EID_SSID);
> > > + ieee80211_send_probe_req(sdata, ifmgd->associated->cbss.bssid,
> > > + ssid + 2, ssid[1], NULL, 0);
> > > + } else {
> >
> > Shouldn't this just call _probe_ap() again? After you move the setting
> > to 0 out of it, that is?
> No, first of all I tried it :-).
:)
> It takes the ifmgd->mtx first of all,
> and besides this way it is more logical, ieee80211_mgd_probe_ap is
> called once per AP ping, and here we continue it.
> Since I have copied these 3 lines from ieee80211_mgd_probe_ap I have no
> objection to put them in a new function.
Don't think it really matters, it's just two function calls anyway...
But maybe it would make sense to put this whole block into a
_mgd_probe_ap_retry function or so? On the other hand, it's just a
handful lines of code, so this is fine too.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [rt2800pci] Problems with (and without) rfkill
From: Darren Salt @ 2009-07-31 13:37 UTC (permalink / raw)
To: linux-wireless; +Cc: IvDoorn
[-- Attachment #1: Type: text/plain, Size: 1920 bytes --]
I've had a play with the rt2x00 tree (11c3222a) and hit some problems on my
EeePC 901.
First, I was seeing "SIOCSIFFLAGS: unknown error 132" (which turns out to be
ERFKILL) when trying to bring up the interface. "rfkill list" shows that phy0
is hard-blocked¹; since there's no switch for this, the only way to "unblock"
it is to patch the driver. I used the following patch for this².
diff --git a/drivers/net/wireless/rt2x00/rt2800pci.c b/drivers/net/wireless/rt2x
index 8a22e65..f934325 100644
--- a/drivers/net/wireless/rt2x00/rt2800pci.c
+++ b/drivers/net/wireless/rt2x00/rt2800pci.c
@@ -380,7 +380,12 @@ static int rt2800pci_rfkill_poll(struct rt2x00_dev *rt2x00d
u32 reg;
rt2x00pci_register_read(rt2x00dev, GPIO_CTRL_CFG, ®);
- return rt2x00_get_field32(reg, GPIO_CTRL_CFG_BIT2);
+ /*return rt2x00_get_field32(reg, GPIO_CTRL_CFG_BIT2);*/
+ if (rt2x00_get_field32(reg, GPIO_CTRL_CFG_BIT2)) {
+ rt2x00_set_field32(®, GPIO_CTRL_CFG_BIT2, 0);
+ rt2x00pci_register_write(rt2x00dev, GPIO_CTRL_CFG, reg);
+ }
+ return 0;
}
#ifdef CONFIG_RT2X00_LIB_LEDS
However, this isn't the end of the problems: I get an oops instead while
trying to bring up the interface (configured via /etc/network/interfaces and
using WPA2; the configuration is known good for rt2860sta).
¹ phy0 is only present when eeepc-wlan is not blocked, which isn't surprising
because the card is effectively unplugged when eeepc-wlan is blocked.
² I also tried just having rt2800pci_rfkill_poll() just return 0, but that
makes no difference.
--
| Darren Salt | linux at youmustbejoking | nr. Ashington, | Doon
| using Debian GNU/Linux | or ds ,demon,co,uk | Northumberland | Army
| + Burn less waste. Use less packaging. Waste less. USE FEWER RESOURCES.
Sir Bobby Robson, R. I. P.
[-- Attachment #2: 2800pci.oops --]
[-- Type: application/octet-stream, Size: 30160 bytes --]
Linux version 2.6.31-rc4-wl-eee901-02154-g11c3222-dirty (root@alien8) (gcc version 4.2.4 (Debian 4.2.4-6)) #1 SMP PREEMPT Fri Jul 31 14:00:58 BST 2009
KERNEL supported cpus:
Intel GenuineIntel
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000003f7a0000 (usable)
BIOS-e820: 000000003f7a0000 - 000000003f7ae000 (ACPI data)
BIOS-e820: 000000003f7ae000 - 000000003f7f0000 (ACPI NVS)
BIOS-e820: 000000003f7f0000 - 000000003f800000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
DMI present.
last_pfn = 0x3f7a0 max_arch_pfn = 0x100000
MTRR default type: uncachable
MTRR fixed ranges enabled:
00000-9FFFF write-back
A0000-DFFFF uncachable
E0000-E3FFF write-protect
E4000-EFFFF write-through
F0000-FFFFF write-protect
MTRR variable ranges enabled:
0 base 000000000 mask 0C0000000 write-back
1 base 03F800000 mask 0FF800000 uncachable
2 disabled
3 disabled
4 disabled
5 disabled
6 disabled
7 disabled
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
initial memory mapped : 0 - 00800000
init_memory_mapping: 0000000000000000-00000000377fe000
0000000000 - 0000400000 page 4k
0000400000 - 0037400000 page 2M
0037400000 - 00377fe000 page 4k
kernel direct mapping tables up to 377fe000 @ 7000-c000
ACPI: RSDP 000fbd00 00014 (v00 ACPIAM)
ACPI: RSDT 3f7a0000 0003C (v01 A_M_I_ OEMRSDT 06000911 MSFT 00000097)
ACPI: FACP 3f7a0200 00084 (v02 A_M_I_ OEMFACP 06000911 MSFT 00000097)
ACPI: DSDT 3f7a0430 062A6 (v01 P0017 P0017000 00000000 INTL 20060113)
ACPI: FACS 3f7ae000 00040
ACPI: APIC 3f7a0390 0005C (v01 A_M_I_ OEMAPIC 06000911 MSFT 00000097)
ACPI: MCFG 3f7a03f0 0003C (v01 A_M_I_ OEMMCFG 06000911 MSFT 00000097)
ACPI: OEMB 3f7ae040 00061 (v01 A_M_I_ AMI_OEM 06000911 MSFT 00000097)
ACPI: HPET 3f7a66e0 00038 (v01 A_M_I_ OEMHPET 06000911 MSFT 00000097)
ACPI: SSDT 3f7aeb80 004F0 (v01 PmRef CpuPm 00003000 INTL 20060113)
ACPI: Local APIC address 0xfee00000
127MB HIGHMEM available.
887MB LOWMEM available.
mapped low ram: 0 - 377fe000
low ram: 0 - 377fe000
node 0 low ram: 00000000 - 377fe000
node 0 bootmap 00008000 - 0000ef00
(8 early reservations) ==> bootmem [0000000000 - 00377fe000]
#0 [0000000000 - 0000001000] BIOS data page ==> [0000000000 - 0000001000]
#1 [0000001000 - 0000002000] EX TRAMPOLINE ==> [0000001000 - 0000002000]
#2 [0000006000 - 0000007000] TRAMPOLINE ==> [0000006000 - 0000007000]
#3 [0000100000 - 00005ff478] TEXT DATA BSS ==> [0000100000 - 00005ff478]
#4 [000009fc00 - 0000100000] BIOS reserved ==> [000009fc00 - 0000100000]
#5 [0000600000 - 00006021f4] BRK ==> [0000600000 - 00006021f4]
#6 [0000007000 - 0000008000] PGTABLE ==> [0000007000 - 0000008000]
#7 [0000008000 - 000000f000] BOOTMAP ==> [0000008000 - 000000f000]
Zone PFN ranges:
DMA 0x00000000 -> 0x00001000
Normal 0x00001000 -> 0x000377fe
HighMem 0x000377fe -> 0x0003f7a0
Movable zone start PFN for each node
early_node_map[2] active PFN ranges
0: 0x00000000 -> 0x0000009f
0: 0x00000100 -> 0x0003f7a0
On node 0 totalpages: 259903
free_area_init_node: node 0, pgdat c0555080, node_mem_map c1000000
DMA zone: 32 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 3967 pages, LIFO batch:0
Normal zone: 1744 pages used for memmap
Normal zone: 221486 pages, LIFO batch:31
HighMem zone: 256 pages used for memmap
HighMem zone: 32418 pages, LIFO batch:7
Using APIC driver default
ACPI: PM-Timer IO Port: 0x808
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, 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
ACPI: HPET id: 0xffffffff base: 0xfed00000
SMP: Allowing 2 CPUs, 0 hotplug CPUs
nr_irqs_gsi: 24
Allocating PCI resources starting at 3f800000 (gap: 3f800000:bf600000)
NR_CPUS:2 nr_cpumask_bits:2 nr_cpu_ids:2 nr_node_ids:1
PERCPU: Embedded 11 pages at c17f4000, static data 23516 bytes
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 257871
Kernel command line: auto BOOT_IMAGE=Linux ro root=801 cfg80211.ieee80211_regdom=EU snd_hda_intel.power_save=1 i915.modeset=1
PID hash table entries: 4096 (order: 12, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
Initializing HighMem for node 0 (000377fe:0003f7a0)
Memory: 1025076k/1040000k available (3083k kernel code, 14184k reserved, 1426k data, 272k init, 130696k highmem)
virtual kernel memory layout:
fixmap : 0xfff91000 - 0xfffff000 ( 440 kB)
pkmap : 0xff800000 - 0xffc00000 (4096 kB)
vmalloc : 0xf7ffe000 - 0xff7fe000 ( 120 MB)
lowmem : 0xc0000000 - 0xf77fe000 ( 887 MB)
.init : 0xc056d000 - 0xc05b1000 ( 272 kB)
.data : 0xc0402ca2 - 0xc0567724 (1426 kB)
.text : 0xc0100000 - 0xc0402ca2 (3083 kB)
Checking if this processor honours the WP bit even in supervisor mode...Ok.
SLUB: Genslabs=13, HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
NR_IRQS:320
Fast TSC calibration using PIT
Detected 1599.868 MHz processor.
Console: colour dummy device 80x25
console [tty0] enabled
hpet clockevent registered
HPET: 3 timers in total, 0 timers will be used for per-cpu timer
Calibrating delay loop (skipped), value calculated using timer frequency.. 3199.73 BogoMIPS (lpj=6399472)
Mount-cache hash table entries: 512
CPU: L1 I cache: 32K, L1 D cache: 24K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
mce: CPU supports 5 MCE banks
CPU0: Thermal monitoring enabled (TM2)
using mwait in idle threads.
Checking 'hlt' instruction... OK.
ACPI: Core revision 20090521
..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
CPU0: Intel(R) Atom(TM) CPU N270 @ 1.60GHz stepping 02
Booting processor 1 APIC 0x1 ip 0x6000
Initializing CPU#1
Calibrating delay using timer specific routine.. 3199.90 BogoMIPS (lpj=6399819)
CPU: L1 I cache: 32K, L1 D cache: 24K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
mce: CPU supports 5 MCE banks
CPU1: Thermal monitoring enabled (TM2)
x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106
CPU1: Intel(R) Atom(TM) CPU N270 @ 1.60GHz stepping 02
checking TSC synchronization [CPU#0 -> CPU#1]: passed.
Brought up 2 CPUs
Total of 2 processors activated (6399.64 BogoMIPS).
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 63
PCI: Not using MMCONFIG.
PCI: PCI BIOS revision 3.00 entry at 0xf0031, last bus=6
PCI: Using configuration type 1 for base access
bio: create slab <bio-0> at 0
ACPI: EC: Look up EC in DSDT
ACPI: Interpreter enabled
ACPI: (supports S0 S1 S3 S5)
ACPI: Using IOAPIC for interrupt routing
PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 63
PCI: MCFG area at e0000000 reserved in ACPI motherboard resources
PCI: Using MMCONFIG for extended config space
ACPI: EC: GPE = 0x1c, I/O: command/status = 0x66, data = 0x62
ACPI: EC: driver started in poll mode
ACPI: No dock devices found.
ACPI: PCI Root Bridge [PCI0] (0000:00)
pci 0000:00:02.0: reg 10 32bit mmio: [0xf7f00000-0xf7f7ffff]
pci 0000:00:02.0: reg 14 io port: [0xdc80-0xdc87]
pci 0000:00:02.0: reg 18 32bit mmio: [0xd0000000-0xdfffffff]
pci 0000:00:02.0: reg 1c 32bit mmio: [0xf7ec0000-0xf7efffff]
pci 0000:00:02.1: reg 10 32bit mmio: [0xf7f80000-0xf7ffffff]
pci 0000:00:1b.0: reg 10 64bit mmio: [0xf7eb8000-0xf7ebbfff]
pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold
pci 0000:00:1b.0: PME# disabled
pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
pci 0000:00:1c.0: PME# disabled
pci 0000:00:1c.1: PME# supported from D0 D3hot D3cold
pci 0000:00:1c.1: PME# disabled
pci 0000:00:1c.2: PME# supported from D0 D3hot D3cold
pci 0000:00:1c.2: PME# disabled
pci 0000:00:1c.3: PME# supported from D0 D3hot D3cold
pci 0000:00:1c.3: PME# disabled
pci 0000:00:1d.0: reg 20 io port: [0xd480-0xd49f]
pci 0000:00:1d.1: reg 20 io port: [0xd800-0xd81f]
pci 0000:00:1d.2: reg 20 io port: [0xd880-0xd89f]
pci 0000:00:1d.3: reg 20 io port: [0xdc00-0xdc1f]
pci 0000:00:1d.7: reg 10 32bit mmio: [0xf7eb7c00-0xf7eb7fff]
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 0800-087f claimed by ICH6 ACPI/GPIO/TCO
pci 0000:00:1f.0: quirk: region 0480-04bf claimed by ICH6 GPIO
pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0380 (mask 0003)
pci 0000:00:1f.0: ICH7 LPC Generic IO decode 2 PIO at 0290 (mask 0007)
pci 0000:00:1f.0: ICH7 LPC Generic IO decode 3 PIO at 0068 (mask 0003)
pci 0000:00:1f.2: reg 10 io port: [0x00-0x07]
pci 0000:00:1f.2: reg 14 io port: [0x00-0x03]
pci 0000:00:1f.2: reg 18 io port: [0x00-0x07]
pci 0000:00:1f.2: reg 1c io port: [0x00-0x03]
pci 0000:00:1f.2: reg 20 io port: [0xffa0-0xffaf]
pci 0000:00:1f.2: PME# supported from D3hot
pci 0000:00:1f.2: PME# disabled
pci 0000:00:1f.3: reg 20 io port: [0x400-0x41f]
pci 0000:04:00.0: reg 10 64bit mmio: [0xfbfc0000-0xfbffffff]
pci 0000:04:00.0: reg 18 io port: [0xec80-0xecff]
pci 0000:04:00.0: PME# supported from D3hot D3cold
pci 0000:04:00.0: PME# disabled
pci 0000:04:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force'
pci 0000:00:1c.1: bridge io port: [0xe000-0xefff]
pci 0000:00:1c.1: bridge 32bit mmio: [0xfbf00000-0xfbffffff]
pci 0000:01:00.0: reg 10 32bit mmio: [0x000000-0x00ffff]
pci 0000:01:00.0: PME# supported from D0 D3hot
pci 0000:01:00.0: PME# disabled
pci 0000:00:1c.3: bridge 32bit mmio: [0xf8000000-0xfbefffff]
pci 0000:00:1c.3: bridge 64bit mmio pref: [0xf0000000-0xf6ffffff]
pci 0000:00:1e.0: transparent bridge
pci_bus 0000:00: on NUMA node 0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P4._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P6._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P7._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P5._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs *3 4 5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 *4 5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 *7 10 11 12 14 15)
SCSI subsystem initialized
libata version 3.00 loaded.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
PCI: Using ACPI for IRQ routing
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
pnp: PnP ACPI init
ACPI: bus type pnp registered
pnp: PnP ACPI: found 13 devices
ACPI: ACPI bus type pnp unregistered
system 00:01: iomem range 0xfed13000-0xfed19fff has been reserved
system 00:08: ioport range 0x25c-0x25f has been reserved
system 00:08: ioport range 0x380-0x383 has been reserved
system 00:08: ioport range 0x400-0x41f has been reserved
system 00:08: ioport range 0x4d0-0x4d1 has been reserved
system 00:08: ioport range 0x800-0x87f has been reserved
system 00:08: ioport range 0x480-0x4bf has been reserved
system 00:08: iomem range 0x8c000000-0x8c01ffff has been reserved
system 00:08: iomem range 0xfed1c000-0xfed1ffff has been reserved
system 00:08: iomem range 0xfed20000-0xfed3ffff has been reserved
system 00:08: iomem range 0xfed50000-0xfed8ffff has been reserved
system 00:08: iomem range 0xffb00000-0xffbfffff has been reserved
system 00:08: iomem range 0xfff00000-0xffffffff could not be reserved
system 00:0a: iomem range 0xfec00000-0xfec00fff could not be reserved
system 00:0a: iomem range 0xfee00000-0xfee00fff has been reserved
system 00:0b: iomem range 0xe0000000-0xe3ffffff has been reserved
system 00:0c: iomem range 0x0-0x9ffff could not be reserved
system 00:0c: iomem range 0xc0000-0xcffff could not be reserved
system 00:0c: iomem range 0xe0000-0xfffff could not be reserved
system 00:0c: iomem range 0x100000-0x3f7fffff could not be reserved
pci 0000:00:1c.0: PCI bridge, secondary bus 0000:05
pci 0000:00:1c.0: IO window: disabled
pci 0000:00:1c.0: MEM window: disabled
pci 0000:00:1c.0: PREFETCH window: disabled
pci 0000:00:1c.1: PCI bridge, secondary bus 0000:04
pci 0000:00:1c.1: IO window: 0xe000-0xefff
pci 0000:00:1c.1: MEM window: 0xfbf00000-0xfbffffff
pci 0000:00:1c.1: PREFETCH window: disabled
pci 0000:00:1c.2: PCI bridge, secondary bus 0000:03
pci 0000:00:1c.2: IO window: disabled
pci 0000:00:1c.2: MEM window: disabled
pci 0000:00:1c.2: PREFETCH window: disabled
pci 0000:00:1c.3: PCI bridge, secondary bus 0000:01
pci 0000:00:1c.3: IO window: disabled
pci 0000:00:1c.3: MEM window: 0xf8000000-0xfbefffff
pci 0000:00:1c.3: PREFETCH window: 0x000000f0000000-0x000000f6ffffff
pci 0000:00:1e.0: PCI bridge, secondary bus 0000:06
pci 0000:00:1e.0: IO window: disabled
pci 0000:00:1e.0: MEM window: disabled
pci 0000:00:1e.0: PREFETCH window: disabled
pci 0000:00:1c.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
pci 0000:00:1c.0: setting latency timer to 64
pci 0000:00:1c.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
pci 0000:00:1c.1: setting latency timer to 64
pci 0000:00:1c.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
pci 0000:00:1c.2: setting latency timer to 64
pci 0000:00:1c.3: PCI INT D -> GSI 19 (level, low) -> IRQ 19
pci 0000:00:1c.3: setting latency timer to 64
pci 0000:00:1e.0: setting latency timer to 64
pci_bus 0000:00: resource 0 io: [0x00-0xffff]
pci_bus 0000:00: resource 1 mem: [0x000000-0xffffffff]
pci_bus 0000:04: resource 0 io: [0xe000-0xefff]
pci_bus 0000:04: resource 1 mem: [0xfbf00000-0xfbffffff]
pci_bus 0000:01: resource 1 mem: [0xf8000000-0xfbefffff]
pci_bus 0000:01: resource 2 pref mem [0xf0000000-0xf6ffffff]
pci_bus 0000:06: resource 3 io: [0x00-0xffff]
pci_bus 0000:06: resource 4 mem: [0x000000-0xffffffff]
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
NET: Registered protocol family 1
highmem bounce pool size: 64 pages
msgmni has been set to 1747
alg: No test for stdrng (krng)
io scheduler noop registered (default)
pci 0000:00:02.0: Boot video device
pcieport-driver 0000:00:1c.0: irq 24 for MSI/MSI-X
pcieport-driver 0000:00:1c.0: setting latency timer to 64
pcieport-driver 0000:00:1c.1: irq 25 for MSI/MSI-X
pcieport-driver 0000:00:1c.1: setting latency timer to 64
pcieport-driver 0000:00:1c.2: irq 26 for MSI/MSI-X
pcieport-driver 0000:00:1c.2: setting latency timer to 64
pcieport-driver 0000:00:1c.3: irq 27 for MSI/MSI-X
pcieport-driver 0000:00:1c.3: setting latency timer to 64
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
ACPI: AC Adapter [AC0] (on-line)
input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
ACPI: Power Button [PWRF]
input: Lid Switch as /devices/LNXSYSTM:00/device:00/PNP0C0D:00/input/input1
ACPI: EC: non-query interrupt received, switching to interrupt mode
ACPI: Lid Switch [LID]
input: Sleep Button as /devices/LNXSYSTM:00/device:00/PNP0C0E:00/input/input2
ACPI: Sleep Button [SLPB]
input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input3
ACPI: Power Button [PWRB]
input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/device:1f/input/input4
ACPI: Video Device [VGA] (multi-head: yes rom: no post: no)
ACPI: SSDT 3f7ae180 0023C (v01 PmRef Cpu0Ist 00003000 INTL 20060113)
ACPI: SSDT 3f7ae450 00724 (v01 PmRef Cpu0Cst 00003001 INTL 20060113)
Monitor-Mwait will be used to enter C-1 state
Monitor-Mwait will be used to enter C-2 state
Marking TSC unstable due to TSC halts in idle
Switched to high resolution mode on CPU 0
ACPI: CPU0 (power states: C1[C1] C2[C2])
processor LNXCPU:00: registered as cooling_device0
ACPI: Processor [CPU0] (supports 8 throttling states)
Switched to high resolution mode on CPU 1
ACPI: SSDT 3f7ae0b0 000CC (v01 PmRef Cpu1Ist 00003000 INTL 20060113)
ACPI: SSDT 3f7ae3c0 00085 (v01 PmRef Cpu1Cst 00003000 INTL 20060113)
ACPI: CPU1 (power states: C1[C1] C2[C2])
processor LNXCPU:01: registered as cooling_device1
ACPI: Processor [CPU1] (supports 8 throttling states)
thermal LNXTHERM:01: registered as thermal_zone0
ACPI: Thermal Zone [TZ00] (45 C)
Non-volatile memory driver v1.3
Linux agpgart interface v0.103
agpgart-intel 0000:00:00.0: Intel 945GME Chipset
agpgart-intel 0000:00:00.0: detected 7932K stolen memory
agpgart-intel 0000:00:00.0: AGP aperture is 256M @ 0xd0000000
[drm] Initialized drm 1.1.0 20060810
i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
i915 0000:00:02.0: setting latency timer to 64
ACPI: Battery Slot [BAT0] (battery present)
[drm] LVDS-8: set mode 1024x600 e
Console: switching to colour frame buffer device 128x37
[drm] fb0: inteldrmfb frame buffer device
[drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
ACPI: EC: missing confirmations, switch off interrupt mode.
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
Platform driver 'serial8250' needs updating - please use dev_pm_ops
loop: module loaded
ata_piix 0000:00:1f.2: version 2.13
ata_piix 0000:00:1f.2: PCI INT B -> GSI 19 (level, low) -> IRQ 19
ata_piix 0000:00:1f.2: MAP [ P0 P2 IDE IDE ]
ata_piix 0000:00:1f.2: setting latency timer to 64
scsi0 : ata_piix
scsi1 : ata_piix
ata1: SATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xffa0 irq 14
ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xffa8 irq 15
ATL1E 0000:04:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
ATL1E 0000:04:00.0: setting latency timer to 64
console [netcon0] enabled
netconsole: network logging started
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci_hcd 0000:00:1d.7: PCI INT A -> 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 32 is not supported
ehci_hcd 0000:00:1d.7: irq 23, io mem 0xf7eb7c00
ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: EHCI Host Controller
usb usb1: Manufacturer: Linux 2.6.31-rc4-wl-eee901-02154-g11c3222-dirty ehci_hcd
usb usb1: SerialNumber: 0000:00:1d.7
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 8 ports detected
uhci_hcd: USB Universal Host Controller Interface driver
uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23
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 23, io base 0x0000d480
usb usb2: New USB device found, idVendor=1d6b, idProduct=0001
usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: UHCI Host Controller
usb usb2: Manufacturer: Linux 2.6.31-rc4-wl-eee901-02154-g11c3222-dirty uhci_hcd
usb usb2: SerialNumber: 0000:00:1d.0
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 22 (level, low) -> IRQ 22
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 22, io base 0x0000d800
usb usb3: New USB device found, idVendor=1d6b, idProduct=0001
ata2.00: CFA: ASUS-PHISON SSD, TST2.04U, max UDMA/66
ata2.00: 7880544 sectors, multi 0: LBA
ata2.01: CFA: ASUS-PHISON SSD, TST2.04P, max UDMA/66
ata2.01: 31522176 sectors, multi 0: LBA
ata2.00: configured for UDMA/66
usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
ata2.01: configured for UDMA/66
scsi 1:0:0:0: Direct-Access ATA ASUS-PHISON SSD TST2 PQ: 0 ANSI: 5
sd 1:0:0:0: [sda] 7880544 512-byte logical blocks: (4.03 GB/3.75 GiB)
sd 1:0:0:0: [sda] Write Protect is off
sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
usb usb3: Product: UHCI Host Controller
usb usb3: Manufacturer: Linux 2.6.31-rc4-wl-eee901-02154-g11c3222-dirty uhci_hcd
usb usb3: SerialNumber: 0000:00:1d.1
sda:
scsi 1:0:1:0: Direct-Access ATA ASUS-PHISON SSD TST2 PQ: 0 ANSI: 5
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 21 (level, low) -> IRQ 21
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 21, io base 0x0000d880
usb usb4: New USB device found, idVendor=1d6b, idProduct=0001
usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb4: Product: UHCI Host Controller
usb usb4: Manufacturer: Linux 2.6.31-rc4-wl-eee901-02154-g11c3222-dirty uhci_hcd
usb usb4: SerialNumber: 0000:00:1d.2
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 20 (level, low) -> IRQ 20
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 20, io base 0x0000dc00
usb usb5: New USB device found, idVendor=1d6b, idProduct=0001
usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb5: Product: UHCI Host Controller
usb usb5: Manufacturer: Linux 2.6.31-rc4-wl-eee901-02154-g11c3222-dirty uhci_hcd
usb usb5: SerialNumber: 0000:00:1d.3
usb usb5: configuration #1 chosen from 1 choice
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 2 ports detected
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usbcore: registered new interface driver usbserial
usbserial: USB Serial Driver core
USB Serial support registered for pl2303
usbcore: registered new interface driver pl2303
pl2303: Prolific PL2303 USB to serial adaptor driver
PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
Platform driver 'i8042' needs updating - please use dev_pm_ops
serio: i8042 KBD port at 0x60,0x64 irq 1
mice: PS/2 mouse device common for all mice
rtc_cmos 00:03: RTC can wake from S4
rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0
rtc0: alarms up to one month, 114 bytes nvram, hpet irqs
i2c /dev entries driver
coretemp: Unknown CPU model 1c
coretemp: Unknown CPU model 1c
cpuidle: using governor ladder
sda1 sda4
sd 1:0:1:0: [sdb] 31522176 512-byte logical blocks: (16.1 GB/15.0 GiB)
cpuidle: using governor menu
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
usbhid: v2.6:USB HID core driver
eeepc_laptop: Eee PC Hotkey Driver
sd 1:0:0:0: [sda] Attached SCSI disk
sd 1:0:1:0: [sdb] Write Protect is off
sd 1:0:1:0: [sdb] Mode Sense: 00 3a 00 00
sd 1:0:1:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
sdb: unknown partition table
sd 1:0:1:0: [sdb] Attached SCSI disk
input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input5
hub 1-0:1.0: unable to enumerate USB device on port 7
usb 1-8: new high speed USB device using ehci_hcd and address 3
usb 1-8: New USB device found, idVendor=05e3, idProduct=0505
usb 1-8: New USB device strings: Mfr=0, Product=1, SerialNumber=0
usb 1-8: Product: USB 2.0 Camera
usb 1-8: configuration #1 chosen from 1 choice
eeepc_laptop: Hotkey init flags 0x41
eeepc_laptop: TYPE (2000000) not reported by BIOS, enabling anyway
eeepc_laptop: PANELPOWER (4000000) not reported by BIOS, enabling anyway
eeepc_laptop: Get control methods supported: 0x6101713
input: Asus EeePC extra buttons as /devices/virtual/input/input6
Advanced Linux Sound Architecture Driver Version 1.0.20.
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
input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:1b.0/input/input7
ALSA device list:
#0: HDA Intel at 0xf7eb8000 irq 16
TCP cubic registered
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
NET: Registered protocol family 17
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
Using IPI No-Shortcut mode
rtc_cmos 00:03: setting system clock to 2009-07-31 13:09:06 UTC (1249045746)
EXT4-fs (sda1): barriers enabled
EXT4-fs (sda1): delayed allocation enabled
EXT4-fs: file extents enabled
kjournald2 starting: pid 1164, dev sda1:8, commit interval 5 seconds
EXT4-fs: mballoc enabled
EXT4-fs (sda1): mounted filesystem with ordered data mode
VFS: Mounted root (ext4 filesystem) readonly on device 8:1.
Freeing unused kernel memory: 272k freed
Write protecting the kernel text: 3084k
Write protecting the kernel read-only data: 1052k
rt2800pci 0000:01:00.0: enabling device (0000 -> 0002)
rt2800pci 0000:01:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
rt2800pci 0000:01:00.0: setting latency timer to 64
phy0 -> rt2x00_set_chip: Info - Chipset detected - rt: 0781, rf: 0003, rev: 28720200.
Linux video capture interface: v2.00
uvcvideo: Found UVC 1.00 device USB 2.0 Camera (05e3:0505)
phy0: Selected rate control algorithm 'pid'
usbcore: registered new interface driver uvcvideo
USB Video Class driver (v0.1.0)
EXT4-fs (sda1): internal journal on sda1:8
EXT4-fs (sdb): barriers enabled
kjournald2 starting: pid 2596, dev sdb:8, commit interval 5 seconds
EXT4-fs (sdb): internal journal on sdb:8
EXT4-fs (sdb): delayed allocation enabled
EXT4-fs: file extents enabled
EXT4-fs: mballoc enabled
EXT4-fs (sdb): mounted filesystem with ordered data mode
phy0 -> rt2x00lib_request_firmware: Info - Loading firmware file 'rt2860.bin'.
rt2800pci 0000:01:00.0: firmware: requesting rt2860.bin
phy0 -> rt2x00lib_request_firmware: Info - Firmware detected - version: 0.11.
phy0 -> rt2800pci_mcu_status: Error - MCU request failed, no response from hardware
phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 0 - CWmin: 3, CWmax: 4, Aifs: 2, TXop: 102.
phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 1 - CWmin: 4, CWmax: 5, Aifs: 2, TXop: 188.
phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 2 - CWmin: 5, CWmax: 10, Aifs: 3, TXop: 0.
phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 3 - CWmin: 5, CWmax: 10, Aifs: 7, TXop: 0.
ADDRCONF(NETDEV_UP): wlan0: link is not ready
BUG: unable to handle kernel paging request at 8000000c
IP: [<c03e20da>] ieee80211_scan_work+0x163/0x383
*pde = 00000000
Oops: 0000 [#1] PREEMPT SMP
last sysfs file: /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/ACPI0003:00/power_supply/AC0/online
Modules linked in: uvcvideo videodev v4l1_compat rt2800pci rt2x00pci rt2x00lib
Pid: 1512, comm: phy0 Not tainted (2.6.31-rc4-wl-eee901-02154-g11c3222-dirty #1) 901
EIP: 0060:[<c03e20da>] EFLAGS: 00010286 CPU: 0
EIP is at ieee80211_scan_work+0x163/0x383
EAX: f699da7d EBX: 80000000 ECX: f68d2380 EDX: f699da00
ESI: f696f1c0 EDI: f696f768 EBP: f6b3bf80 ESP: f6b3bf68
DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Process phy0 (pid: 1512, ti=f6b3a000 task=f68191c0 task.ti=f6b3a000)
Stack:
f696f760 f6b3bf80 f696f7fc f696f7fc f8384100 f696f800 f6b3bfb4 c0130711
<0> f838410c f8384104 c03e1f77 00000000 f68191c0 c0132e01 f6b3bfa0 f6b3bfa0
<0> f6b5bd74 f6b3bfc4 f8384100 f6b3bfe0 c0132c78 c013060e 00000000 00000000
Call Trace:
[<c0130711>] ? worker_thread+0x103/0x18f
[<c03e1f77>] ? ieee80211_scan_work+0x0/0x383
[<c0132e01>] ? autoremove_wake_function+0x0/0x30
[<c0132c78>] ? kthread+0x64/0x69
[<c013060e>] ? worker_thread+0x0/0x18f
[<c0132c14>] ? kthread+0x0/0x69
[<c01033df>] ? kernel_thread_helper+0x7/0x10
Code: ff ff c7 86 38 06 00 00 03 00 00 00 e9 57 ff ff ff 8b 96 20 06 00 00 8b 86 30 06 00 00 8b 8e 7c 06 00 00 c1 e0 02 03 42 08 8b 18 <8b> 43 0c a8 01 75 25 83 b9 a8 03 00 00 01 75 04 a8 04 75 18 ba
EIP: [<c03e20da>] ieee80211_scan_work+0x163/0x383 SS:ESP 0068:f6b3bf68
CR2: 000000008000000c
---[ end trace 81c575e36adc17db ]---
Bluetooth: Core ver 2.15
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: L2CAP ver 2.13
Bluetooth: L2CAP socket layer initialized
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM TTY layer initialized
Bluetooth: RFCOMM ver 1.11
^ permalink raw reply related
* Re: [PATCH] mac80211: use beacons for connection monitoring
From: Maxim Levitsky @ 2009-07-31 13:56 UTC (permalink / raw)
To: Johannes Berg; +Cc: Reinette Chatre, linville, linux-wireless
In-Reply-To: <1249047576.29587.76.camel@johannes.local>
On Fri, 2009-07-31 at 15:39 +0200, Johannes Berg wrote:
> On Fri, 2009-07-31 at 16:19 +0300, Maxim Levitsky wrote:
>
> > First patch makes the probe requests be retried (and with it and only
> > it, my connection is very stable, it never retries more that 3 times,
> > and I set max retries to 5)
> >
> > Second patch, trivial one bumps up the timeouts (30 for ping, and 1/2
> > for response, so device won't send out frames too often)
>
> Thank you!
>
> > diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> > index ee83125..38ef7f2 100644
> > --- a/net/mac80211/mlme.c
> > +++ b/net/mac80211/mlme.c
> > @@ -31,6 +31,7 @@
> > #define IEEE80211_AUTH_MAX_TRIES 3
> > #define IEEE80211_ASSOC_TIMEOUT (HZ / 5)
> > #define IEEE80211_ASSOC_MAX_TRIES 3
> > +#define IEEE80211_ASSOC_RETRIES 5
>
> I'd prefer that be named PROBE_TRIES or something like that?
Fine
>
> > @@ -1209,6 +1210,7 @@ static void ieee80211_mgd_probe_ap(struct ieee80211_sub_if_data *sdata,
> > ieee80211_recalc_ps(sdata->local, -1);
> > mutex_unlock(&sdata->local->iflist_mtx);
> >
> > + sdata->u.mgd.probe_miss_count = 0;
> > ssid = ieee80211_bss_get_ie(&ifmgd->associated->cbss, WLAN_EID_SSID);
> > ieee80211_send_probe_req(sdata, ifmgd->associated->cbss.bssid,
> > ssid + 2, ssid[1], NULL, 0);
>
> That appears to be in the wrong place. Shouldn't that be in the
> _set_associated function? Otherwise you're always setting it to 0 before
> sending the probe?
I thought about this too, but I think this is the right place.
ieee80211_mgd_probe_ap is called to start a probe on an AP, it will
ignore following calls till ether AP responds or we reconnect.
What I did is not to fail after first timeout, but resend the assoc
request once more, thus this function won't be called again.
>
> > @@ -2072,17 +2074,36 @@ static void ieee80211_sta_work(struct work_struct *work)
> > if (ifmgd->flags & (IEEE80211_STA_BEACON_POLL |
> > IEEE80211_STA_CONNECTION_POLL) &&
> > ifmgd->associated) {
> > +
> > + u8 bssid[ETH_ALEN];
>
> drop that empty line please
no problem
>
> > + const u8 *ssid;
> > +
> > + memcpy(bssid, ifmgd->associated->cbss.bssid, ETH_ALEN);
> > +
> > if (time_is_after_jiffies(ifmgd->probe_timeout))
> > run_again(ifmgd, ifmgd->probe_timeout);
> > - else {
> > - u8 bssid[ETH_ALEN];
> > +
> > + else if (ifmgd->probe_miss_count < IEEE80211_ASSOC_RETRIES) {
> > +
> > + printk(KERN_DEBUG "No probe response from AP %pM"
>
> and that one too
same here
>
> > + " after %dms, try %d\n", bssid,
> > + (1000 * IEEE80211_PROBE_WAIT)/HZ,
> > + (int)ifmgd->probe_miss_count);
> > +
> > + ifmgd->probe_miss_count++;
> > + ifmgd->probe_timeout = jiffies + IEEE80211_PROBE_WAIT;
> > + run_again(ifmgd, ifmgd->probe_timeout);
> > +
> > + ssid = ieee80211_bss_get_ie(&ifmgd->associated->cbss, WLAN_EID_SSID);
> > + ieee80211_send_probe_req(sdata, ifmgd->associated->cbss.bssid,
> > + ssid + 2, ssid[1], NULL, 0);
> > + } else {
>
> Shouldn't this just call _probe_ap() again? After you move the setting
> to 0 out of it, that is?
No, first of all I tried it :-). It takes the ifmgd->mtx first of all,
and besides this way it is more logical, ieee80211_mgd_probe_ap is
called once per AP ping, and here we continue it.
Since I have copied these 3 lines from ieee80211_mgd_probe_ap I have no
objection to put them in a new function.
>
> > From: Maxim Levitsky <maximlevitsky@gmail.com>
> >
> > Do a poll every 30 seconds, and wait for response half a second
> >
> > Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
> > ---
> >
> > net/mac80211/mlme.c | 4 ++--
> > 1 files changed, 2 insertions(+), 2 deletions(-)
> >
> >
> > diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> > index 38ef7f2..a8ab40c 100644
> > --- a/net/mac80211/mlme.c
> > +++ b/net/mac80211/mlme.c
> > @@ -42,13 +42,13 @@
> > * Time the connection can be idle before we probe
> > * it to see if we can still talk to the AP.
> > */
> > -#define IEEE80211_CONNECTION_IDLE_TIME (2 * HZ)
> > +#define IEEE80211_CONNECTION_IDLE_TIME (30 * HZ)
> > /*
> > * Time we wait for a probe response after sending
> > * a probe request because of beacon loss or for
> > * checking the connection still works.
> > */
> > -#define IEEE80211_PROBE_WAIT (HZ / 5)
> > +#define IEEE80211_PROBE_WAIT (HZ / 2)
>
>
> Fine with me.
>
> johannes
Best regards,
Maxim Levitsky
^ permalink raw reply
* Re: [PATCH] mac80211: use beacons for connection monitoring
From: Johannes Berg @ 2009-07-31 13:39 UTC (permalink / raw)
To: Maxim Levitsky; +Cc: Reinette Chatre, linville, linux-wireless
In-Reply-To: <1249046380.6418.6.camel@maxim-laptop>
[-- Attachment #1: Type: text/plain, Size: 3573 bytes --]
On Fri, 2009-07-31 at 16:19 +0300, Maxim Levitsky wrote:
> First patch makes the probe requests be retried (and with it and only
> it, my connection is very stable, it never retries more that 3 times,
> and I set max retries to 5)
>
> Second patch, trivial one bumps up the timeouts (30 for ping, and 1/2
> for response, so device won't send out frames too often)
Thank you!
> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> index ee83125..38ef7f2 100644
> --- a/net/mac80211/mlme.c
> +++ b/net/mac80211/mlme.c
> @@ -31,6 +31,7 @@
> #define IEEE80211_AUTH_MAX_TRIES 3
> #define IEEE80211_ASSOC_TIMEOUT (HZ / 5)
> #define IEEE80211_ASSOC_MAX_TRIES 3
> +#define IEEE80211_ASSOC_RETRIES 5
I'd prefer that be named PROBE_TRIES or something like that?
> @@ -1209,6 +1210,7 @@ static void ieee80211_mgd_probe_ap(struct ieee80211_sub_if_data *sdata,
> ieee80211_recalc_ps(sdata->local, -1);
> mutex_unlock(&sdata->local->iflist_mtx);
>
> + sdata->u.mgd.probe_miss_count = 0;
> ssid = ieee80211_bss_get_ie(&ifmgd->associated->cbss, WLAN_EID_SSID);
> ieee80211_send_probe_req(sdata, ifmgd->associated->cbss.bssid,
> ssid + 2, ssid[1], NULL, 0);
That appears to be in the wrong place. Shouldn't that be in the
_set_associated function? Otherwise you're always setting it to 0 before
sending the probe?
> @@ -2072,17 +2074,36 @@ static void ieee80211_sta_work(struct work_struct *work)
> if (ifmgd->flags & (IEEE80211_STA_BEACON_POLL |
> IEEE80211_STA_CONNECTION_POLL) &&
> ifmgd->associated) {
> +
> + u8 bssid[ETH_ALEN];
drop that empty line please
> + const u8 *ssid;
> +
> + memcpy(bssid, ifmgd->associated->cbss.bssid, ETH_ALEN);
> +
> if (time_is_after_jiffies(ifmgd->probe_timeout))
> run_again(ifmgd, ifmgd->probe_timeout);
> - else {
> - u8 bssid[ETH_ALEN];
> +
> + else if (ifmgd->probe_miss_count < IEEE80211_ASSOC_RETRIES) {
> +
> + printk(KERN_DEBUG "No probe response from AP %pM"
and that one too
> + " after %dms, try %d\n", bssid,
> + (1000 * IEEE80211_PROBE_WAIT)/HZ,
> + (int)ifmgd->probe_miss_count);
> +
> + ifmgd->probe_miss_count++;
> + ifmgd->probe_timeout = jiffies + IEEE80211_PROBE_WAIT;
> + run_again(ifmgd, ifmgd->probe_timeout);
> +
> + ssid = ieee80211_bss_get_ie(&ifmgd->associated->cbss, WLAN_EID_SSID);
> + ieee80211_send_probe_req(sdata, ifmgd->associated->cbss.bssid,
> + ssid + 2, ssid[1], NULL, 0);
> + } else {
Shouldn't this just call _probe_ap() again? After you move the setting
to 0 out of it, that is?
> From: Maxim Levitsky <maximlevitsky@gmail.com>
>
> Do a poll every 30 seconds, and wait for response half a second
>
> Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
> ---
>
> net/mac80211/mlme.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
>
> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> index 38ef7f2..a8ab40c 100644
> --- a/net/mac80211/mlme.c
> +++ b/net/mac80211/mlme.c
> @@ -42,13 +42,13 @@
> * Time the connection can be idle before we probe
> * it to see if we can still talk to the AP.
> */
> -#define IEEE80211_CONNECTION_IDLE_TIME (2 * HZ)
> +#define IEEE80211_CONNECTION_IDLE_TIME (30 * HZ)
> /*
> * Time we wait for a probe response after sending
> * a probe request because of beacon loss or for
> * checking the connection still works.
> */
> -#define IEEE80211_PROBE_WAIT (HZ / 5)
> +#define IEEE80211_PROBE_WAIT (HZ / 2)
Fine with me.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] dell-laptop: Fix rfkill state queries
From: Matthew Garrett @ 2009-07-31 13:36 UTC (permalink / raw)
To: Tim Gardner; +Cc: linux-acpi, johannes, linux-wireless
In-Reply-To: <4A72EF60.1090501@tpi.com>
On Fri, Jul 31, 2009 at 07:19:28AM -0600, Tim Gardner wrote:
> This works on an Inspiron 1420 and XPS1330 as far as I was able to test.
> The physical rfkill switch sets 'Hard blocked: yes' for 'phy0: Wireless
> LAN', and everything returns to normal 'blocked: no' when the switch is
> disabled. I was not able to figure out how to get BIT(16) cleared. Is
> that a keyboard function? Anyways,
Might be Fn+F2.
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply
* Re: [PATCH] mac80211: use beacons for connection monitoring
From: Maxim Levitsky @ 2009-07-31 13:19 UTC (permalink / raw)
To: Johannes Berg; +Cc: Reinette Chatre, linville, linux-wireless
In-Reply-To: <1249026181.29587.14.camel@johannes.local>
[-- Attachment #1: Type: text/plain, Size: 5771 bytes --]
On Fri, 2009-07-31 at 09:43 +0200, Johannes Berg wrote:
> On Fri, 2009-07-31 at 10:08 +0300, Maxim Levitsky wrote:
> > On Wed, 2009-07-29 at 14:32 -0700, Reinette Chatre wrote:
> > > From: Reinette Chatre <reinette.chatre@intel.com>
> > >
> > > The connection monitor currently relies on probe requests paired
> > > with probe responses to ensure that a connection is alive. This is
> > > fragile in some environments where probe responses can get lost.
> > > When we receive beacons we can also consider the connection to be
> > > alive, so cancel connection poll instance when we receive a beacon.
> > >
> > > The debug message "cancelling probereq poll due to a received beacon"
> > > is removed as part of this change as this case is hit very often after
> > > the above change and debug log receives significant number of these messages.
> >
> > In my opinion this is the correct solution
> > I did plenty of wireless monitoring, and I see that nobody sends probe
> > requests at that rate (1 per second it seems). This is ridiculous.
>
> Fix it then. Offer an implementation of your superior solution. We've
> done pretty much exactly what you're all pointing out _forever_ in
> mac80211, ever since it was initially merged. Now that it's more
> explicit in the code, people are complaining?
>
> johannes
Here it is:
First patch makes the probe requests be retried (and with it and only
it, my connection is very stable, it never retries more that 3 times,
and I set max retries to 5)
Second patch, trivial one bumps up the timeouts (30 for ping, and 1/2
for response, so device won't send out frames too often)
I attach the patches, since I afraid my mailer would mangle them.
Here they are in-line too:
-------------------------------------------------------------------------------------------------
[MAC80211] Retry probe request few times, before assuming that AP is out of range
From: Maxim Levitsky <maximlevitsky@gmail.com>
Fixes very often reconnects while connected to nearby APs
Signed-off-by: Maxim Levitky <maximlevitsky@gmail.com>
---
net/mac80211/ieee80211_i.h | 1 +
net/mac80211/mlme.c | 27 ++++++++++++++++++++++++---
2 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index aec6853..ac2489b 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -280,6 +280,7 @@ struct ieee80211_if_managed {
struct work_struct beacon_loss_work;
unsigned long probe_timeout;
+ unsigned long probe_miss_count;
struct mutex mtx;
struct ieee80211_bss *associated;
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index ee83125..38ef7f2 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -31,6 +31,7 @@
#define IEEE80211_AUTH_MAX_TRIES 3
#define IEEE80211_ASSOC_TIMEOUT (HZ / 5)
#define IEEE80211_ASSOC_MAX_TRIES 3
+#define IEEE80211_ASSOC_RETRIES 5
/*
* beacon loss detection timeout
@@ -1209,6 +1210,7 @@ static void ieee80211_mgd_probe_ap(struct ieee80211_sub_if_data *sdata,
ieee80211_recalc_ps(sdata->local, -1);
mutex_unlock(&sdata->local->iflist_mtx);
+ sdata->u.mgd.probe_miss_count = 0;
ssid = ieee80211_bss_get_ie(&ifmgd->associated->cbss, WLAN_EID_SSID);
ieee80211_send_probe_req(sdata, ifmgd->associated->cbss.bssid,
ssid + 2, ssid[1], NULL, 0);
@@ -2072,17 +2074,36 @@ static void ieee80211_sta_work(struct work_struct *work)
if (ifmgd->flags & (IEEE80211_STA_BEACON_POLL |
IEEE80211_STA_CONNECTION_POLL) &&
ifmgd->associated) {
+
+ u8 bssid[ETH_ALEN];
+ const u8 *ssid;
+
+ memcpy(bssid, ifmgd->associated->cbss.bssid, ETH_ALEN);
+
if (time_is_after_jiffies(ifmgd->probe_timeout))
run_again(ifmgd, ifmgd->probe_timeout);
- else {
- u8 bssid[ETH_ALEN];
+
+ else if (ifmgd->probe_miss_count < IEEE80211_ASSOC_RETRIES) {
+
+ printk(KERN_DEBUG "No probe response from AP %pM"
+ " after %dms, try %d\n", bssid,
+ (1000 * IEEE80211_PROBE_WAIT)/HZ,
+ (int)ifmgd->probe_miss_count);
+
+ ifmgd->probe_miss_count++;
+ ifmgd->probe_timeout = jiffies + IEEE80211_PROBE_WAIT;
+ run_again(ifmgd, ifmgd->probe_timeout);
+
+ ssid = ieee80211_bss_get_ie(&ifmgd->associated->cbss, WLAN_EID_SSID);
+ ieee80211_send_probe_req(sdata, ifmgd->associated->cbss.bssid,
+ ssid + 2, ssid[1], NULL, 0);
+ } else {
/*
* We actually lost the connection ... or did we?
* Let's make sure!
*/
ifmgd->flags &= ~(IEEE80211_STA_CONNECTION_POLL |
IEEE80211_STA_BEACON_POLL);
- memcpy(bssid, ifmgd->associated->cbss.bssid, ETH_ALEN);
printk(KERN_DEBUG "No probe response from AP %pM"
" after %dms, disconnecting.\n",
bssid, (1000 * IEEE80211_PROBE_WAIT)/HZ);
------------------------------------------------------------------------------------------
[MAC80211] Increase timeouts for AP polling
From: Maxim Levitsky <maximlevitsky@gmail.com>
Do a poll every 30 seconds, and wait for response half a second
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
---
net/mac80211/mlme.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 38ef7f2..a8ab40c 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -42,13 +42,13 @@
* Time the connection can be idle before we probe
* it to see if we can still talk to the AP.
*/
-#define IEEE80211_CONNECTION_IDLE_TIME (2 * HZ)
+#define IEEE80211_CONNECTION_IDLE_TIME (30 * HZ)
/*
* Time we wait for a probe response after sending
* a probe request because of beacon loss or for
* checking the connection still works.
*/
-#define IEEE80211_PROBE_WAIT (HZ / 5)
+#define IEEE80211_PROBE_WAIT (HZ / 2)
#define TMR_RUNNING_TIMER 0
#define TMR_RUNNING_CHANSW 1
[-- Attachment #2: 0001-mac80211-retry-probe-requests --]
[-- Type: text/plain, Size: 2895 bytes --]
[MAC80211] Retry probe request few times, before assuming that AP is out of range
From: Maxim Levitsky <maximlevitsky@gmail.com>
Fixes very often reconnects while connected to nearby APs
Signed-off-by: Maxim Levitky <maximlevitsky@gmail.com>
---
net/mac80211/ieee80211_i.h | 1 +
net/mac80211/mlme.c | 27 ++++++++++++++++++++++++---
2 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index aec6853..ac2489b 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -280,6 +280,7 @@ struct ieee80211_if_managed {
struct work_struct beacon_loss_work;
unsigned long probe_timeout;
+ unsigned long probe_miss_count;
struct mutex mtx;
struct ieee80211_bss *associated;
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index ee83125..38ef7f2 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -31,6 +31,7 @@
#define IEEE80211_AUTH_MAX_TRIES 3
#define IEEE80211_ASSOC_TIMEOUT (HZ / 5)
#define IEEE80211_ASSOC_MAX_TRIES 3
+#define IEEE80211_ASSOC_RETRIES 5
/*
* beacon loss detection timeout
@@ -1209,6 +1210,7 @@ static void ieee80211_mgd_probe_ap(struct ieee80211_sub_if_data *sdata,
ieee80211_recalc_ps(sdata->local, -1);
mutex_unlock(&sdata->local->iflist_mtx);
+ sdata->u.mgd.probe_miss_count = 0;
ssid = ieee80211_bss_get_ie(&ifmgd->associated->cbss, WLAN_EID_SSID);
ieee80211_send_probe_req(sdata, ifmgd->associated->cbss.bssid,
ssid + 2, ssid[1], NULL, 0);
@@ -2072,17 +2074,36 @@ static void ieee80211_sta_work(struct work_struct *work)
if (ifmgd->flags & (IEEE80211_STA_BEACON_POLL |
IEEE80211_STA_CONNECTION_POLL) &&
ifmgd->associated) {
+
+ u8 bssid[ETH_ALEN];
+ const u8 *ssid;
+
+ memcpy(bssid, ifmgd->associated->cbss.bssid, ETH_ALEN);
+
if (time_is_after_jiffies(ifmgd->probe_timeout))
run_again(ifmgd, ifmgd->probe_timeout);
- else {
- u8 bssid[ETH_ALEN];
+
+ else if (ifmgd->probe_miss_count < IEEE80211_ASSOC_RETRIES) {
+
+ printk(KERN_DEBUG "No probe response from AP %pM"
+ " after %dms, try %d\n", bssid,
+ (1000 * IEEE80211_PROBE_WAIT)/HZ,
+ (int)ifmgd->probe_miss_count);
+
+ ifmgd->probe_miss_count++;
+ ifmgd->probe_timeout = jiffies + IEEE80211_PROBE_WAIT;
+ run_again(ifmgd, ifmgd->probe_timeout);
+
+ ssid = ieee80211_bss_get_ie(&ifmgd->associated->cbss, WLAN_EID_SSID);
+ ieee80211_send_probe_req(sdata, ifmgd->associated->cbss.bssid,
+ ssid + 2, ssid[1], NULL, 0);
+ } else {
/*
* We actually lost the connection ... or did we?
* Let's make sure!
*/
ifmgd->flags &= ~(IEEE80211_STA_CONNECTION_POLL |
IEEE80211_STA_BEACON_POLL);
- memcpy(bssid, ifmgd->associated->cbss.bssid, ETH_ALEN);
printk(KERN_DEBUG "No probe response from AP %pM"
" after %dms, disconnecting.\n",
bssid, (1000 * IEEE80211_PROBE_WAIT)/HZ);
[-- Attachment #3: 0002-mac80211-increase-timeouts-for --]
[-- Type: text/plain, Size: 956 bytes --]
[MAC80211] Increase timeouts for AP polling
From: Maxim Levitsky <maximlevitsky@gmail.com>
Do a poll every 30 seconds, and wait for response half a second
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
---
net/mac80211/mlme.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 38ef7f2..a8ab40c 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -42,13 +42,13 @@
* Time the connection can be idle before we probe
* it to see if we can still talk to the AP.
*/
-#define IEEE80211_CONNECTION_IDLE_TIME (2 * HZ)
+#define IEEE80211_CONNECTION_IDLE_TIME (30 * HZ)
/*
* Time we wait for a probe response after sending
* a probe request because of beacon loss or for
* checking the connection still works.
*/
-#define IEEE80211_PROBE_WAIT (HZ / 5)
+#define IEEE80211_PROBE_WAIT (HZ / 2)
#define TMR_RUNNING_TIMER 0
#define TMR_RUNNING_CHANSW 1
^ permalink raw reply related
* Re: [PATCH] dell-laptop: Fix rfkill state queries
From: Tim Gardner @ 2009-07-31 13:19 UTC (permalink / raw)
To: Matthew Garrett; +Cc: linux-acpi, johannes, linux-wireless
In-Reply-To: <1249007138-27354-1-git-send-email-mjg@redhat.com>
Matthew Garrett wrote:
> The current code in dell-laptop is confused about the hardware rfkill
> state. Fix it up such that it's always reported correctly.
>
> Signed-off-by: Matthew Garrett <mjg@redhat.com>
> ---
> drivers/platform/x86/dell-laptop.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/platform/x86/dell-laptop.c b/drivers/platform/x86/dell-laptop.c
> index 74909c4..9061111 100644
> --- a/drivers/platform/x86/dell-laptop.c
> +++ b/drivers/platform/x86/dell-laptop.c
> @@ -197,8 +197,8 @@ static void dell_rfkill_query(struct rfkill *rfkill, void *data)
> dell_send_request(&buffer, 17, 11);
> status = buffer.output[1];
>
> - if (status & BIT(bit))
> - rfkill_set_hw_state(rfkill, !!(status & BIT(16)));
> + rfkill_set_sw_state(rfkill, !!(status & BIT(bit)));
> + rfkill_set_hw_state(rfkill, !(status & BIT(16)));
> }
>
> static const struct rfkill_ops dell_rfkill_ops = {
This works on an Inspiron 1420 and XPS1330 as far as I was able to test.
The physical rfkill switch sets 'Hard blocked: yes' for 'phy0: Wireless
LAN', and everything returns to normal 'blocked: no' when the switch is
disabled. I was not able to figure out how to get BIT(16) cleared. Is
that a keyboard function? Anyways,
Tested-by: Tim Gardner <tim.gardner@canonical.com>
rtg
--
Tim Gardner timg@tpi.com www.tpi.com
OR 503-601-0234 x102 MT 406-443-5357
^ permalink raw reply
* zd1211rw with MIPS architecture: mysterious behavior with zd1211b and AL2230/AL2230S RF Chip
From: Mladen Horvat @ 2009-07-31 13:11 UTC (permalink / raw)
To: linux-wireless
Hello again,
after some search i found another zd1211b usb stick this time with an AL2230
chipset and not an AL2230S as the ones i tested before.
whats really funny.. the stb boots with kernel 2.6.30 and with iwconfig i see
the wlan0 and wmaster0 interfaces.
kerneloutput till there:
[ 0.944000] ohci_hcd 0000:00:14.2: OHCI 1.0, NO legacy support registers
[ 0.944000] ohci_hcd 0000:00:14.2: control 0x083 HCFS=operational CBSR=3
[ 0.944000] ohci_hcd 0000:00:14.2: cmdstatus 0x00000 SOC=0
[ 0.944000] ohci_hcd 0000:00:14.2: intrstatus 0x00000044 RHSC SF
[ 0.944000] ohci_hcd 0000:00:14.2: intrenable 0x8000000a MIE RD WDH
[ 0.944000] ohci_hcd 0000:00:14.2: hcca frame #0003
[ 0.944000] ohci_hcd 0000:00:14.2: roothub.a 01000202 POTPGT=1 NPS NDP=2(2)
[ 0.944000] ohci_hcd 0000:00:14.2: roothub.b 00000000 PPCM=0000 DR=0000
[ 0.944000] ohci_hcd 0000:00:14.2: roothub.status 00008000 DRWE
[ 0.944000] ohci_hcd 0000:00:14.2: roothub.portstatus [0] 0x00010301 CSC
LSDA PPS CCS
[ 0.944000] ohci_hcd 0000:00:14.2: roothub.portstatus [1] 0x00000100 PPS
[ 0.944000] usb usb1: default language 0x0409
[ 0.944000] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001
[ 0.951000] usb usb1: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[ 0.958000] usb usb1: Product: OHCI Host Controller
[ 0.963000] usb usb1: Manufacturer: Linux 2.6.30-dm7025 ohci_hcd
[ 0.970000] usb usb1: SerialNumber: 0000:00:14.2
[ 0.975000] usb usb1: uevent
[ 0.975000] usb usb1: usb_probe_device
[ 0.975000] usb usb1: configuration #1 chosen from 1 choice
[ 0.981000] usb usb1: adding 1-0:1.0 (config #1, interface 0)
[ 0.981000] usb 1-0:1.0: uevent
[ 0.982000] hub 1-0:1.0: usb_probe_interface
[ 0.982000] hub 1-0:1.0: usb_probe_interface - got id
[ 0.982000] hub 1-0:1.0: USB hub found
[ 0.986000] hub 1-0:1.0: 2 ports detected
[ 0.990000] hub 1-0:1.0: standalone hub
[ 0.990000] hub 1-0:1.0: no power switching (usb 1.0)
[ 0.990000] hub 1-0:1.0: global over-current protection
[ 0.990000] hub 1-0:1.0: power on to power good time: 2ms
[ 0.991000] hub 1-0:1.0: local power source is good
[ 0.991000] hub 1-0:1.0: no over-current condition exists
[ 0.991000] hub 1-0:1.0: trying to enable port power on non-switchable hub
[ 0.992000] drivers/usb/core/inode.c: creating file '001'
[ 0.994000] Initializing USB Mass Storage driver...
[ 1.000000] usbcore: registered new interface driver usb-storage
[ 1.006000] USB Mass Storage support registered.
[ 1.012000] usbcore: registered new interface driver ums-alauda
[ 1.019000] usbcore: registered new interface driver ums-cypress
[ 1.026000] usbcore: registered new interface driver ums-datafab
[ 1.033000] usbcore: registered new interface driver ums-freecom
[ 1.040000] usbcore: registered new interface driver ums-isd200
[ 1.046000] usbcore: registered new interface driver ums-jumpshot
[ 1.053000] usbcore: registered new interface driver ums-karma
[ 1.060000] usbcore: registered new interface driver ums-onetouch
[ 1.067000] usbcore: registered new interface driver ums-sddr09
[ 1.074000] usbcore: registered new interface driver ums-sddr55
[ 1.081000] usbcore: registered new interface driver ums-usbat
[ 1.087000] i2c /dev entries driver
[ 1.091000] ohci_hcd 0000:00:14.2: GetStatus roothub.portstatus [0]
= 0x00010301 CSC LSDA PPS CCS
[ 1.091000] hub 1-0:1.0: port 1: status 0301 change 0001
[ 12.281000] usb 1-1: default language 0x0409
[ 12.288000] usb 1-1: New USB device found, idVendor=050d, idProduct=705c
[ 12.294000] usb 1-1: New USB device strings: Mfr=16, Product=32,
SerialNumber=0
[ 12.302000] usb 1-1: Product: USB2.0 WLAN
[ 12.306000] usb 1-1: Manufacturer: Belkin
[ 12.310000] usb 1-1: uevent
[ 14.465000] usb 1-1: usb_probe_device
[ 14.465000] usb 1-1: configuration #1 chosen from 1 choice
[ 14.506000] usb 1-1: adding 1-1:1.0 (config #1, interface 0)
[ 14.506000] usb 1-1:1.0: uevent
[ 14.550000] drivers/usb/core/inode.c: creating file '003'
[ 14.554000] hub 1-0:1.0: state 7 ports 2 chg 0000 evt 0002
[ 16.347000] cfg80211: Calling CRDA to update world regulatory domain
[ 16.963000] read DCA...<7>zd1211rw usb_init()
[ 17.183000] zd1211rw 1-1:1.0: usb_probe_interface
[ 17.183000] zd1211rw 1-1:1.0: usb_probe_interface - got id
[ 17.183000] usb 1-1: print_id() 050d:705c v4810 full
[ 17.196000] hub 1-0:1.0: state 7 ports 2 chg 0000 evt 0002
[ 17.204000] hub 1-0:1.0: state 7 ports 2 chg 0000 evt 0002
[ 17.252000] ohci_hcd 0000:00:14.2: GetStatus roothub.portstatus [0] =
0x00100103 PRSC PPS PES CCS
[ 17.303000] usb 1-1: reset full speed USB device using ohci_hcd and
address 3
[ 17.377000] ohci_hcd 0000:00:14.2: GetStatus roothub.portstatus [0] =
0x00100103 PRSC PPS PES CCS
[ 17.449000] zd1211rw 1-1:1.0: zd_chip_read_mac_addr_fw()
[ 17.509000] ok
[ 18.549000] phy0: Selected rate control algorithm 'minstrel'
[ 18.550000] zd1211rw 1-1:1.0: probe() successful
[ 18.550000] zd1211rw 1-1:1.0: phy0
[ 18.554000] usbcore: registered new interface driver zd1211rw
[ 18.560000] zd1211rw initialized
[ 19.420000] usb usb1: uevent
[ 19.420000] usb 1-0:1.0: uevent
[ 19.421000] usb 1-1: uevent
[ 19.421000] usb 1-1:1.0: uevent
iwconfig
lo no wireless extensions.
eth0 no wireless extensions.
wmaster0 no wireless extensions.
wlan0 IEEE 802.11bg ESSID:""
Mode:Managed Frequency:2.412 GHz Access Point: Not-Associated
Tx-Power=0 dBm
Retry min limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality:0 Signal level:0 Noise level:0
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
until this everything looks like its running .
after issuing an ifconfig wlan0 up :
ifconfig wlan0 up
ifconfig: SIOCSIFFLAGS: Connection timed out
and following kernel messages:
[ 294.473000] zd1211rw 1-1:1.0: zd_usb_init_hw()
[ 294.473000] usb 1-1: request_fw_file() fw name zd1211/zd1211b_ub
[ 294.473000] usb 1-1: firmware: requesting zd1211/zd1211b_ub
[ 294.536000] usb 1-1: upload_firmware() firmware device id 0x4810 is equal to
the actual device id
[ 294.536000] usb 1-1: request_fw_file() fw name zd1211/zd1211b_uphr
[ 294.536000] usb 1-1: firmware: requesting zd1211/zd1211b_uphr
[ 294.609000] usb 1-1: upload_code() transfer size 4018
[ 294.624000] usb 1-1: upload_code() firmware confirm return value 0x01
[ 295.331000] zd1211rw 1-1:1.0: zd_usb_enable_int()
[ 295.331000] zd1211rw 1-1:1.0: zd_usb_enable_int() submit urb 843e1180
[ 295.331000] zd1211rw 1-1:1.0: zd_chip_init_hw()
[ 296.333000] zd1211rw 1-1:1.0: zd_usb_ioread16v() read timed out
[ 296.333000] zd1211rw 1-1:1.0: zd_ioread32v_locked() error:
zd_ioread16v_locked. Error number -145
[ 296.333000] zd1211rw 1-1:1.0: dump_cr() error reading CR_AFTER_PNP. Error
number -145
[ 296.333000] zd1211rw 1-1:1.0: zd_usb_disable_int() urb 843e1180 killed
[ 296.334000] zd1211rw 1-1:1.0: zd_usb_init_hw() couldn't initialize mac. Error
number -145
the same stick runs flawless on a x86 pc with kernel 2.6.30.
as i said, also on the same machine with kernel 2.6.12 and the vendor driver
this stick works without problems.
perhaps someone has an idea ?
regards
Mladen
^ permalink raw reply
* RTL8192SE support status
From: Bartlomiej Zolnierkiewicz @ 2009-07-31 12:31 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-wireless, Greg KH
Hi,
I've been getting some private mail regarding the status of RTL8192SE
wireless chipset support (the chipset is used in some newer netbooks,
i.e. Medion Akoya E1312) so the current situation is:
* I'm not working on it and I don't know if/when the driver is coming.
* Realtek has been queried about the issue two weeks ago but we haven't
heard anything back yet.
* rtl8192su driver present in staging area of the kernel is for RTL8192SU
(USB version of the chipset) and never contained working/complete code
for RTL8192SE (PCI-E version of the chipset) so there is no point in
attempts of reverting some patches in hope that it will make the things
magically work (it won't, please save your time).
Thanks,
Bart
^ permalink raw reply
* Re: [RFC PATCH] rt2x00: FIF_PSPOLL filter flag support
From: Igor Perminov @ 2009-07-31 10:59 UTC (permalink / raw)
To: users; +Cc: linux-wireless
In-Reply-To: <1249037282.2143.15.camel@sunlight>
On Fri, 31/07/2009 at 14:48 +0400, Igor Perminov wrote:
> This patch implements FIF_PSPOLL filter flag support in rt2x00 drivers,
> which has been introduced in mac80211 (see
> http://marc.info/?l=linux-wireless&m=124897986330807&w=2).
This patch implements support of FIF_PSPOLL for all drivers in
drivers/net/wireless/rt2x00 directory. Including rt2400pci, rt2500pci
and rt2500usb, which are not modified at all.
I've tested the patch with rt73usb and rt2500usb sticks only.
Unfortunately, I have no other kinds of Ralink hardware.
Igor
^ permalink raw reply
* [RFC PATCH] rt2x00: FIF_PSPOLL filter flag support
From: Igor Perminov @ 2009-07-31 10:48 UTC (permalink / raw)
To: users; +Cc: linux-wireless
This patch implements FIF_PSPOLL filter flag support in rt2x00 drivers,
which has been introduced in mac80211 (see
http://marc.info/?l=linux-wireless&m=124897986330807&w=2).
Signed-off-by: Igor Perminov <igor.perminov@inbox.ru>
---
drivers/net/wireless/rt2x00/rt2800usb.c | 9 ++++++++-
drivers/net/wireless/rt2x00/rt2x00.h | 6 ++++++
drivers/net/wireless/rt2x00/rt2x00mac.c | 17 +++++++++++++++++
drivers/net/wireless/rt2x00/rt61pci.c | 8 +++++++-
drivers/net/wireless/rt2x00/rt73usb.c | 8 +++++++-
5 files changed, 45 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
index 9efb417..569e904 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -518,7 +518,7 @@ static void rt2800usb_config_filter(struct rt2x00_dev *rt2x00dev,
rt2x00_set_field32(®, RX_FILTER_CFG_DROP_RTS,
!(filter_flags & FIF_CONTROL));
rt2x00_set_field32(®, RX_FILTER_CFG_DROP_PSPOLL,
- !(filter_flags & FIF_CONTROL));
+ !(filter_flags & FIF_PSPOLL));
rt2x00_set_field32(®, RX_FILTER_CFG_DROP_BA, 1);
rt2x00_set_field32(®, RX_FILTER_CFG_DROP_BAR, 0);
rt2x00_set_field32(®, RX_FILTER_CFG_DROP_CNTL,
@@ -2624,6 +2624,13 @@ static int rt2800usb_probe_hw(struct rt2x00_dev *rt2x00dev)
return retval;
/*
+ * This device has multiple filters for control frames
+ * and has a separate filter for PS Poll frames.
+ */
+ __set_bit(DRIVER_HAS_MULTIPLE_CONTROL_FILTER, &rt2x00dev->flags);
+ __set_bit(DRIVER_HAS_PSPOLL_FILTER, &rt2x00dev->flags);
+
+ /*
* This device requires firmware.
*/
__set_bit(DRIVER_REQUIRE_FIRMWARE, &rt2x00dev->flags);
diff --git a/drivers/net/wireless/rt2x00/rt2x00.h b/drivers/net/wireless/rt2x00/rt2x00.h
index cbec91e..b958e0d 100644
--- a/drivers/net/wireless/rt2x00/rt2x00.h
+++ b/drivers/net/wireless/rt2x00/rt2x00.h
@@ -607,6 +607,12 @@ enum rt2x00_flags {
DRIVER_REQUIRE_L2PAD,
/*
+ * Driver capabilities
+ */
+ DRIVER_HAS_MULTIPLE_CONTROL_FILTER,
+ DRIVER_HAS_PSPOLL_FILTER,
+
+ /*
* Driver features
*/
CONFIG_SUPPORT_HW_BUTTON,
diff --git a/drivers/net/wireless/rt2x00/rt2x00mac.c b/drivers/net/wireless/rt2x00/rt2x00mac.c
index e92c8f9..eba168d 100644
--- a/drivers/net/wireless/rt2x00/rt2x00mac.c
+++ b/drivers/net/wireless/rt2x00/rt2x00mac.c
@@ -407,6 +407,7 @@ void rt2x00mac_configure_filter(struct ieee80211_hw *hw,
FIF_FCSFAIL |
FIF_PLCPFAIL |
FIF_CONTROL |
+ FIF_PSPOLL |
FIF_OTHER_BSS |
FIF_PROMISC_IN_BSS;
@@ -422,6 +423,22 @@ void rt2x00mac_configure_filter(struct ieee80211_hw *hw,
*total_flags |= FIF_PROMISC_IN_BSS | FIF_OTHER_BSS;
/*
+ * If the device has a single filter for all control frames,
+ * FIF_CONTROL and FIF_PSPOLL flags imply each other.
+ * And if the device has more than one filter for control frames
+ * of different types, but has no a separate filter for PS Poll frames,
+ * FIF_CONTROL flag implies FIF_PSPOLL.
+ */
+ if (!test_bit(DRIVER_HAS_MULTIPLE_CONTROL_FILTER, &rt2x00dev->flags)) {
+ if (*total_flags & FIF_CONTROL ||
+ *total_flags & FIF_PSPOLL)
+ *total_flags |= FIF_CONTROL | FIF_PSPOLL;
+ } else if (!test_bit(DRIVER_HAS_PSPOLL_FILTER, &rt2x00dev->flags)) {
+ if (*total_flags & FIF_CONTROL)
+ *total_flags |= FIF_PSPOLL;
+ }
+
+ /*
* Check if there is any work left for us.
*/
if (rt2x00dev->packet_filter == *total_flags)
diff --git a/drivers/net/wireless/rt2x00/rt61pci.c b/drivers/net/wireless/rt2x00/rt61pci.c
index fb95b8c..2f5a209 100644
--- a/drivers/net/wireless/rt2x00/rt61pci.c
+++ b/drivers/net/wireless/rt2x00/rt61pci.c
@@ -530,7 +530,7 @@ static void rt61pci_config_filter(struct rt2x00_dev *rt2x00dev,
rt2x00_set_field32(®, TXRX_CSR0_DROP_PHYSICAL,
!(filter_flags & FIF_PLCPFAIL));
rt2x00_set_field32(®, TXRX_CSR0_DROP_CONTROL,
- !(filter_flags & FIF_CONTROL));
+ !(filter_flags & (FIF_CONTROL | FIF_PSPOLL)));
rt2x00_set_field32(®, TXRX_CSR0_DROP_NOT_TO_ME,
!(filter_flags & FIF_PROMISC_IN_BSS));
rt2x00_set_field32(®, TXRX_CSR0_DROP_TO_DS,
@@ -2619,6 +2619,12 @@ static int rt61pci_probe_hw(struct rt2x00_dev *rt2x00dev)
return retval;
/*
+ * This device has multiple filters for control frames,
+ * but has no a separate filter for PS Poll frames.
+ */
+ __set_bit(DRIVER_HAS_MULTIPLE_CONTROL_FILTER, &rt2x00dev->flags);
+
+ /*
* This device requires firmware and DMA mapped skbs.
*/
__set_bit(DRIVER_REQUIRE_FIRMWARE, &rt2x00dev->flags);
diff --git a/drivers/net/wireless/rt2x00/rt73usb.c b/drivers/net/wireless/rt2x00/rt73usb.c
index 4f9b177..a89fcb7 100644
--- a/drivers/net/wireless/rt2x00/rt73usb.c
+++ b/drivers/net/wireless/rt2x00/rt73usb.c
@@ -493,7 +493,7 @@ static void rt73usb_config_filter(struct rt2x00_dev *rt2x00dev,
rt2x00_set_field32(®, TXRX_CSR0_DROP_PHYSICAL,
!(filter_flags & FIF_PLCPFAIL));
rt2x00_set_field32(®, TXRX_CSR0_DROP_CONTROL,
- !(filter_flags & FIF_CONTROL));
+ !(filter_flags & (FIF_CONTROL | FIF_PSPOLL)));
rt2x00_set_field32(®, TXRX_CSR0_DROP_NOT_TO_ME,
!(filter_flags & FIF_PROMISC_IN_BSS));
rt2x00_set_field32(®, TXRX_CSR0_DROP_TO_DS,
@@ -2144,6 +2144,12 @@ static int rt73usb_probe_hw(struct rt2x00_dev *rt2x00dev)
return retval;
/*
+ * This device has multiple filters for control frames,
+ * but has no a separate filter for PS Poll frames.
+ */
+ __set_bit(DRIVER_HAS_MULTIPLE_CONTROL_FILTER, &rt2x00dev->flags);
+
+ /*
* This device requires firmware.
*/
__set_bit(DRIVER_REQUIRE_FIRMWARE, &rt2x00dev->flags);
^ permalink raw reply related
* Re: [PATCH] mac80211: use beacons for connection monitoring
From: Marcel Holtmann @ 2009-07-31 9:41 UTC (permalink / raw)
To: Maxim Levitsky; +Cc: Johannes Berg, Reinette Chatre, linville, linux-wireless
In-Reply-To: <1249027460.2609.2.camel@maxim-laptop>
Hi Maxim,
> > > Fix it then. Offer an implementation of your superior solution.
> >
> > I just don't think that this patch is a solution because it means that
> > we'll be connected to the AP forever, without knowing anything is wrong,
> > if the AP can reach us but we can't reach the AP (maybe because we have
> > a good Intel card with great sensitivity).
> >
> > Sure -- it's possible to factor in transmit status reports (but remember
> > that not all hardware gives those reliably) or do things on a different
> > schedule etc. But as long as nobody wants to really improve things I
> > don't see why we should take the regression and _remove_ the current
> > behaviour.
>
> It is ok to send probes every minute or so, but not each second, and
> probes must be retried.
>
> Because of these probes, wireless literally reconnects every 5 seconds,
> here, and I am 10 meters from the AP.
even with Reinette's patch, I am seeing this:
[18594.423855] wlan0: cancelling probereq poll due to a received beacon
[18629.544841] No probe response from AP 00:1c:f0:xx:xx:xx after 200ms, disconnecting.
So that is with the patch, being 1m away from the AP, in the 18th floor
of a building and with only another 10 APs around me.
The Bluetooth world calls this link supervision timeout and the default
value for that timeout is 30 seconds. I think it is the best to make
this value configurable and increase it to at least 30 seconds by
default. Within Bluetooth you can change it and runtime.
Johannes, I don't care how good or bad some hardware is. How sensitive
or not. This is a clear regression and you are overdoing it here with
only waiting for 200ms.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] cfg80211: lower dynamic PS timeout to 100ms
From: Kalle Valo @ 2009-07-31 9:20 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, linux-wireless
In-Reply-To: <1249031893.29587.63.camel@johannes.local>
Johannes Berg <johannes@sipsolutions.net> writes:
> The default of 500ms is pretty high, and leads
> to the device being awake at least 50% of the
> time under such light traffic conditions as a
> simple 1 second interval ping. Reduce to just
> 100ms -- it should have a similar effect while
> providing a better sleep time.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
I agree, 500 ms is too long.
Reviewed-by: Kalle Valo <kalle.valo@iki.fi>
--
Kalle Valo
^ permalink raw reply
* [PATCH] cfg80211: lower dynamic PS timeout to 100ms
From: Johannes Berg @ 2009-07-31 9:18 UTC (permalink / raw)
To: John Linville; +Cc: Kalle Valo, linux-wireless
The default of 500ms is pretty high, and leads
to the device being awake at least 50% of the
time under such light traffic conditions as a
simple 1 second interval ping. Reduce to just
100ms -- it should have a similar effect while
providing a better sleep time.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
net/wireless/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- wireless-testing.orig/net/wireless/core.c 2009-07-31 11:15:32.000000000 +0200
+++ wireless-testing/net/wireless/core.c 2009-07-31 11:15:40.000000000 +0200
@@ -673,7 +673,7 @@ static int cfg80211_netdev_notifier_call
wdev->wext.default_mgmt_key = -1;
wdev->wext.connect.auth_type = NL80211_AUTHTYPE_AUTOMATIC;
wdev->wext.ps = CONFIG_CFG80211_DEFAULT_PS_VALUE;
- wdev->wext.ps_timeout = 500;
+ wdev->wext.ps_timeout = 100;
if (rdev->ops->set_power_mgmt)
if (rdev->ops->set_power_mgmt(wdev->wiphy, dev,
wdev->wext.ps,
^ permalink raw reply
* Re: [PATCH] Fix SPARC64 unaligned access in zd_mac_rx
From: Johannes Berg @ 2009-07-31 8:39 UTC (permalink / raw)
To: Patrick Simmons; +Cc: linux-wireless, Daniel Drake, Ulrich Kunitz
In-Reply-To: <4A72A462.6060107@netscape.net>
[-- Attachment #1: Type: text/plain, Size: 469 bytes --]
On Fri, 2009-07-31 at 01:59 -0600, Patrick Simmons wrote:
> I'm running zd1211rw on SPARC64 and was getting a lot of "unaligned
> access" messages in dmesg. I tracked the problem down to this line, and
> changing the cast to a memcpy fixes the issue.
>
> - fc = *(__le16 *)buffer;
> + memcpy(&fc,buffer,sizeof(__le16));
> need_padding = ieee80211_is_data_qos(fc) ^ ieee80211_has_a4(fc);
Please use get_unaligned instead.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH] Fix SPARC64 unaligned access in zd_mac_rx
From: Patrick Simmons @ 2009-07-31 7:59 UTC (permalink / raw)
To: linux-wireless; +Cc: Daniel Drake, Ulrich Kunitz
I'm running zd1211rw on SPARC64 and was getting a lot of "unaligned
access" messages in dmesg. I tracked the problem down to this line, and
changing the cast to a memcpy fixes the issue.
Please CC me with any comments as I am not subscribed to the list.
Signed-off-by: Patrick Simmons <linuxrocks123@netscape.net>
--- a/drivers/net/wireless/zd1211rw/zd_mac.c 2009-07-30
23:23:50.000000000 -0600
+++ b/drivers/net/wireless/zd1211rw/zd_mac.c 2009-07-30
23:58:19.000000000 -0600
@@ -694,7 +694,7 @@
&& !mac->pass_ctrl)
return 0;
- fc = *(__le16 *)buffer;
+ memcpy(&fc,buffer,sizeof(__le16));
need_padding = ieee80211_is_data_qos(fc) ^ ieee80211_has_a4(fc);
skb = dev_alloc_skb(length + (need_padding ? 2 : 0));
^ permalink raw reply
* Re: [PATCH] mac80211: use beacons for connection monitoring
From: Maxim Levitsky @ 2009-07-31 8:04 UTC (permalink / raw)
To: Johannes Berg; +Cc: Reinette Chatre, linville, linux-wireless
In-Reply-To: <1249027087.29587.18.camel@johannes.local>
On Fri, 2009-07-31 at 09:58 +0200, Johannes Berg wrote:
> On Fri, 2009-07-31 at 09:43 +0200, Johannes Berg wrote:
>
> > Fix it then. Offer an implementation of your superior solution.
>
> I just don't think that this patch is a solution because it means that
> we'll be connected to the AP forever, without knowing anything is wrong,
> if the AP can reach us but we can't reach the AP (maybe because we have
> a good Intel card with great sensitivity).
>
> Sure -- it's possible to factor in transmit status reports (but remember
> that not all hardware gives those reliably) or do things on a different
> schedule etc. But as long as nobody wants to really improve things I
> don't see why we should take the regression and _remove_ the current
> behaviour.
>
> johannes
It is ok to send probes every minute or so, but not each second, and
probes must be retried.
Because of these probes, wireless literally reconnects every 5 seconds,
here, and I am 10 meters from the AP.
Maxim
^ permalink raw reply
* Re: [PATCH] mac80211: use beacons for connection monitoring
From: Johannes Berg @ 2009-07-31 7:58 UTC (permalink / raw)
To: Maxim Levitsky; +Cc: Reinette Chatre, linville, linux-wireless
In-Reply-To: <1249026181.29587.14.camel@johannes.local>
[-- Attachment #1: Type: text/plain, Size: 704 bytes --]
On Fri, 2009-07-31 at 09:43 +0200, Johannes Berg wrote:
> Fix it then. Offer an implementation of your superior solution.
I just don't think that this patch is a solution because it means that
we'll be connected to the AP forever, without knowing anything is wrong,
if the AP can reach us but we can't reach the AP (maybe because we have
a good Intel card with great sensitivity).
Sure -- it's possible to factor in transmit status reports (but remember
that not all hardware gives those reliably) or do things on a different
schedule etc. But as long as nobody wants to really improve things I
don't see why we should take the regression and _remove_ the current
behaviour.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] cfg80211: fix regression on beacon world roaming feature
From: Johannes Berg @ 2009-07-31 7:45 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linville, linux-wireless, Jouni Malinen
In-Reply-To: <1249001028-15110-1-git-send-email-lrodriguez@atheros.com>
[-- Attachment #1: Type: text/plain, Size: 651 bytes --]
On Thu, 2009-07-30 at 17:43 -0700, Luis R. Rodriguez wrote:
> By doing so though we also disallowed beacon hints on devices
> registering their wiphy with custom world regulatory domains
> enabled, this happens to be currently ath5k, ath9k and ar9170.
> The passive scan and beacon restrictions on those devices would
> never be lifted even if we did find a beacon and the hardware did
> support such enhancements when world roaming.
I dislike this solution, it just adds proliferation of possible
behaviours. Can't those devices just set the _flags_ in their reg
notifier, and clear the corresponding bit in the orig_flags?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] mac80211: use beacons for connection monitoring
From: Johannes Berg @ 2009-07-31 7:43 UTC (permalink / raw)
To: Maxim Levitsky; +Cc: Reinette Chatre, linville, linux-wireless
In-Reply-To: <1249024097.7653.6.camel@maxim-laptop>
[-- Attachment #1: Type: text/plain, Size: 1236 bytes --]
On Fri, 2009-07-31 at 10:08 +0300, Maxim Levitsky wrote:
> On Wed, 2009-07-29 at 14:32 -0700, Reinette Chatre wrote:
> > From: Reinette Chatre <reinette.chatre@intel.com>
> >
> > The connection monitor currently relies on probe requests paired
> > with probe responses to ensure that a connection is alive. This is
> > fragile in some environments where probe responses can get lost.
> > When we receive beacons we can also consider the connection to be
> > alive, so cancel connection poll instance when we receive a beacon.
> >
> > The debug message "cancelling probereq poll due to a received beacon"
> > is removed as part of this change as this case is hit very often after
> > the above change and debug log receives significant number of these messages.
>
> In my opinion this is the correct solution
> I did plenty of wireless monitoring, and I see that nobody sends probe
> requests at that rate (1 per second it seems). This is ridiculous.
Fix it then. Offer an implementation of your superior solution. We've
done pretty much exactly what you're all pointing out _forever_ in
mac80211, ever since it was initially merged. Now that it's more
explicit in the code, people are complaining?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] mac80211: use beacons for connection monitoring
From: Maxim Levitsky @ 2009-07-31 7:08 UTC (permalink / raw)
To: Reinette Chatre; +Cc: johannes, linville, linux-wireless
In-Reply-To: <1248903159-17024-1-git-send-email-reinette.chatre@intel.com>
On Wed, 2009-07-29 at 14:32 -0700, Reinette Chatre wrote:
> From: Reinette Chatre <reinette.chatre@intel.com>
>
> The connection monitor currently relies on probe requests paired
> with probe responses to ensure that a connection is alive. This is
> fragile in some environments where probe responses can get lost.
> When we receive beacons we can also consider the connection to be
> alive, so cancel connection poll instance when we receive a beacon.
>
> The debug message "cancelling probereq poll due to a received beacon"
> is removed as part of this change as this case is hit very often after
> the above change and debug log receives significant number of these messages.
In my opinion this is the correct solution
I did plenty of wireless monitoring, and I see that nobody sends probe
requests at that rate (1 per second it seems). This is ridiculous.
According to the monitor on my iwl3945, (which might though be
incorrect), sometimes AP doesn't respond in time, but then later it
sends a storm (about 5 or so) probe responses at once (after the deauth)
I think that while wireless is fast most AP aren't, (mine is 150 Mhz
mips system for example), thus it can delay the response for more that
200 ms.
I think that the right solution is to send probes every minute or so,
and retry at last few times, before concluding that connection is lost.
(and if beacons are lost for a prolonged period it might make a sense to
send a probe earlier)
Best regards,
Maxim Levitsky
^ 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