I'm using:
[ebuild R ] net-wireless/wireless-regdb-20090130 0 kB
[ebuild R ] net-wireless/crda-1.0.1-r1 0 kB
[ebuild R ] net-wireless/iwl5000-ucode-5.4.0.11 0 kB
The regulatory information for Great Britain looks as follows:
country GB:
(2402.000 - 2482.000 @ 40.000), (N/A, 20.00)
(5170.000 - 5250.000 @ 40.000), (N/A, 20.00)
(5250.000 - 5330.000 @ 40.000), (N/A, 20.00), DFS
(5490.000 - 5710.000 @ 40.000), (N/A, 27.00), DFS
iw reports the card configuration like such:
Wiphy phy0
Band 1:
HT capabilities: 0x087e
* 20/40 MHz operation
* SM PS disabled
* HT-greenfield
* 20 MHz short GI
* 40 MHz short GI
* max A-MSDU len 7935
HT A-MPDU factor: 0x0003 (65535 bytes)
HT A-MPDU density: 0x0005 (4 usec)
HT MCS set: ff ff ff 00 01 00 00 00 00 00 c2 01 01 00 00 00
Frequencies:
* 2412 MHz [1] (15.0 dBm)
* 2417 MHz [2] (15.0 dBm)
* 2422 MHz [3] (15.0 dBm)
* 2427 MHz [4] (15.0 dBm)
* 2432 MHz [5] (15.0 dBm)
* 2437 MHz [6] (15.0 dBm)
* 2442 MHz [7] (15.0 dBm)
* 2447 MHz [8] (15.0 dBm)
* 2452 MHz [9] (15.0 dBm)
* 2457 MHz [10] (15.0 dBm)
* 2462 MHz [11] (15.0 dBm)
* 2467 MHz [12] (15.0 dBm) (passive scanning, no IBSS)
* 2472 MHz [13] (15.0 dBm) (passive scanning, no IBSS)
Bitrates:
* 1.0 Mbps
* 2.0 Mbps (short preamble supported)
* 5.5 Mbps (short preamble supported)
* 11.0 Mbps (short preamble supported)
* 6.0 Mbps
* 9.0 Mbps
* 12.0 Mbps
* 18.0 Mbps
* 24.0 Mbps
* 36.0 Mbps
* 48.0 Mbps
* 54.0 Mbps
* 60.0 Mbps
Band 2:
HT capabilities: 0x087e
* 20/40 MHz operation
* SM PS disabled
* HT-greenfield
* 20 MHz short GI
* 40 MHz short GI
* max A-MSDU len 7935
HT A-MPDU factor: 0x0003 (65535 bytes)
HT A-MPDU density: 0x0005 (4 usec)
HT MCS set: ff ff ff 00 01 00 00 00 00 00 c2 01 01 00 00 00
Frequencies:
* 5180 MHz [36] (disabled)
* 5200 MHz [40] (disabled)
* 5220 MHz [44] (disabled)
* 5240 MHz [48] (disabled)
* 5260 MHz [52] (disabled)
* 5280 MHz [56] (disabled)
* 5300 MHz [60] (disabled)
* 5320 MHz [64] (disabled)
* 5500 MHz [100] (disabled)
* 5520 MHz [104] (disabled)
* 5540 MHz [108] (disabled)
* 5560 MHz [112] (disabled)
* 5580 MHz [116] (disabled)
* 5600 MHz [120] (disabled)
* 5620 MHz [124] (disabled)
* 5640 MHz [128] (disabled)
* 5660 MHz [132] (disabled)
* 5680 MHz [136] (disabled)
* 5700 MHz [140] (disabled)
* 5745 MHz [149] (disabled)
* 5765 MHz [153] (disabled)
* 5785 MHz [157] (disabled)
* 5805 MHz [161] (disabled)
* 5825 MHz [165] (disabled)
Bitrates:
* 6.0 Mbps
* 9.0 Mbps
* 12.0 Mbps
* 18.0 Mbps
* 24.0 Mbps
* 36.0 Mbps
* 48.0 Mbps
* 54.0 Mbps
* 60.0 Mbps
Supported interface modes:
* IBSS
* Station
* Monitor
My Cisco AIR-AP1131AG-E-K9_v04 access point with C1130 Software
(C1130-K9W7-M), Version 12.4(10b)JA, RELEASE has Dot11Radio0 &
Dot11Radio1 configured like so:
world-mode dot11d country GB indoor
The kernel seems to do something else:
cfg80211: Calling CRDA for country: GB
cfg80211: Current regulatory domain updated by AP to: GB
(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
(2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
Any idea how that could happen please?
Regards,
Tony V.
On Wed, Feb 11, 2009 at 11:19 AM, Tony Vroon <[email protected]> wrote:
> Clear run, haven't touched iw, still no 802.11A spectrum. dmesg
> attached. Any suggestion for a workaround that will get me my networks
> back please? (Besides enabling the old regulatory options, which is
> scheduled to be taken away from me soon)
Looks good here -- can you please provide 'iw list' output prior to
trying to associate.
Luis
On Mon, 2009-02-09 at 17:39 -0800, Luis R. Rodriguez wrote:
> In Intel's case the first regulatory domain is ignored (world). To see,
> before associating to an AP try running 'iw list'.
I will remove NetworkManager & gdm from the default runlevel and try
that, yes.
> I noticed that, what ends up happening then is the static world regulatory
> domain is used from the kernel. I take it you used an initramfs with the
> sda driver in there?
No. There's an initramfs, but it's only used to unlock the encrypted
root filesystem. The actual driver for sda (ata_piix) is in the kernel.
> I've been using initramfs too but for some reason
> on my system udev triggers the request eventually after the drive
> is mounted. So this is the first time I hear of this.
I have another user reporting it on PowerPC, without an encrypted root.
> I also noticed though:
>
> cfg80211: Calling CRDA for country: GB
> cfg80211: Current regulatory intersected:
> (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
> (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
>
> This seems to indicate to me you manually ran:
>
> sudo iw reg set GB
>
> Is that the case?
Eventually, yes. To see if that would clear things up, but it didn't.
Even if I just leave the AP 802.11d info to fill in the regulatory
information (which you can see higher up, as it has the information
slightly wrong and includes channel 14 together with very high radio
power) the 5GHz channels are not included.
As said, will do an iw list with no other software having fiddled with
anything yet. The Cisco APs are in the vicinity so I may not be able to
stop them picking up the 80211d info though.
Regards,
Tony V.
On Mon, Feb 09, 2009 at 05:51:29PM -0800, Tony Vroon wrote:
> On Mon, 2009-02-09 at 17:39 -0800, Luis R. Rodriguez wrote:
> > In Intel's case the first regulatory domain is ignored (world). To see,
> > before associating to an AP try running 'iw list'.
>
> I will remove NetworkManager & gdm from the default runlevel and try
> that, yes.
>
> > I noticed that, what ends up happening then is the static world regulatory
> > domain is used from the kernel. I take it you used an initramfs with the
> > sda driver in there?
>
> No. There's an initramfs, but it's only used to unlock the encrypted
> root filesystem. The actual driver for sda (ata_piix) is in the kernel.
Intersting -- this is the first case I hear about this.
> > I've been using initramfs too but for some reason
> > on my system udev triggers the request eventually after the drive
> > is mounted. So this is the first time I hear of this.
>
> I have another user reporting it on PowerPC, without an encrypted root.
Are they also disabling OLD_REG? Note that the only routine I see
failing then in the initial:
err = __regulatory_hint(NULL, REGDOM_SET_BY_CORE, "00", 0, ENVIRON_ANY);
Is a kmalloc() (unlikely) or call_crda() failing, and call_crda() will
only fail if kobject_uevent_env() fails and last I checked that would
fail only if the kernel failed to build and emit the udev event (it doesn't mean
CRDA was not present, it should mean udev never got the udev event IIRC).
> > I also noticed though:
> >
> > cfg80211: Calling CRDA for country: GB
> > cfg80211: Current regulatory intersected:
> > (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
> > (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
> >
> > This seems to indicate to me you manually ran:
> >
> > sudo iw reg set GB
> >
> > Is that the case?
>
> Eventually, yes.
Oh? Hmm.. if we leave the channel intact before applying the intersected
regulatory domain and if 'iw list' shows the 5 GHz channels it should mean
they are left enabled, I'm a bit puzzled myself, unless I'm missing something.
> To see if that would clear things up, but it didn't.
> Even if I just leave the AP 802.11d info to fill in the regulatory
> information (which you can see higher up, as it has the information
> slightly wrong and includes channel 14 together with very high radio
> power) the 5GHz channels are not included.
Heh :)
> As said, will do an iw list with no other software having fiddled with
> anything yet. The Cisco APs are in the vicinity so I may not be able to
> stop them picking up the 80211d info though.
Actually we don't follow country IE hints in Linux until we associate
to an AP so you should be good.
Luis
On Wed, Feb 11, 2009 at 11:19:41AM -0800, Tony Vroon wrote:
> Clear run, haven't touched iw, still no 802.11A spectrum. dmesg
> attached. Any suggestion for a workaround that will get me my networks
> back please? (Besides enabling the old regulatory options, which is
> scheduled to be taken away from me soon)
>
> Regards,
> Tony V.
> Linux version 2.6.29-rc4-00026-gf06da26 (root@amalthea) (gcc version 4.3.3 (Gentoo 4.3.3 p1.0, pie-10.1.5) ) #1 SMP Mon Feb 9 18:55:10 GMT 2009
> Command line: auto BOOT_IMAGE=2.6.29-rc4-0002 rw root=0 video=vesafb:ywrap,pmipal,mtrr
> KERNEL supported cpus:
> Intel GenuineIntel
> AMD AuthenticAMD
> Centaur CentaurHauls
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 000000000009d400 (usable)
> BIOS-e820: 000000000009d400 - 00000000000a0000 (reserved)
> BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
> BIOS-e820: 0000000000100000 - 00000000bce51000 (usable)
> BIOS-e820: 00000000bce51000 - 00000000bce57000 (reserved)
> BIOS-e820: 00000000bce57000 - 00000000bd058000 (usable)
> BIOS-e820: 00000000bd058000 - 00000000bd0af000 (reserved)
> BIOS-e820: 00000000bd0af000 - 00000000bd1a8000 (usable)
> BIOS-e820: 00000000bd1a8000 - 00000000bd4af000 (reserved)
> BIOS-e820: 00000000bd4af000 - 00000000bd4d8000 (usable)
> BIOS-e820: 00000000bd4d8000 - 00000000bd4df000 (reserved)
> BIOS-e820: 00000000bd4df000 - 00000000bd535000 (usable)
> BIOS-e820: 00000000bd535000 - 00000000bd57f000 (ACPI NVS)
> BIOS-e820: 00000000bd57f000 - 00000000bd5e4000 (usable)
> BIOS-e820: 00000000bd5e4000 - 00000000bd5fd000 (ACPI data)
> BIOS-e820: 00000000bd5fd000 - 00000000bd600000 (usable)
> BIOS-e820: 00000000bd600000 - 00000000c0000000 (reserved)
> BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
> BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
> BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved)
> BIOS-e820: 00000000fed10000 - 00000000fed14000 (reserved)
> BIOS-e820: 00000000fed18000 - 00000000fed1a000 (reserved)
> BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved)
> BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
> BIOS-e820: 00000000ff800000 - 0000000100000000 (reserved)
> DMI 2.4 present.
> last_pfn = 0xbd600 max_arch_pfn = 0x100000000
> x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
> init_memory_mapping: 0000000000000000-00000000bd600000
> 0000000000 - 00bd600000 page 2M
> kernel direct mapping tables up to bd600000 @ 8000-c000
> last_map_addr: bd600000 end: bd600000
> ACPI: RSDP 000F53D0, 0024 (r2 FUJ )
> ACPI: XSDT BD5F3434, 0074 (r1 FSC PC 1160000 FUJ 100)
> ACPI: FACP BD5E6000, 00F4 (r3 FSC PC 1160000 FUJ 100)
> FADT: X_PM1a_EVT_BLK.bit_width (16) does not match PM1_EVT_LEN (4)
> ACPI: DSDT BD5E7000, 8CFF (r1 FUJ FJNB1E6 1160000 FUJ 100)
> ACPI: FACS BD56EFC0, 0040
> ACPI: SSDT BD5FC1DF, 034F (r1 FUJ FJNB1E6 1160000 FUJ 100)
> ACPI: HPET BD5FC622, 0038 (r1 FUJ FJNB1E6 1160000 FUJ 100)
> ACPI: MCFG BD5FC65A, 003C (r1 FUJ FJNB1E6 1160000 FUJ 100)
> ACPI: SSDT BD5FC696, 042F (r1 FUJ FJNB1E6 1160000 FUJ 100)
> ACPI: SSDT BD5FCAC5, 02C1 (r1 FUJ FJNB1E6 1160000 FUJ 100)
> ACPI: APIC BD5FCD86, 0068 (r1 FUJ FJNB1E6 1160000 FUJ 100)
> ACPI: BOOT BD5FCDEE, 0028 (r1 FUJ FJNB1E6 1160000 FUJ 100)
> ACPI: SLIC BD5FCE16, 0176 (r1 FSC PC 1160000 FUJ 100)
> ACPI: SSDT BD5E5000, 04E6 (r1 PmRef CpuPm 3000 INTL 20050624)
> ACPI: Local APIC address 0xfee00000
> (5 early reservations) ==> bootmem [0000000000 - 00bd600000]
> #0 [0000000000 - 0000001000] BIOS data page ==> [0000000000 - 0000001000]
> #1 [0000006000 - 0000008000] TRAMPOLINE ==> [0000006000 - 0000008000]
> #2 [0000200000 - 00009f3dec] TEXT DATA BSS ==> [0000200000 - 00009f3dec]
> #3 [000009d400 - 0000100000] BIOS reserved ==> [000009d400 - 0000100000]
> #4 [0000008000 - 000000a000] PGTABLE ==> [0000008000 - 000000a000]
> [ffffe20000000000-ffffe200029fffff] PMD -> [ffff880001200000-ffff880003bfffff] on node 0
> Zone PFN ranges:
> DMA 0x00000000 -> 0x00001000
> DMA32 0x00001000 -> 0x00100000
> Normal 0x00100000 -> 0x00100000
> Movable zone start PFN for each node
> early_node_map[8] active PFN ranges
> 0: 0x00000000 -> 0x0000009d
> 0: 0x00000100 -> 0x000bce51
> 0: 0x000bce57 -> 0x000bd058
> 0: 0x000bd0af -> 0x000bd1a8
> 0: 0x000bd4af -> 0x000bd4d8
> 0: 0x000bd4df -> 0x000bd535
> 0: 0x000bd57f -> 0x000bd5e4
> 0: 0x000bd5fd -> 0x000bd600
> On node 0 totalpages: 774607
> DMA zone: 56 pages used for memmap
> DMA zone: 2138 pages reserved
> DMA zone: 1803 pages, LIFO batch:0
> DMA32 zone: 10549 pages used for memmap
> DMA32 zone: 760061 pages, LIFO batch:31
> ACPI: PM-Timer IO Port: 0x408
> ACPI: Local APIC address 0xfee00000
> ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
> ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
> ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
> ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
> ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
> IOAPIC[0]: apic_id 2, version 0, address 0xfec00000, GSI 0-23
> ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
> 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.
> Using ACPI (MADT) for SMP configuration information
> ACPI: HPET id: 0x8086a201 base: 0xfed00000
> SMP: Allowing 2 CPUs, 0 hotplug CPUs
> Allocating PCI resources starting at c2000000 (gap: c0000000:20000000)
> NR_CPUS:2 nr_cpumask_bits:2 nr_cpu_ids:2 nr_node_ids:1
> PERCPU: Allocating 49152 bytes of per cpu data
> Built 1 zonelists in Zone order, mobility grouping on. Total pages: 761864
> Kernel command line: auto BOOT_IMAGE=2.6.29-rc4-0002 rw root=0 video=vesafb:ywrap,pmipal,mtrr
> Initializing CPU#0
> PID hash table entries: 4096 (order: 12, 32768 bytes)
> Extended CMOS year: 2000
> Fast TSC calibration using PIT
> Detected 2526.896 MHz processor.
> Console: colour VGA+ 80x25
> console [tty0] enabled
> Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
> Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
> Checking aperture...
> No AGP bridge found
> Memory: 3040120k/3102720k available (4161k kernel code, 4292k absent, 57580k reserved, 1977k data, 1428k init)
> SLUB: Genslabs=12, HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
> hpet clockevent registered
> HPET: 4 timers in total, 0 timers will be used for per-cpu timer
> Calibrating delay loop (skipped), value calculated using timer frequency.. 5055.36 BogoMIPS (lpj=8422986)
> Mount-cache hash table entries: 256
> CPU: L1 I cache: 32K, L1 D cache: 32K
> CPU: L2 cache: 6144K
> [ds] using Core 2/Atom configuration
> CPU: Physical Processor ID: 0
> CPU: Processor Core ID: 0
> CPU0: Thermal monitoring enabled (TM2)
> using mwait in idle threads.
> Freeing SMP alternatives: 37k freed
> ACPI: Core revision 20081204
> Setting APIC routing to flat
> ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
> CPU0: Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz stepping 06
> Booting processor 1 APIC 0x1 ip 0x6000
> Initializing CPU#1
> Calibrating delay using timer specific routine.. 5056.56 BogoMIPS (lpj=8423304)
> CPU: L1 I cache: 32K, L1 D cache: 32K
> CPU: L2 cache: 6144K
> [ds] using Core 2/Atom configuration
> CPU: Physical Processor ID: 0
> CPU: Processor Core ID: 1
> CPU1: Thermal monitoring enabled (TM2)
> x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106
> CPU1: Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz stepping 06
> checking TSC synchronization [CPU#0 -> CPU#1]: passed.
> Brought up 2 CPUs
> Total of 2 processors activated (10111.93 BogoMIPS).
> net_namespace: 960 bytes
> NET: Registered protocol family 16
> ACPI: bus type pci registered
> PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
> PCI: MCFG area at e0000000 reserved in E820
> PCI: Using MMCONFIG at e0000000 - efffffff
> PCI: Using configuration type 1 for base access
> mtrr: your CPUs had inconsistent variable MTRR settings
> mtrr: probably your BIOS does not setup all CPUs.
> mtrr: corrected configuration.
> bio: create slab <bio-0> at 0
> ACPI: EC: Look up EC in DSDT
> ACPI: SSDT BD56E965, 03F1 (r1 FUJ FJNB1E6 1160000 FUJ 100)
> ACPI: Interpreter enabled
> ACPI: (supports S0 S5)
> ACPI: Using IOAPIC for interrupt routing
> ACPI: EC: GPE = 0x17, I/O: command/status = 0x66, data = 0x62
> ACPI: EC: driver started in poll mode
> ACPI: ACPI Dock Station Driver: 2 docks/bays found
> ACPI: PCI Root Bridge [PCI0] (0000:00)
> pci 0000:00:02.0: reg 10 64bit mmio: [0xf0000000-0xf03fffff]
> pci 0000:00:02.0: reg 18 64bit mmio: [0xd0000000-0xdfffffff]
> pci 0000:00:02.0: reg 20 io port: [0x1800-0x1807]
> pci 0000:00:02.1: reg 10 64bit mmio: [0xf0400000-0xf04fffff]
> pci 0000:00:1a.0: reg 20 io port: [0x1820-0x183f]
> pci 0000:00:1a.1: reg 20 io port: [0x1840-0x185f]
> pci 0000:00:1a.2: reg 20 io port: [0x1860-0x187f]
> pci 0000:00:1a.7: reg 10 32bit mmio: [0xf0a04800-0xf0a04bff]
> pci 0000:00:1a.7: PME# supported from D0 D3hot D3cold
> pci 0000:00:1a.7: PME# disabled
> pci 0000:00:1b.0: reg 10 64bit mmio: [0xf0a00000-0xf0a03fff]
> 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.2: PME# supported from D0 D3hot D3cold
> pci 0000:00:1c.2: PME# disabled
> pci 0000:00:1d.0: reg 20 io port: [0x1880-0x189f]
> pci 0000:00:1d.1: reg 20 io port: [0x18a0-0x18bf]
> pci 0000:00:1d.2: reg 20 io port: [0x18c0-0x18df]
> pci 0000:00:1d.7: reg 10 32bit mmio: [0xf0a04c00-0xf0a04fff]
> pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold
> pci 0000:00:1d.7: PME# disabled
> pci 0000:00:1f.2: reg 10 io port: [0x1818-0x181f]
> pci 0000:00:1f.2: reg 14 io port: [0x180c-0x180f]
> pci 0000:00:1f.2: reg 18 io port: [0x1810-0x1817]
> pci 0000:00:1f.2: reg 1c io port: [0x1808-0x180b]
> pci 0000:00:1f.2: reg 20 io port: [0x18e0-0x18ff]
> pci 0000:00:1f.2: reg 24 32bit mmio: [0xf0a04000-0xf0a047ff]
> pci 0000:00:1f.2: PME# supported from D3hot
> pci 0000:00:1f.2: PME# disabled
> pci 0000:00:1f.3: reg 10 64bit mmio: [0x000000-0x0000ff]
> pci 0000:00:1f.3: reg 20 io port: [0x1c00-0x1c1f]
> pci 0000:08:00.0: reg 10 64bit mmio: [0xf0500000-0xf0503fff]
> pci 0000:08:00.0: reg 18 io port: [0x2000-0x20ff]
> pci 0000:08:00.0: reg 30 32bit mmio: [0x000000-0x01ffff]
> pci 0000:08:00.0: supports D1 D2
> pci 0000:08:00.0: PME# supported from D0 D1 D2 D3hot D3cold
> pci 0000:08:00.0: PME# disabled
> pci 0000:00:1c.0: bridge io port: [0x2000-0x2fff]
> pci 0000:00:1c.0: bridge 32bit mmio: [0xf0500000-0xf05fffff]
> pci 0000:18:00.0: reg 10 64bit mmio: [0xf0600000-0xf0601fff]
> pci 0000:18:00.0: PME# supported from D0 D3hot D3cold
> pci 0000:18:00.0: PME# disabled
> pci 0000:00:1c.2: bridge 32bit mmio: [0xf0600000-0xf06fffff]
> pci 0000:38:03.0: reg 10 32bit mmio: [0x000000-0x000fff]
> pci 0000:38:03.0: supports D1 D2
> pci 0000:38:03.0: PME# supported from D0 D1 D2 D3hot D3cold
> pci 0000:38:03.0: PME# disabled
> pci 0000:38:03.2: reg 10 32bit mmio: [0xf0700000-0xf07000ff]
> pci 0000:38:03.2: supports D1 D2
> pci 0000:38:03.2: PME# supported from D0 D1 D2 D3hot D3cold
> pci 0000:38:03.2: PME# disabled
> pci 0000:38:03.3: reg 10 32bit mmio: [0xf0701000-0xf0701fff]
> pci 0000:38:03.3: supports D1 D2
> pci 0000:38:03.3: PME# supported from D0 D1 D2 D3hot D3cold
> pci 0000:38:03.3: PME# disabled
> pci 0000:38:03.4: reg 10 32bit mmio: [0xf0702000-0xf0702fff]
> pci 0000:38:03.4: reg 14 32bit mmio: [0xf0700800-0xf0700fff]
> pci 0000:38:03.4: supports D1 D2
> pci 0000:38:03.4: PME# supported from D0 D1 D2 D3hot
> pci 0000:38:03.4: PME# disabled
> pci 0000:00:1e.0: transparent bridge
> pci 0000:00:1e.0: bridge 32bit mmio: [0xf0700000-0xf07fffff]
> pci_bus 0000:00: on NUMA node 0
> ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
> ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP01._PRT]
> ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP03._PRT]
> ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIB._PRT]
> ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 10 12 14 15) *11
> ACPI: PCI Interrupt Link [LNKB] (IRQs 1 3 4 5 6 7 *11 12 14 15)
> ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 5 6 7 10 12 14 15) *11
> ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 5 6 7 *11 12 14 15)
> ACPI: PCI Interrupt Link [LNKE] (IRQs 1 3 4 5 6 7 10 12 14 15) *0, disabled.
> ACPI: PCI Interrupt Link [LNKF] (IRQs 1 3 4 5 6 7 11 12 14 15) *0, disabled.
> ACPI: PCI Interrupt Link [LNKG] (IRQs 1 3 4 5 6 7 10 12 14 15) *11
> ACPI: PCI Interrupt Link [LNKH] (IRQs 1 3 4 5 6 7 *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
> Bluetooth: Core ver 2.14
> NET: Registered protocol family 31
> Bluetooth: HCI device and connection manager initialized
> Bluetooth: HCI socket layer initialized
> cfg80211: Calling CRDA to update world regulatory domain
> cfg80211: calling CRDA failed - unable to update world regulatory domain, using static definition
OK please use the new patch series I am about to post to test why this is
happening. And I am perplexed as to why you have 5 GHz disabled because
wiphy->custom_regulatory is enabled for intel the iwlagn driver and upon
wiphy registration we have a check to see if this is set and if the last
regulatory hint came from the core, if this is true we don't update the
wiphy's channels based on the regulatory domain:
if (!last_request)
return true;
if (setby == REGDOM_SET_BY_CORE &&
wiphy->custom_regulatory)
return true
Please run with my latest patch series or wait until it gets merged,
we'll be able to do a trace of your udev even failing to call CRDA
and the core initialization will be much easier to read.
Luis
Do correct me if I'm missing something here, but:
cfg80211: Leaving channel 5180 MHz intact on phy0 - no rule found in
band on Country IE
How will leaving the channel intact help, if the static world domain
turned it off in the first place? (Note that the CRDA request for the
world domain is emitted by the kernel before /dev/sda is even attached,
so needless to say that goes unserviced)
Regards,
Tony V.
Full dmesg of the faulty run with debugging attached for your reference.
Indeed, as John said this patch made it into mainline and is already
applied to my sources:
chainsaw@amalthea /cvs/linux-2.6 $ patch --dry-run -p1 -i ~/\[PATCH_5_6
\]_cfg80211\:_Fix_regression_with_11d_on_bands.diff
patching file net/wireless/reg.c
Reversed (or previously applied) patch detected! Assume -R? [n] ^C
Regards,
Tony V.
On Mon, Feb 16, 2009 at 07:47:33AM -0800, John W. Linville wrote:
> On Mon, Feb 16, 2009 at 12:08:44PM +0000, Tony Vroon wrote:
> > Just to confirm, if I use my early-boot hook that I used for your iw
> > list to set the regulatory domain manually (iw reg set GB) all is well.
> > If I allow the driver stack to get to the association stage without
> > setting a regulatory domain, I can never get my 802.11A spectrum back
> > after the fact.
> > Would you still see this as a bug or rather a specific requirement of
> > the new interface that hasn't yet been documented?
>
> Seems like a bug, or at least an unintended consequence of intersection...?
On Mon, Feb 9, 2009 at 10:09 AM, Tony Vroon <[email protected]> wrote:
> I'm using:
> [ebuild R ] net-wireless/wireless-regdb-20090130 0 kB
> [ebuild R ] net-wireless/crda-1.0.1-r1 0 kB
> [ebuild R ] net-wireless/iwl5000-ucode-5.4.0.11 0 kB
>
> The regulatory information for Great Britain looks as follows:
> country GB:
> (2402.000 - 2482.000 @ 40.000), (N/A, 20.00)
> (5170.000 - 5250.000 @ 40.000), (N/A, 20.00)
> (5250.000 - 5330.000 @ 40.000), (N/A, 20.00), DFS
> (5490.000 - 5710.000 @ 40.000), (N/A, 27.00), DFS
>
> iw reports the card configuration like such:
> Wiphy phy0
> Band 1:
> HT capabilities: 0x087e
> * 20/40 MHz operation
> * SM PS disabled
> * HT-greenfield
> * 20 MHz short GI
> * 40 MHz short GI
> * max A-MSDU len 7935
> HT A-MPDU factor: 0x0003 (65535 bytes)
> HT A-MPDU density: 0x0005 (4 usec)
> HT MCS set: ff ff ff 00 01 00 00 00 00 00 c2 01 01 00 00 00
> Frequencies:
> * 2412 MHz [1] (15.0 dBm)
> * 2417 MHz [2] (15.0 dBm)
> * 2422 MHz [3] (15.0 dBm)
> * 2427 MHz [4] (15.0 dBm)
> * 2432 MHz [5] (15.0 dBm)
> * 2437 MHz [6] (15.0 dBm)
> * 2442 MHz [7] (15.0 dBm)
> * 2447 MHz [8] (15.0 dBm)
> * 2452 MHz [9] (15.0 dBm)
> * 2457 MHz [10] (15.0 dBm)
> * 2462 MHz [11] (15.0 dBm)
> * 2467 MHz [12] (15.0 dBm) (passive scanning, no IBSS)
> * 2472 MHz [13] (15.0 dBm) (passive scanning, no IBSS)
> Bitrates:
> * 1.0 Mbps
> * 2.0 Mbps (short preamble supported)
> * 5.5 Mbps (short preamble supported)
> * 11.0 Mbps (short preamble supported)
> * 6.0 Mbps
> * 9.0 Mbps
> * 12.0 Mbps
> * 18.0 Mbps
> * 24.0 Mbps
> * 36.0 Mbps
> * 48.0 Mbps
> * 54.0 Mbps
> * 60.0 Mbps
> Band 2:
> HT capabilities: 0x087e
> * 20/40 MHz operation
> * SM PS disabled
> * HT-greenfield
> * 20 MHz short GI
> * 40 MHz short GI
> * max A-MSDU len 7935
> HT A-MPDU factor: 0x0003 (65535 bytes)
> HT A-MPDU density: 0x0005 (4 usec)
> HT MCS set: ff ff ff 00 01 00 00 00 00 00 c2 01 01 00 00 00
> Frequencies:
> * 5180 MHz [36] (disabled)
> * 5200 MHz [40] (disabled)
> * 5220 MHz [44] (disabled)
> * 5240 MHz [48] (disabled)
> * 5260 MHz [52] (disabled)
> * 5280 MHz [56] (disabled)
> * 5300 MHz [60] (disabled)
> * 5320 MHz [64] (disabled)
> * 5500 MHz [100] (disabled)
> * 5520 MHz [104] (disabled)
> * 5540 MHz [108] (disabled)
> * 5560 MHz [112] (disabled)
> * 5580 MHz [116] (disabled)
> * 5600 MHz [120] (disabled)
> * 5620 MHz [124] (disabled)
> * 5640 MHz [128] (disabled)
> * 5660 MHz [132] (disabled)
> * 5680 MHz [136] (disabled)
> * 5700 MHz [140] (disabled)
> * 5745 MHz [149] (disabled)
> * 5765 MHz [153] (disabled)
> * 5785 MHz [157] (disabled)
> * 5805 MHz [161] (disabled)
> * 5825 MHz [165] (disabled)
> Bitrates:
> * 6.0 Mbps
> * 9.0 Mbps
> * 12.0 Mbps
> * 18.0 Mbps
> * 24.0 Mbps
> * 36.0 Mbps
> * 48.0 Mbps
> * 54.0 Mbps
> * 60.0 Mbps
> Supported interface modes:
> * IBSS
> * Station
> * Monitor
>
> My Cisco AIR-AP1131AG-E-K9_v04 access point with C1130 Software
> (C1130-K9W7-M), Version 12.4(10b)JA, RELEASE has Dot11Radio0 &
> Dot11Radio1 configured like so:
> world-mode dot11d country GB indoor
>
> The kernel seems to do something else:
> cfg80211: Calling CRDA for country: GB
> cfg80211: Current regulatory domain updated by AP to: GB
> (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
> (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
>
> Any idea how that could happen please?
Your AP did not provide 5 GHz frequencies in its country information
element. Because of this the intersection between what CRDA has for GB
and what your AP provides does not include any channels in 5 GHz. This
has been fixed in wireless-testing though, if your AP country IE does
not have information for a separate band we lave that band to trust
CRDA information instead.
This should have been propagated down to 29 already, maybe it'll be in rc5?
Luis
On Mon, Feb 09, 2009 at 06:23:31PM +0000, Tony Vroon wrote:
> On Mon, 2009-02-09 at 10:20 -0800, Luis R. Rodriguez wrote:
> > Your AP did not provide 5 GHz frequencies in its country information
> > element. Because of this the intersection between what CRDA has for GB
> > and what your AP provides does not include any channels in 5 GHz. This
> > has been fixed in wireless-testing though, if your AP country IE does
> > not have information for a separate band we lave that band to trust
> > CRDA information instead.
> >
> > This should have been propagated down to 29 already, maybe it'll be in
> > rc5?
>
> John, will this make it into 2.6.29 final please?
It is in 2.6.29-rc3 AFAICT.
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On Tue, Feb 17, 2009 at 11:06:46AM -0800, Luis Rodriguez wrote:
> On Tue, Feb 17, 2009 at 10:42:30AM -0800, Luis Rodriguez wrote:
> > On Mon, Feb 16, 2009 at 07:47:33AM -0800, John W. Linville wrote:
> > > On Mon, Feb 16, 2009 at 12:08:44PM +0000, Tony Vroon wrote:
> > > > Just to confirm, if I use my early-boot hook that I used for your iw
> > > > list to set the regulatory domain manually (iw reg set GB) all is well.
> > > > If I allow the driver stack to get to the association stage without
> > > > setting a regulatory domain, I can never get my 802.11A spectrum back
> > > > after the fact.
> > > > Would you still see this as a bug or rather a specific requirement of
> > > > the new interface that hasn't yet been documented?
> > >
> > > Seems like a bug, or at least an unintended consequence of intersection...?
>
> Sorry for the blank e-mail.
>
> You are reporting you are disabling OLD_REG and your 5 GHz on iwlagn is disabled
> upon bootup. You also reported from your log:
>
> cfg80211: Calling CRDA to update world regulatory domain
> cfg80211: calling CRDA failed - unable to update world regulatory domain, using static definition
>
> This indicates to me your regulatory domain was simply never updated by CRDA. So what
> would have happened is that iwlagn registers its device to mac80211 via ieee80211_register_hw()
> then mac80211 registers it with cfg80211 via wiphy_register(). Upon that call cfg80211 will update
> the device's regulatory ifnromation by calling
>
> wiphy_update_regulatory(wiphy, REGDOM_SET_BY_CORE);
>
> This in turn will check to see if it should ignore the request, and in your case
> the check is:
>
> if (!last_request)
> return true;
> if (setby == REGDOM_SET_BY_CORE &&
> wiphy->custom_regulatory)
> return true
>
> Since iwlagn sets wiphy->custom_regulatory to true and since upon registration setby is
> REGDOM_SET_BY_CORE the device will be ignored to change the regulatory domain. I see I
> currently see no reason why your 5 GHz channels will be disabled unless I'm missing
> something or the card's EEPROM disables them.
>
> To debug this further we need more information. So please provide the output of both
> the kernel *and*, 'iw list' _prior_ to associating to your AP. Before you do so please
> recompile wireless-testing with these options enabled:
>
> # Intel debug
> CONFIG_IWL_DEBUG_INFO=y
>
> # Cfg80211 regulatory debug
> CONFIG_CFG80211_REG_DEBUG=y
>
> So to re-iterate: I want both your kernel log _and_ 'iw list' output prior to association.
To help isolate that orthogonal issue about having the udev rule not being
created you can also test the new patch series I just posted and enable REG_DEBUG,
this will give us a trace and hopefully we can see if call_usermodehelper() was
the one that failed during early boot.
http://marc.info/?l=linux-wireless&m=123510990625914&w=2
Luis
On Mon, Feb 09, 2009 at 11:35:52AM -0800, Tony Vroon wrote:
> Do correct me if I'm missing something here, but:
> cfg80211: Leaving channel 5180 MHz intact on phy0 - no rule found in
> band on Country IE
Looks good.
> How will leaving the channel intact help, if the static world domain
> turned it off in the first place?
In Intel's case the first regulatory domain is ignored (world). To see,
before associating to an AP try running 'iw list'.
> (Note that the CRDA request for the
> world domain is emitted by the kernel before /dev/sda is even attached,
> so needless to say that goes unserviced)
I noticed that, what ends up happening then is the static world regulatory
domain is used from the kernel. I take it you used an initramfs with the
sda driver in there? I've been using initramfs too but for some reason
on my system udev triggers the request eventually after the drive
is mounted. So this is the first time I hear of this.
I also noticed though:
cfg80211: Calling CRDA for country: GB
cfg80211: Current regulatory intersected:
(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
(2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
This seems to indicate to me you manually ran:
sudo iw reg set GB
Is that the case? If so then that would explain your 5 GHz channels
going missing. Technically we should not allow this though as the country
IE already had GB, I can send a patch for that but you could also not set
one up with iw manually and see the output if 'iw list'. Reason they would
have gone missing is that cfg80211 already has the intersected regulatory
domain present and if you issue a a user that you the country you are in
we will perform an intersection with what we have already and that of
the country you specificy and in that case the intersection yields no 5 GHz
channels. The band exception only occurs on country IEs. But regardless
trying to set the reg domain to manually if the country IE already had that
should result in a no-op. Will have to fix that.
Luis
On Mon, 2009-02-09 at 10:20 -0800, Luis R. Rodriguez wrote:
> Your AP did not provide 5 GHz frequencies in its country information
> element. Because of this the intersection between what CRDA has for GB
> and what your AP provides does not include any channels in 5 GHz. This
> has been fixed in wireless-testing though, if your AP country IE does
> not have information for a separate band we lave that band to trust
> CRDA information instead.
>
> This should have been propagated down to 29 already, maybe it'll be in
> rc5?
John, will this make it into 2.6.29 final please?
>
Regards,
Tony V.
Clear run, haven't touched iw, still no 802.11A spectrum. dmesg
attached. Any suggestion for a workaround that will get me my networks
back please? (Besides enabling the old regulatory options, which is
scheduled to be taken away from me soon)
Regards,
Tony V.
On Fri, Feb 13, 2009 at 08:52:32PM -0800, Luis Rodriguez wrote:
> On Wed, Feb 11, 2009 at 11:19:41AM -0800, Tony Vroon wrote:
> > Clear run, haven't touched iw, still no 802.11A spectrum. dmesg
> > attached. Any suggestion for a workaround that will get me my networks
> > back please? (Besides enabling the old regulatory options, which is
> > scheduled to be taken away from me soon)
> >
> > Regards,
> > Tony V.
>
> > Linux version 2.6.29-rc4-00026-gf06da26 (root@amalthea) (gcc version 4.3.3 (Gentoo 4.3.3 p1.0, pie-10.1.5) ) #1 SMP Mon Feb 9 18:55:10 GMT 2009
> > Command line: auto BOOT_IMAGE=2.6.29-rc4-0002 rw root=0 video=vesafb:ywrap,pmipal,mtrr
> > KERNEL supported cpus:
> > Intel GenuineIntel
> > AMD AuthenticAMD
> > Centaur CentaurHauls
> > BIOS-provided physical RAM map:
> > BIOS-e820: 0000000000000000 - 000000000009d400 (usable)
> > BIOS-e820: 000000000009d400 - 00000000000a0000 (reserved)
> > BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
> > BIOS-e820: 0000000000100000 - 00000000bce51000 (usable)
> > BIOS-e820: 00000000bce51000 - 00000000bce57000 (reserved)
> > BIOS-e820: 00000000bce57000 - 00000000bd058000 (usable)
> > BIOS-e820: 00000000bd058000 - 00000000bd0af000 (reserved)
> > BIOS-e820: 00000000bd0af000 - 00000000bd1a8000 (usable)
> > BIOS-e820: 00000000bd1a8000 - 00000000bd4af000 (reserved)
> > BIOS-e820: 00000000bd4af000 - 00000000bd4d8000 (usable)
> > BIOS-e820: 00000000bd4d8000 - 00000000bd4df000 (reserved)
> > BIOS-e820: 00000000bd4df000 - 00000000bd535000 (usable)
> > BIOS-e820: 00000000bd535000 - 00000000bd57f000 (ACPI NVS)
> > BIOS-e820: 00000000bd57f000 - 00000000bd5e4000 (usable)
> > BIOS-e820: 00000000bd5e4000 - 00000000bd5fd000 (ACPI data)
> > BIOS-e820: 00000000bd5fd000 - 00000000bd600000 (usable)
> > BIOS-e820: 00000000bd600000 - 00000000c0000000 (reserved)
> > BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
> > BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
> > BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved)
> > BIOS-e820: 00000000fed10000 - 00000000fed14000 (reserved)
> > BIOS-e820: 00000000fed18000 - 00000000fed1a000 (reserved)
> > BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved)
> > BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
> > BIOS-e820: 00000000ff800000 - 0000000100000000 (reserved)
> > DMI 2.4 present.
> > last_pfn = 0xbd600 max_arch_pfn = 0x100000000
> > x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
> > init_memory_mapping: 0000000000000000-00000000bd600000
> > 0000000000 - 00bd600000 page 2M
> > kernel direct mapping tables up to bd600000 @ 8000-c000
> > last_map_addr: bd600000 end: bd600000
> > ACPI: RSDP 000F53D0, 0024 (r2 FUJ )
> > ACPI: XSDT BD5F3434, 0074 (r1 FSC PC 1160000 FUJ 100)
> > ACPI: FACP BD5E6000, 00F4 (r3 FSC PC 1160000 FUJ 100)
> > FADT: X_PM1a_EVT_BLK.bit_width (16) does not match PM1_EVT_LEN (4)
> > ACPI: DSDT BD5E7000, 8CFF (r1 FUJ FJNB1E6 1160000 FUJ 100)
> > ACPI: FACS BD56EFC0, 0040
> > ACPI: SSDT BD5FC1DF, 034F (r1 FUJ FJNB1E6 1160000 FUJ 100)
> > ACPI: HPET BD5FC622, 0038 (r1 FUJ FJNB1E6 1160000 FUJ 100)
> > ACPI: MCFG BD5FC65A, 003C (r1 FUJ FJNB1E6 1160000 FUJ 100)
> > ACPI: SSDT BD5FC696, 042F (r1 FUJ FJNB1E6 1160000 FUJ 100)
> > ACPI: SSDT BD5FCAC5, 02C1 (r1 FUJ FJNB1E6 1160000 FUJ 100)
> > ACPI: APIC BD5FCD86, 0068 (r1 FUJ FJNB1E6 1160000 FUJ 100)
> > ACPI: BOOT BD5FCDEE, 0028 (r1 FUJ FJNB1E6 1160000 FUJ 100)
> > ACPI: SLIC BD5FCE16, 0176 (r1 FSC PC 1160000 FUJ 100)
> > ACPI: SSDT BD5E5000, 04E6 (r1 PmRef CpuPm 3000 INTL 20050624)
> > ACPI: Local APIC address 0xfee00000
> > (5 early reservations) ==> bootmem [0000000000 - 00bd600000]
> > #0 [0000000000 - 0000001000] BIOS data page ==> [0000000000 - 0000001000]
> > #1 [0000006000 - 0000008000] TRAMPOLINE ==> [0000006000 - 0000008000]
> > #2 [0000200000 - 00009f3dec] TEXT DATA BSS ==> [0000200000 - 00009f3dec]
> > #3 [000009d400 - 0000100000] BIOS reserved ==> [000009d400 - 0000100000]
> > #4 [0000008000 - 000000a000] PGTABLE ==> [0000008000 - 000000a000]
> > [ffffe20000000000-ffffe200029fffff] PMD -> [ffff880001200000-ffff880003bfffff] on node 0
> > Zone PFN ranges:
> > DMA 0x00000000 -> 0x00001000
> > DMA32 0x00001000 -> 0x00100000
> > Normal 0x00100000 -> 0x00100000
> > Movable zone start PFN for each node
> > early_node_map[8] active PFN ranges
> > 0: 0x00000000 -> 0x0000009d
> > 0: 0x00000100 -> 0x000bce51
> > 0: 0x000bce57 -> 0x000bd058
> > 0: 0x000bd0af -> 0x000bd1a8
> > 0: 0x000bd4af -> 0x000bd4d8
> > 0: 0x000bd4df -> 0x000bd535
> > 0: 0x000bd57f -> 0x000bd5e4
> > 0: 0x000bd5fd -> 0x000bd600
> > On node 0 totalpages: 774607
> > DMA zone: 56 pages used for memmap
> > DMA zone: 2138 pages reserved
> > DMA zone: 1803 pages, LIFO batch:0
> > DMA32 zone: 10549 pages used for memmap
> > DMA32 zone: 760061 pages, LIFO batch:31
> > ACPI: PM-Timer IO Port: 0x408
> > ACPI: Local APIC address 0xfee00000
> > ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
> > ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
> > ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
> > ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
> > ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
> > IOAPIC[0]: apic_id 2, version 0, address 0xfec00000, GSI 0-23
> > ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
> > 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.
> > Using ACPI (MADT) for SMP configuration information
> > ACPI: HPET id: 0x8086a201 base: 0xfed00000
> > SMP: Allowing 2 CPUs, 0 hotplug CPUs
> > Allocating PCI resources starting at c2000000 (gap: c0000000:20000000)
> > NR_CPUS:2 nr_cpumask_bits:2 nr_cpu_ids:2 nr_node_ids:1
> > PERCPU: Allocating 49152 bytes of per cpu data
> > Built 1 zonelists in Zone order, mobility grouping on. Total pages: 761864
> > Kernel command line: auto BOOT_IMAGE=2.6.29-rc4-0002 rw root=0 video=vesafb:ywrap,pmipal,mtrr
> > Initializing CPU#0
> > PID hash table entries: 4096 (order: 12, 32768 bytes)
> > Extended CMOS year: 2000
> > Fast TSC calibration using PIT
> > Detected 2526.896 MHz processor.
> > Console: colour VGA+ 80x25
> > console [tty0] enabled
> > Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
> > Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
> > Checking aperture...
> > No AGP bridge found
> > Memory: 3040120k/3102720k available (4161k kernel code, 4292k absent, 57580k reserved, 1977k data, 1428k init)
> > SLUB: Genslabs=12, HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
> > hpet clockevent registered
> > HPET: 4 timers in total, 0 timers will be used for per-cpu timer
> > Calibrating delay loop (skipped), value calculated using timer frequency.. 5055.36 BogoMIPS (lpj=8422986)
> > Mount-cache hash table entries: 256
> > CPU: L1 I cache: 32K, L1 D cache: 32K
> > CPU: L2 cache: 6144K
> > [ds] using Core 2/Atom configuration
> > CPU: Physical Processor ID: 0
> > CPU: Processor Core ID: 0
> > CPU0: Thermal monitoring enabled (TM2)
> > using mwait in idle threads.
> > Freeing SMP alternatives: 37k freed
> > ACPI: Core revision 20081204
> > Setting APIC routing to flat
> > ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
> > CPU0: Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz stepping 06
> > Booting processor 1 APIC 0x1 ip 0x6000
> > Initializing CPU#1
> > Calibrating delay using timer specific routine.. 5056.56 BogoMIPS (lpj=8423304)
> > CPU: L1 I cache: 32K, L1 D cache: 32K
> > CPU: L2 cache: 6144K
> > [ds] using Core 2/Atom configuration
> > CPU: Physical Processor ID: 0
> > CPU: Processor Core ID: 1
> > CPU1: Thermal monitoring enabled (TM2)
> > x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106
> > CPU1: Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz stepping 06
> > checking TSC synchronization [CPU#0 -> CPU#1]: passed.
> > Brought up 2 CPUs
> > Total of 2 processors activated (10111.93 BogoMIPS).
> > net_namespace: 960 bytes
> > NET: Registered protocol family 16
> > ACPI: bus type pci registered
> > PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
> > PCI: MCFG area at e0000000 reserved in E820
> > PCI: Using MMCONFIG at e0000000 - efffffff
> > PCI: Using configuration type 1 for base access
> > mtrr: your CPUs had inconsistent variable MTRR settings
> > mtrr: probably your BIOS does not setup all CPUs.
> > mtrr: corrected configuration.
> > bio: create slab <bio-0> at 0
> > ACPI: EC: Look up EC in DSDT
> > ACPI: SSDT BD56E965, 03F1 (r1 FUJ FJNB1E6 1160000 FUJ 100)
> > ACPI: Interpreter enabled
> > ACPI: (supports S0 S5)
> > ACPI: Using IOAPIC for interrupt routing
> > ACPI: EC: GPE = 0x17, I/O: command/status = 0x66, data = 0x62
> > ACPI: EC: driver started in poll mode
> > ACPI: ACPI Dock Station Driver: 2 docks/bays found
> > ACPI: PCI Root Bridge [PCI0] (0000:00)
> > pci 0000:00:02.0: reg 10 64bit mmio: [0xf0000000-0xf03fffff]
> > pci 0000:00:02.0: reg 18 64bit mmio: [0xd0000000-0xdfffffff]
> > pci 0000:00:02.0: reg 20 io port: [0x1800-0x1807]
> > pci 0000:00:02.1: reg 10 64bit mmio: [0xf0400000-0xf04fffff]
> > pci 0000:00:1a.0: reg 20 io port: [0x1820-0x183f]
> > pci 0000:00:1a.1: reg 20 io port: [0x1840-0x185f]
> > pci 0000:00:1a.2: reg 20 io port: [0x1860-0x187f]
> > pci 0000:00:1a.7: reg 10 32bit mmio: [0xf0a04800-0xf0a04bff]
> > pci 0000:00:1a.7: PME# supported from D0 D3hot D3cold
> > pci 0000:00:1a.7: PME# disabled
> > pci 0000:00:1b.0: reg 10 64bit mmio: [0xf0a00000-0xf0a03fff]
> > 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.2: PME# supported from D0 D3hot D3cold
> > pci 0000:00:1c.2: PME# disabled
> > pci 0000:00:1d.0: reg 20 io port: [0x1880-0x189f]
> > pci 0000:00:1d.1: reg 20 io port: [0x18a0-0x18bf]
> > pci 0000:00:1d.2: reg 20 io port: [0x18c0-0x18df]
> > pci 0000:00:1d.7: reg 10 32bit mmio: [0xf0a04c00-0xf0a04fff]
> > pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold
> > pci 0000:00:1d.7: PME# disabled
> > pci 0000:00:1f.2: reg 10 io port: [0x1818-0x181f]
> > pci 0000:00:1f.2: reg 14 io port: [0x180c-0x180f]
> > pci 0000:00:1f.2: reg 18 io port: [0x1810-0x1817]
> > pci 0000:00:1f.2: reg 1c io port: [0x1808-0x180b]
> > pci 0000:00:1f.2: reg 20 io port: [0x18e0-0x18ff]
> > pci 0000:00:1f.2: reg 24 32bit mmio: [0xf0a04000-0xf0a047ff]
> > pci 0000:00:1f.2: PME# supported from D3hot
> > pci 0000:00:1f.2: PME# disabled
> > pci 0000:00:1f.3: reg 10 64bit mmio: [0x000000-0x0000ff]
> > pci 0000:00:1f.3: reg 20 io port: [0x1c00-0x1c1f]
> > pci 0000:08:00.0: reg 10 64bit mmio: [0xf0500000-0xf0503fff]
> > pci 0000:08:00.0: reg 18 io port: [0x2000-0x20ff]
> > pci 0000:08:00.0: reg 30 32bit mmio: [0x000000-0x01ffff]
> > pci 0000:08:00.0: supports D1 D2
> > pci 0000:08:00.0: PME# supported from D0 D1 D2 D3hot D3cold
> > pci 0000:08:00.0: PME# disabled
> > pci 0000:00:1c.0: bridge io port: [0x2000-0x2fff]
> > pci 0000:00:1c.0: bridge 32bit mmio: [0xf0500000-0xf05fffff]
> > pci 0000:18:00.0: reg 10 64bit mmio: [0xf0600000-0xf0601fff]
> > pci 0000:18:00.0: PME# supported from D0 D3hot D3cold
> > pci 0000:18:00.0: PME# disabled
> > pci 0000:00:1c.2: bridge 32bit mmio: [0xf0600000-0xf06fffff]
> > pci 0000:38:03.0: reg 10 32bit mmio: [0x000000-0x000fff]
> > pci 0000:38:03.0: supports D1 D2
> > pci 0000:38:03.0: PME# supported from D0 D1 D2 D3hot D3cold
> > pci 0000:38:03.0: PME# disabled
> > pci 0000:38:03.2: reg 10 32bit mmio: [0xf0700000-0xf07000ff]
> > pci 0000:38:03.2: supports D1 D2
> > pci 0000:38:03.2: PME# supported from D0 D1 D2 D3hot D3cold
> > pci 0000:38:03.2: PME# disabled
> > pci 0000:38:03.3: reg 10 32bit mmio: [0xf0701000-0xf0701fff]
> > pci 0000:38:03.3: supports D1 D2
> > pci 0000:38:03.3: PME# supported from D0 D1 D2 D3hot D3cold
> > pci 0000:38:03.3: PME# disabled
> > pci 0000:38:03.4: reg 10 32bit mmio: [0xf0702000-0xf0702fff]
> > pci 0000:38:03.4: reg 14 32bit mmio: [0xf0700800-0xf0700fff]
> > pci 0000:38:03.4: supports D1 D2
> > pci 0000:38:03.4: PME# supported from D0 D1 D2 D3hot
> > pci 0000:38:03.4: PME# disabled
> > pci 0000:00:1e.0: transparent bridge
> > pci 0000:00:1e.0: bridge 32bit mmio: [0xf0700000-0xf07fffff]
> > pci_bus 0000:00: on NUMA node 0
> > ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
> > ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP01._PRT]
> > ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP03._PRT]
> > ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIB._PRT]
> > ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 10 12 14 15) *11
> > ACPI: PCI Interrupt Link [LNKB] (IRQs 1 3 4 5 6 7 *11 12 14 15)
> > ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 5 6 7 10 12 14 15) *11
> > ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 5 6 7 *11 12 14 15)
> > ACPI: PCI Interrupt Link [LNKE] (IRQs 1 3 4 5 6 7 10 12 14 15) *0, disabled.
> > ACPI: PCI Interrupt Link [LNKF] (IRQs 1 3 4 5 6 7 11 12 14 15) *0, disabled.
> > ACPI: PCI Interrupt Link [LNKG] (IRQs 1 3 4 5 6 7 10 12 14 15) *11
> > ACPI: PCI Interrupt Link [LNKH] (IRQs 1 3 4 5 6 7 *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
> > Bluetooth: Core ver 2.14
> > NET: Registered protocol family 31
> > Bluetooth: HCI device and connection manager initialized
> > Bluetooth: HCI socket layer initialized
> > cfg80211: Calling CRDA to update world regulatory domain
> > cfg80211: calling CRDA failed - unable to update world regulatory domain, using static definition
>
> OK please use the new patch series I am about to post to test why this is
> happening. And I am perplexed as to why you have 5 GHz disabled because
> wiphy->custom_regulatory is enabled for intel the iwlagn driver and upon
> wiphy registration we have a check to see if this is set and if the last
> regulatory hint came from the core, if this is true we don't update the
> wiphy's channels based on the regulatory domain:
>
> if (!last_request)
> return true;
> if (setby == REGDOM_SET_BY_CORE &&
> wiphy->custom_regulatory)
> return true
>
> Please run with my latest patch series or wait until it gets merged,
> we'll be able to do a trace of your udev even failing to call CRDA
> and the core initialization will be much easier to read.
Actually, upon further investigation it may just be that the iwlagn driver
is simply respecting your EEPROM settings. Enable IWL_DEBUG_INFO and recompile
and spit the log out here.
Luis
On Tue, Feb 17, 2009 at 10:42:30AM -0800, Luis Rodriguez wrote:
> On Mon, Feb 16, 2009 at 07:47:33AM -0800, John W. Linville wrote:
> > On Mon, Feb 16, 2009 at 12:08:44PM +0000, Tony Vroon wrote:
> > > Just to confirm, if I use my early-boot hook that I used for your iw
> > > list to set the regulatory domain manually (iw reg set GB) all is well.
> > > If I allow the driver stack to get to the association stage without
> > > setting a regulatory domain, I can never get my 802.11A spectrum back
> > > after the fact.
> > > Would you still see this as a bug or rather a specific requirement of
> > > the new interface that hasn't yet been documented?
> >
> > Seems like a bug, or at least an unintended consequence of intersection...?
Sorry for the blank e-mail.
You are reporting you are disabling OLD_REG and your 5 GHz on iwlagn is disabled
upon bootup. You also reported from your log:
cfg80211: Calling CRDA to update world regulatory domain
cfg80211: calling CRDA failed - unable to update world regulatory domain, using static definition
This indicates to me your regulatory domain was simply never updated by CRDA. So what
would have happened is that iwlagn registers its device to mac80211 via ieee80211_register_hw()
then mac80211 registers it with cfg80211 via wiphy_register(). Upon that call cfg80211 will update
the device's regulatory ifnromation by calling
wiphy_update_regulatory(wiphy, REGDOM_SET_BY_CORE);
This in turn will check to see if it should ignore the request, and in your case
the check is:
if (!last_request)
return true;
if (setby == REGDOM_SET_BY_CORE &&
wiphy->custom_regulatory)
return true
Since iwlagn sets wiphy->custom_regulatory to true and since upon registration setby is
REGDOM_SET_BY_CORE the device will be ignored to change the regulatory domain. I see I
currently see no reason why your 5 GHz channels will be disabled unless I'm missing
something or the card's EEPROM disables them.
To debug this further we need more information. So please provide the output of both
the kernel *and*, 'iw list' _prior_ to associating to your AP. Before you do so please
recompile wireless-testing with these options enabled:
# Intel debug
CONFIG_IWL_DEBUG_INFO=y
# Cfg80211 regulatory debug
CONFIG_CFG80211_REG_DEBUG=y
So to re-iterate: I want both your kernel log _and_ 'iw list' output prior to association.
Luis
On Mon, Feb 9, 2009 at 10:20 AM, Luis R. Rodriguez
<[email protected]> wrote:
> On Mon, Feb 9, 2009 at 10:09 AM, Tony Vroon <[email protected]> wrote:
>> I'm using:
>> [ebuild R ] net-wireless/wireless-regdb-20090130 0 kB
>> [ebuild R ] net-wireless/crda-1.0.1-r1 0 kB
>> [ebuild R ] net-wireless/iwl5000-ucode-5.4.0.11 0 kB
>>
>> The regulatory information for Great Britain looks as follows:
>> country GB:
>> (2402.000 - 2482.000 @ 40.000), (N/A, 20.00)
>> (5170.000 - 5250.000 @ 40.000), (N/A, 20.00)
>> (5250.000 - 5330.000 @ 40.000), (N/A, 20.00), DFS
>> (5490.000 - 5710.000 @ 40.000), (N/A, 27.00), DFS
>>
>> iw reports the card configuration like such:
>> Wiphy phy0
>> Band 1:
>> HT capabilities: 0x087e
>> * 20/40 MHz operation
>> * SM PS disabled
>> * HT-greenfield
>> * 20 MHz short GI
>> * 40 MHz short GI
>> * max A-MSDU len 7935
>> HT A-MPDU factor: 0x0003 (65535 bytes)
>> HT A-MPDU density: 0x0005 (4 usec)
>> HT MCS set: ff ff ff 00 01 00 00 00 00 00 c2 01 01 00 00 00
>> Frequencies:
>> * 2412 MHz [1] (15.0 dBm)
>> * 2417 MHz [2] (15.0 dBm)
>> * 2422 MHz [3] (15.0 dBm)
>> * 2427 MHz [4] (15.0 dBm)
>> * 2432 MHz [5] (15.0 dBm)
>> * 2437 MHz [6] (15.0 dBm)
>> * 2442 MHz [7] (15.0 dBm)
>> * 2447 MHz [8] (15.0 dBm)
>> * 2452 MHz [9] (15.0 dBm)
>> * 2457 MHz [10] (15.0 dBm)
>> * 2462 MHz [11] (15.0 dBm)
>> * 2467 MHz [12] (15.0 dBm) (passive scanning, no IBSS)
>> * 2472 MHz [13] (15.0 dBm) (passive scanning, no IBSS)
>> Bitrates:
>> * 1.0 Mbps
>> * 2.0 Mbps (short preamble supported)
>> * 5.5 Mbps (short preamble supported)
>> * 11.0 Mbps (short preamble supported)
>> * 6.0 Mbps
>> * 9.0 Mbps
>> * 12.0 Mbps
>> * 18.0 Mbps
>> * 24.0 Mbps
>> * 36.0 Mbps
>> * 48.0 Mbps
>> * 54.0 Mbps
>> * 60.0 Mbps
>> Band 2:
>> HT capabilities: 0x087e
>> * 20/40 MHz operation
>> * SM PS disabled
>> * HT-greenfield
>> * 20 MHz short GI
>> * 40 MHz short GI
>> * max A-MSDU len 7935
>> HT A-MPDU factor: 0x0003 (65535 bytes)
>> HT A-MPDU density: 0x0005 (4 usec)
>> HT MCS set: ff ff ff 00 01 00 00 00 00 00 c2 01 01 00 00 00
>> Frequencies:
>> * 5180 MHz [36] (disabled)
>> * 5200 MHz [40] (disabled)
>> * 5220 MHz [44] (disabled)
>> * 5240 MHz [48] (disabled)
>> * 5260 MHz [52] (disabled)
>> * 5280 MHz [56] (disabled)
>> * 5300 MHz [60] (disabled)
>> * 5320 MHz [64] (disabled)
>> * 5500 MHz [100] (disabled)
>> * 5520 MHz [104] (disabled)
>> * 5540 MHz [108] (disabled)
>> * 5560 MHz [112] (disabled)
>> * 5580 MHz [116] (disabled)
>> * 5600 MHz [120] (disabled)
>> * 5620 MHz [124] (disabled)
>> * 5640 MHz [128] (disabled)
>> * 5660 MHz [132] (disabled)
>> * 5680 MHz [136] (disabled)
>> * 5700 MHz [140] (disabled)
>> * 5745 MHz [149] (disabled)
>> * 5765 MHz [153] (disabled)
>> * 5785 MHz [157] (disabled)
>> * 5805 MHz [161] (disabled)
>> * 5825 MHz [165] (disabled)
>> Bitrates:
>> * 6.0 Mbps
>> * 9.0 Mbps
>> * 12.0 Mbps
>> * 18.0 Mbps
>> * 24.0 Mbps
>> * 36.0 Mbps
>> * 48.0 Mbps
>> * 54.0 Mbps
>> * 60.0 Mbps
>> Supported interface modes:
>> * IBSS
>> * Station
>> * Monitor
>>
>> My Cisco AIR-AP1131AG-E-K9_v04 access point with C1130 Software
>> (C1130-K9W7-M), Version 12.4(10b)JA, RELEASE has Dot11Radio0 &
>> Dot11Radio1 configured like so:
>> world-mode dot11d country GB indoor
>>
>> The kernel seems to do something else:
>> cfg80211: Calling CRDA for country: GB
>> cfg80211: Current regulatory domain updated by AP to: GB
>> (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
>> (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
>>
>> Any idea how that could happen please?
>
> Your AP did not provide 5 GHz frequencies in its country information
> element. Because of this the intersection between what CRDA has for GB
> and what your AP provides does not include any channels in 5 GHz. This
> has been fixed in wireless-testing though, if your AP country IE does
> not have information for a separate band we lave that band to trust
> CRDA information instead.
>
> This should have been propagated down to 29 already, maybe it'll be in rc5?
BTW this is the patch commit info:
commit 0c7dc45d21de6ae212b5ccb7cdff5beff795ccf0
Author: Luis R. Rodriguez <[email protected]>
Date: Wed Jan 7 17:43:36 2009 -0800
cfg80211: Fix regression with 11d on bands
This fixes a regression on disallowing bands introduced with the new
802.11d support. The issue is that IEEE-802.11 allows APs to send
a subset of what a country regulatory domain defines. This was clarified
in this document:
http://tinyurl.com/11d-clarification
As such it is possible, and this is what is done in practice, that a
single band 2.4 GHz AP will only send 2.4 GHz band regulatory information
through the 802.11 country information element and then the current
intersection with what CRDA provided yields a regulatory domain with
no 5 GHz information -- even though that country may actually allow
5 GHz operation. We correct this by only applying the intersection rules
on a channel if the the intersection yields a regulatory rule on the
same band the channel is on.
Signed-off-by: Luis R. Rodriguez <[email protected]>
Acked-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
On Wed, 2009-02-11 at 13:46 -0800, Luis R. Rodriguez wrote:
> Looks good here -- can you please provide 'iw list' output prior to
> trying to associate.
As expected, the "world domain". Details attached.
Leaving the 802.11A spectrum alone won't help if your defaults don't
enable it.
> Luis
Regards,
Tony V.
Just to confirm, if I use my early-boot hook that I used for your iw
list to set the regulatory domain manually (iw reg set GB) all is well.
If I allow the driver stack to get to the association stage without
setting a regulatory domain, I can never get my 802.11A spectrum back
after the fact.
Would you still see this as a bug or rather a specific requirement of
the new interface that hasn't yet been documented?
Regards,
Tony V.
On Mon, Feb 16, 2009 at 12:08:44PM +0000, Tony Vroon wrote:
> Just to confirm, if I use my early-boot hook that I used for your iw
> list to set the regulatory domain manually (iw reg set GB) all is well.
> If I allow the driver stack to get to the association stage without
> setting a regulatory domain, I can never get my 802.11A spectrum back
> after the fact.
> Would you still see this as a bug or rather a specific requirement of
> the new interface that hasn't yet been documented?
Seems like a bug, or at least an unintended consequence of intersection...?
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.