* Re: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work. [not found] <1507831110.20131018194349@eikelenboom.it> @ 2013-10-23 12:28 ` Sander Eikelenboom 2013-12-11 15:17 ` Sander Eikelenboom 0 siblings, 1 reply; 38+ messages in thread From: Sander Eikelenboom @ 2013-10-23 12:28 UTC (permalink / raw) To: Luis R. Rodriguez, Grumbach, Emmanuel Cc: linux-kernel, ilw@linux.intel.com, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, John W. Linville, Berg, Johannes [-- Attachment #1: Type: text/plain, Size: 961 bytes --] Ping ? Friday, October 18, 2013, 7:43:49 PM, you wrote: > Hi, > I'm trying to change the regulatory domain for my wireless adapter: > Intel Corporation Centrino Advanced-N 6235 > But it fails to change from "world" to anything else (say "US") > I enabled debug options used iwlwifi.debug=0x00043FFF for boot and added some printk's which i think should be triggered .. but they are not. > It seems in function "reg_process_pending_hints" the processing is deferred, > but from the code i don't see how it would ever be triggered to complete ? > Hope some can give some hints to what could be going on ... > Attached: > - full syslog from boot till "iw set reg US", which is done at "Oct 18 21:26:09" > - patch.diff with the added debug printk's against 3.12-rc5 (it also contains the patch that was needed to suppress another warning in the iwlwifi driver. > -- > Sander -- Best regards, Sander mailto:linux@eikelenboom.it [-- Attachment #2: patch.diff --] [-- Type: application/octet-stream, Size: 5512 bytes --] diff --git a/drivers/net/wireless/iwlwifi/dvm/tx.c b/drivers/net/wireless/iwlwifi/dvm/tx.c index da442b8..1fef524 100644 --- a/drivers/net/wireless/iwlwifi/dvm/tx.c +++ b/drivers/net/wireless/iwlwifi/dvm/tx.c @@ -433,27 +433,19 @@ int iwlagn_tx_skb(struct iwl_priv *priv, /* Copy MAC header from skb into command buffer */ memcpy(tx_cmd->hdr, hdr, hdr_len); + txq_id = info->hw_queue; + if (is_agg) txq_id = priv->tid_data[sta_id][tid].agg.txq_id; else if (info->flags & IEEE80211_TX_CTL_SEND_AFTER_DTIM) { /* - * Send this frame after DTIM -- there's a special queue - * reserved for this for contexts that support AP mode. - */ - txq_id = ctx->mcast_queue; - - /* * The microcode will clear the more data * bit in the last frame it transmits. */ hdr->frame_control |= cpu_to_le16(IEEE80211_FCTL_MOREDATA); - } else if (info->flags & IEEE80211_TX_CTL_TX_OFFCHAN) - txq_id = IWL_AUX_QUEUE; - else - txq_id = ctx->ac_to_queue[skb_get_queue_mapping(skb)]; + } - WARN_ON_ONCE(!is_agg && txq_id != info->hw_queue); WARN_ON_ONCE(is_agg && priv->queue_to_mac80211[txq_id] != info->hw_queue); diff --git a/drivers/net/wireless/iwlwifi/mvm/mac80211.c b/drivers/net/wireless/iwlwifi/mvm/mac80211.c index 9833cdf..e081c03 100644 --- a/drivers/net/wireless/iwlwifi/mvm/mac80211.c +++ b/drivers/net/wireless/iwlwifi/mvm/mac80211.c @@ -217,12 +217,16 @@ int iwl_mvm_mac_setup_register(struct iwl_mvm *mvm) mvm->fw->ucode_capa.max_probe_length - 24 - 34; hw->wiphy->max_scan_ssids = PROBE_OPTION_MAX; - if (mvm->nvm_data->bands[IEEE80211_BAND_2GHZ].n_channels) + if (mvm->nvm_data->bands[IEEE80211_BAND_2GHZ].n_channels){ hw->wiphy->bands[IEEE80211_BAND_2GHZ] = &mvm->nvm_data->bands[IEEE80211_BAND_2GHZ]; - if (mvm->nvm_data->bands[IEEE80211_BAND_5GHZ].n_channels) + IWL_ERR(mvm, "SEIK AP create the 802.11 header with 2.4\n"); + } + if (mvm->nvm_data->bands[IEEE80211_BAND_5GHZ].n_channels) { hw->wiphy->bands[IEEE80211_BAND_5GHZ] = &mvm->nvm_data->bands[IEEE80211_BAND_5GHZ]; + IWL_ERR(mvm, "SEIK AP create the 802.11 header with 5\n"); + } hw->wiphy->hw_version = mvm->trans->hw_id; diff --git a/net/wireless/reg.c b/net/wireless/reg.c index de06d5d..4d5dad7 100644 --- a/net/wireless/reg.c +++ b/net/wireless/reg.c @@ -58,6 +58,8 @@ #include "regdb.h" #include "nl80211.h" +#define CONFIG_CFG80211_REG_DEBUG + #ifdef CONFIG_CFG80211_REG_DEBUG #define REG_DBG_PRINT(format, args...) \ printk(KERN_DEBUG pr_fmt(format), ##args) @@ -758,6 +760,8 @@ const struct ieee80211_reg_rule *freq_reg_info(struct wiphy *wiphy, } EXPORT_SYMBOL(freq_reg_info); +#define CONFIG_CFG80211_REG_DEBUG + #ifdef CONFIG_CFG80211_REG_DEBUG static const char *reg_initiator_name(enum nl80211_reg_initiator initiator) { @@ -976,8 +980,8 @@ static bool ignore_reg_update(struct wiphy *wiphy, if (initiator == NL80211_REGDOM_SET_BY_CORE && wiphy->flags & WIPHY_FLAG_CUSTOM_REGULATORY) { - REG_DBG_PRINT("Ignoring regulatory request %s since the driver uses its own custom regulatory domain\n", - reg_initiator_name(initiator)); + REG_DBG_PRINT("Ignoring regulatory request %s since the driver uses its own custom regulatory domain %lx\n", + reg_initiator_name(initiator), wiphy->flags); return true; } @@ -993,8 +997,14 @@ static bool ignore_reg_update(struct wiphy *wiphy, return true; } - if (reg_request_cell_base(lr)) + if (reg_request_cell_base(lr)){ + REG_DBG_PRINT("Ignoring regulatory request ?? %s: %i\n", + reg_initiator_name(initiator), reg_dev_ignore_cell_hint(wiphy)); + return reg_dev_ignore_cell_hint(wiphy); + } + REG_DBG_PRINT("NOT Ignoring regulatory request %s \n", + reg_initiator_name(initiator)); return false; } @@ -1516,6 +1526,7 @@ static void reg_process_hint(struct regulatory_request *reg_request, enum nl80211_reg_initiator reg_initiator) { struct wiphy *wiphy = NULL; + REG_DBG_PRINT("SEIK reg_process_hint begin\n"); if (WARN_ON(!reg_request->alpha2)) return; @@ -1531,14 +1542,19 @@ static void reg_process_hint(struct regulatory_request *reg_request, switch (__regulatory_hint(wiphy, reg_request)) { case REG_REQ_ALREADY_SET: /* This is required so that the orig_* parameters are saved */ - if (wiphy && wiphy->flags & WIPHY_FLAG_STRICT_REGULATORY) + if (wiphy && wiphy->flags & WIPHY_FLAG_STRICT_REGULATORY){ wiphy_update_regulatory(wiphy, reg_initiator); + REG_DBG_PRINT("SEIK reg_process_hint already set\n"); + } break; default: - if (reg_initiator == NL80211_REGDOM_SET_BY_USER) + if (reg_initiator == NL80211_REGDOM_SET_BY_USER){ schedule_delayed_work(®_timeout, msecs_to_jiffies(3142)); + REG_DBG_PRINT("SEIK reg_process_hint default\n"); + } break; + } } @@ -1558,6 +1574,7 @@ static void reg_process_pending_hints(void) REG_DBG_PRINT("Pending regulatory request, waiting for it to be processed...\n"); return; } + REG_DBG_PRINT("SEIK regulatory request...at 1\n"); spin_lock(®_requests_lock); @@ -1572,8 +1589,11 @@ static void reg_process_pending_hints(void) list_del_init(®_request->list); spin_unlock(®_requests_lock); + REG_DBG_PRINT("SEIK regulatory request...at 2\n"); reg_process_hint(reg_request, reg_request->initiator); + REG_DBG_PRINT("SEIK regulatory request...at 3\n"); + } /* Processes beacon hints -- this has nothing to do with country IEs */ [-- Attachment #3: syslog --] [-- Type: application/octet-stream, Size: 152381 bytes --] Oct 18 20:38:54 creabox kernel: imklog 5.8.11, log source = /proc/kmsg started. Oct 18 20:38:54 creabox rsyslogd: [origin software="rsyslogd" swVersion="5.8.11" x-pid="2509" x-info="http://www.rsyslog.com"] start Oct 18 20:38:54 creabox kernel: [ 0.018361] dmar: DRHD base: 0x000000fed90000 flags: 0x0 Oct 18 20:38:54 creabox kernel: [ 0.018436] dmar: IOMMU 0: reg_base_addr fed90000 ver 1:0 cap c0000020e60262 ecap f0101a Oct 18 20:38:54 creabox kernel: [ 0.018521] dmar: DRHD base: 0x000000fed91000 flags: 0x1 Oct 18 20:38:54 creabox kernel: [ 0.018593] dmar: IOMMU 1: reg_base_addr fed91000 ver 1:0 cap c9008020660262 ecap f0105a Oct 18 20:38:54 creabox kernel: [ 0.018679] dmar: RMRR base: 0x000000dbe07000 end: 0x000000dbe13fff Oct 18 20:38:54 creabox kernel: [ 0.018748] dmar: RMRR base: 0x000000dd800000 end: 0x000000df9fffff Oct 18 20:38:54 creabox kernel: [ 0.018889] IOAPIC id 2 under DRHD base 0xfed91000 IOMMU 1 Oct 18 20:38:54 creabox kernel: [ 0.018958] HPET id 0 under DRHD base 0xfed91000 Oct 18 20:38:54 creabox kernel: [ 0.019225] Enabled IRQ remapping in x2apic mode Oct 18 20:38:54 creabox kernel: [ 0.019293] Enabling x2apic Oct 18 20:38:54 creabox kernel: [ 0.019357] Enabled x2apic Oct 18 20:38:54 creabox kernel: [ 0.019434] Switched APIC routing to cluster x2apic. Oct 18 20:38:54 creabox kernel: [ 0.019964] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 Oct 18 20:38:54 creabox kernel: [ 0.059695] smpboot: CPU0: Intel(R) Core(TM) i5-3427U CPU @ 1.80GHz (fam: 06, model: 3a, stepping: 09) Oct 18 20:38:54 creabox kernel: [ 0.059927] TSC deadline timer enabled Oct 18 20:38:54 creabox kernel: [ 0.060000] Performance Events: PEBS fmt1+, 16-deep LBR, IvyBridge events, full-width counters, Intel PMU driver. Oct 18 20:38:54 creabox kernel: [ 0.060313] ... version: 3 Oct 18 20:38:54 creabox kernel: [ 0.060379] ... bit width: 48 Oct 18 20:38:54 creabox kernel: [ 0.060444] ... generic registers: 4 Oct 18 20:38:54 creabox kernel: [ 0.060508] ... value mask: 0000ffffffffffff Oct 18 20:38:54 creabox kernel: [ 0.060576] ... max period: 0000ffffffffffff Oct 18 20:38:54 creabox kernel: [ 0.060642] ... fixed-purpose events: 3 Oct 18 20:38:54 creabox kernel: [ 0.060707] ... event mask: 000000070000000f Oct 18 20:38:54 creabox kernel: [ 0.074786] NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter. Oct 18 20:38:54 creabox kernel: [ 0.061090] smpboot: Booting Node 0, Processors # 1 # 2 # 3 OK Oct 18 20:38:54 creabox kernel: [ 0.102455] Brought up 4 CPUs Oct 18 20:38:54 creabox kernel: [ 0.102523] smpboot: Total of 4 processors activated (18358.08 BogoMIPS) Oct 18 20:38:54 creabox kernel: [ 0.106859] devtmpfs: initialized Oct 18 20:38:54 creabox kernel: [ 0.107820] xor: automatically using best checksumming function: Oct 18 20:38:54 creabox kernel: [ 0.146580] avx : 12154.000 MB/sec Oct 18 20:38:54 creabox kernel: [ 0.146718] NET: Registered protocol family 16 Oct 18 20:38:54 creabox kernel: [ 0.147109] cpuidle: using governor ladder Oct 18 20:38:54 creabox kernel: [ 0.147177] cpuidle: using governor menu Oct 18 20:38:54 creabox kernel: [ 0.147459] ACPI: bus type PCI registered Oct 18 20:38:54 creabox kernel: [ 0.147526] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 Oct 18 20:38:54 creabox kernel: [ 0.147649] dca service started, version 1.12.1 Oct 18 20:38:54 creabox kernel: [ 0.147739] PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xf8000000-0xfbffffff] (base 0xf8000000) Oct 18 20:38:54 creabox kernel: [ 0.147828] PCI: MMCONFIG at [mem 0xf8000000-0xfbffffff] reserved in E820 Oct 18 20:38:54 creabox kernel: [ 0.152548] PCI: Using configuration type 1 for base access Oct 18 20:38:54 creabox kernel: [ 0.156142] bio: create slab <bio-0> at 0 Oct 18 20:38:54 creabox kernel: [ 0.222583] raid6: sse2x1 4583 MB/s Oct 18 20:38:54 creabox kernel: [ 0.290571] raid6: sse2x2 5735 MB/s Oct 18 20:38:54 creabox kernel: [ 0.358561] raid6: sse2x4 6506 MB/s Oct 18 20:38:54 creabox kernel: [ 0.358630] raid6: using algorithm sse2x4 (6506 MB/s) Oct 18 20:38:54 creabox kernel: [ 0.358696] raid6: using ssse3x2 recovery algorithm Oct 18 20:38:54 creabox kernel: [ 0.358813] ACPI: Added _OSI(Module Device) Oct 18 20:38:54 creabox kernel: [ 0.358882] ACPI: Added _OSI(Processor Device) Oct 18 20:38:54 creabox kernel: [ 0.358948] ACPI: Added _OSI(3.0 _SCP Extensions) Oct 18 20:38:54 creabox kernel: [ 0.359014] ACPI: Added _OSI(Processor Aggregator Device) Oct 18 20:38:54 creabox kernel: [ 0.360898] ACPI: EC: Look up EC in DSDT Oct 18 20:38:54 creabox kernel: [ 0.362948] ACPI: Executed 1 blocks of module-level executable AML code Oct 18 20:38:54 creabox kernel: [ 0.375173] ACPI: SSDT 00000000dbe1d018 0083B (v01 PmRef Cpu0Cst 00003001 INTL 20051117) Oct 18 20:38:54 creabox kernel: [ 0.375822] ACPI: Dynamic OEM Table Load: Oct 18 20:38:54 creabox kernel: [ 0.375979] ACPI: SSDT (null) 0083B (v01 PmRef Cpu0Cst 00003001 INTL 20051117) Oct 18 20:38:54 creabox kernel: [ 0.390913] ACPI: SSDT 00000000dbe1ea98 00303 (v01 PmRef ApIst 00003000 INTL 20051117) Oct 18 20:38:54 creabox kernel: [ 0.391609] ACPI: Dynamic OEM Table Load: Oct 18 20:38:54 creabox kernel: [ 0.391767] ACPI: SSDT (null) 00303 (v01 PmRef ApIst 00003000 INTL 20051117) Oct 18 20:38:54 creabox kernel: [ 0.402713] ACPI: SSDT 00000000dbe1fc18 00119 (v01 PmRef ApCst 00003000 INTL 20051117) Oct 18 20:38:54 creabox kernel: [ 0.403346] ACPI: Dynamic OEM Table Load: Oct 18 20:38:54 creabox kernel: [ 0.403502] ACPI: SSDT (null) 00119 (v01 PmRef ApCst 00003000 INTL 20051117) Oct 18 20:38:54 creabox kernel: [ 0.415421] ACPI: Interpreter enabled Oct 18 20:38:54 creabox kernel: [ 0.415494] ACPI: (supports S0 S5) Oct 18 20:38:54 creabox kernel: [ 0.415562] ACPI: Using IOAPIC for interrupt routing Oct 18 20:38:54 creabox kernel: [ 0.415666] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug Oct 18 20:38:54 creabox kernel: [ 0.415974] ACPI: No dock devices found. Oct 18 20:38:54 creabox kernel: [ 0.426273] ACPI: Power Resource [FN00] (off) Oct 18 20:38:54 creabox kernel: [ 0.426463] ACPI: Power Resource [FN01] (off) Oct 18 20:38:54 creabox kernel: [ 0.426658] ACPI: Power Resource [FN02] (off) Oct 18 20:38:54 creabox kernel: [ 0.426840] ACPI: Power Resource [FN03] (off) Oct 18 20:38:54 creabox kernel: [ 0.427026] ACPI: Power Resource [FN04] (off) Oct 18 20:38:54 creabox kernel: [ 0.427944] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-3e]) Oct 18 20:38:54 creabox kernel: [ 0.428388] acpi PNP0A08:00: Requesting ACPI _OSC control (0x1d) Oct 18 20:38:54 creabox kernel: [ 0.429133] acpi PNP0A08:00: ACPI _OSC control (0x1d) granted Oct 18 20:38:54 creabox kernel: [ 0.429903] ACPI: \_SB_.PCI0.TPMX: can't evaluate _ADR (0x5) Oct 18 20:38:54 creabox kernel: [ 0.430225] ACPI: \_SB_.PCI0.PDRC: can't evaluate _ADR (0x5) Oct 18 20:38:54 creabox kernel: [ 0.430298] ACPI: \_SB_.PCI0.ITPM: can't evaluate _ADR (0x5) Oct 18 20:38:54 creabox kernel: [ 0.430367] ACPI: \_SB_.PCI0.DOCK: can't evaluate _ADR (0x5) Oct 18 20:38:54 creabox kernel: [ 0.430435] PCI host bridge to bus 0000:00 Oct 18 20:38:54 creabox kernel: [ 0.430501] pci_bus 0000:00: root bus resource [bus 00-3e] Oct 18 20:38:54 creabox kernel: [ 0.430569] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7] Oct 18 20:38:54 creabox kernel: [ 0.430644] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff] Oct 18 20:38:54 creabox kernel: [ 0.430714] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff] Oct 18 20:38:54 creabox kernel: [ 0.430786] pci_bus 0000:00: root bus resource [mem 0x000d0000-0x000d3fff] Oct 18 20:38:54 creabox kernel: [ 0.430854] pci_bus 0000:00: root bus resource [mem 0x000d4000-0x000d7fff] Oct 18 20:38:54 creabox kernel: [ 0.430925] pci_bus 0000:00: root bus resource [mem 0x000d8000-0x000dbfff] Oct 18 20:38:54 creabox kernel: [ 0.430995] pci_bus 0000:00: root bus resource [mem 0x000dc000-0x000dffff] Oct 18 20:38:54 creabox kernel: [ 0.431064] pci_bus 0000:00: root bus resource [mem 0x000e0000-0x000e3fff] Oct 18 20:38:54 creabox kernel: [ 0.431134] pci_bus 0000:00: root bus resource [mem 0x000e4000-0x000e7fff] Oct 18 20:38:54 creabox kernel: [ 0.431202] pci_bus 0000:00: root bus resource [mem 0xdfa00000-0xfeafffff] Oct 18 20:38:54 creabox kernel: [ 0.431281] pci 0000:00:00.0: [8086:0154] type 00 class 0x060000 Oct 18 20:38:54 creabox kernel: [ 0.431485] pci 0000:00:02.0: [8086:0166] type 00 class 0x030000 Oct 18 20:38:54 creabox kernel: [ 0.431569] pci 0000:00:02.0: reg 0x10: [mem 0xf7800000-0xf7bfffff 64bit] Oct 18 20:38:54 creabox kernel: [ 0.431649] pci 0000:00:02.0: reg 0x18: [mem 0xe0000000-0xefffffff 64bit pref] Oct 18 20:38:54 creabox kernel: [ 0.431739] pci 0000:00:02.0: reg 0x20: [io 0xf000-0xf03f] Oct 18 20:38:54 creabox kernel: [ 0.431960] pci 0000:00:14.0: [8086:1e31] type 00 class 0x0c0330 Oct 18 20:38:54 creabox kernel: [ 0.432055] pci 0000:00:14.0: reg 0x10: [mem 0xf7d20000-0xf7d2ffff 64bit] Oct 18 20:38:54 creabox kernel: [ 0.432207] pci 0000:00:14.0: PME# supported from D3hot D3cold Oct 18 20:38:54 creabox kernel: [ 0.432351] pci 0000:00:14.0: System wakeup disabled by ACPI Oct 18 20:38:54 creabox kernel: [ 0.432478] pci 0000:00:16.0: [8086:1e3a] type 00 class 0x078000 Oct 18 20:38:54 creabox kernel: [ 0.432571] pci 0000:00:16.0: reg 0x10: [mem 0xf7d3c000-0xf7d3c00f 64bit] Oct 18 20:38:54 creabox kernel: [ 0.432729] pci 0000:00:16.0: PME# supported from D0 D3hot D3cold Oct 18 20:38:54 creabox kernel: [ 0.432915] pci 0000:00:16.3: [8086:1e3d] type 00 class 0x070002 Oct 18 20:38:54 creabox kernel: [ 0.432999] pci 0000:00:16.3: reg 0x10: [io 0xf0e0-0xf0e7] Oct 18 20:38:54 creabox kernel: [ 0.433077] pci 0000:00:16.3: reg 0x14: [mem 0xf7d3a000-0xf7d3afff] Oct 18 20:38:54 creabox kernel: [ 0.433345] pci 0000:00:19.0: [8086:1502] type 00 class 0x020000 Oct 18 20:38:54 creabox kernel: [ 0.433436] pci 0000:00:19.0: reg 0x10: [mem 0xf7d00000-0xf7d1ffff] Oct 18 20:38:54 creabox kernel: [ 0.433512] pci 0000:00:19.0: reg 0x14: [mem 0xf7d39000-0xf7d39fff] Oct 18 20:38:54 creabox kernel: [ 0.433590] pci 0000:00:19.0: reg 0x18: [io 0xf080-0xf09f] Oct 18 20:38:54 creabox kernel: [ 0.433729] pci 0000:00:19.0: PME# supported from D0 D3hot D3cold Oct 18 20:38:54 creabox kernel: [ 0.433870] pci 0000:00:19.0: System wakeup disabled by ACPI Oct 18 20:38:54 creabox kernel: [ 0.433992] pci 0000:00:1a.0: [8086:1e2d] type 00 class 0x0c0320 Oct 18 20:38:54 creabox kernel: [ 0.434080] pci 0000:00:1a.0: reg 0x10: [mem 0xf7d38000-0xf7d383ff] Oct 18 20:38:54 creabox kernel: [ 0.434250] pci 0000:00:1a.0: PME# supported from D0 D3hot D3cold Oct 18 20:38:54 creabox kernel: [ 0.434416] pci 0000:00:1a.0: System wakeup disabled by ACPI Oct 18 20:38:54 creabox kernel: [ 0.434540] pci 0000:00:1b.0: [8086:1e20] type 00 class 0x040300 Oct 18 20:38:54 creabox kernel: [ 0.434628] pci 0000:00:1b.0: reg 0x10: [mem 0xf7d30000-0xf7d33fff 64bit] Oct 18 20:38:54 creabox kernel: [ 0.434785] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold Oct 18 20:38:54 creabox kernel: [ 0.434932] pci 0000:00:1b.0: System wakeup disabled by ACPI Oct 18 20:38:54 creabox kernel: [ 0.435049] pci 0000:00:1c.0: [8086:1e10] type 01 class 0x060400 Oct 18 20:38:54 creabox kernel: [ 0.435249] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold Oct 18 20:38:54 creabox kernel: [ 0.435403] pci 0000:00:1c.0: System wakeup disabled by ACPI Oct 18 20:38:54 creabox kernel: [ 0.435524] pci 0000:00:1c.2: [8086:1e14] type 01 class 0x060400 Oct 18 20:38:54 creabox kernel: [ 0.435723] pci 0000:00:1c.2: PME# supported from D0 D3hot D3cold Oct 18 20:38:54 creabox kernel: [ 0.435877] pci 0000:00:1c.2: System wakeup disabled by ACPI Oct 18 20:38:54 creabox kernel: [ 0.436009] pci 0000:00:1d.0: [8086:1e26] type 00 class 0x0c0320 Oct 18 20:38:54 creabox kernel: [ 0.436100] pci 0000:00:1d.0: reg 0x10: [mem 0xf7d37000-0xf7d373ff] Oct 18 20:38:54 creabox kernel: [ 0.436271] pci 0000:00:1d.0: PME# supported from D0 D3hot D3cold Oct 18 20:38:54 creabox kernel: [ 0.436430] pci 0000:00:1d.0: System wakeup disabled by ACPI Oct 18 20:38:54 creabox kernel: [ 0.436549] pci 0000:00:1f.0: [8086:1e56] type 00 class 0x060100 Oct 18 20:38:54 creabox kernel: [ 0.436848] pci 0000:00:1f.2: [8086:1e03] type 00 class 0x010601 Oct 18 20:38:54 creabox kernel: [ 0.436938] pci 0000:00:1f.2: reg 0x10: [io 0xf0d0-0xf0d7] Oct 18 20:38:54 creabox kernel: [ 0.437015] pci 0000:00:1f.2: reg 0x14: [io 0xf0c0-0xf0c3] Oct 18 20:38:54 creabox kernel: [ 0.437090] pci 0000:00:1f.2: reg 0x18: [io 0xf0b0-0xf0b7] Oct 18 20:38:54 creabox kernel: [ 0.437167] pci 0000:00:1f.2: reg 0x1c: [io 0xf0a0-0xf0a3] Oct 18 20:38:54 creabox kernel: [ 0.437243] pci 0000:00:1f.2: reg 0x20: [io 0xf060-0xf07f] Oct 18 20:38:54 creabox kernel: [ 0.437320] pci 0000:00:1f.2: reg 0x24: [mem 0xf7d36000-0xf7d367ff] Oct 18 20:38:54 creabox kernel: [ 0.437443] pci 0000:00:1f.2: PME# supported from D3hot Oct 18 20:38:54 creabox kernel: [ 0.437624] pci 0000:00:1f.3: [8086:1e22] type 00 class 0x0c0500 Oct 18 20:38:54 creabox kernel: [ 0.437713] pci 0000:00:1f.3: reg 0x10: [mem 0xf7d35000-0xf7d350ff 64bit] Oct 18 20:38:54 creabox kernel: [ 0.437807] pci 0000:00:1f.3: reg 0x20: [io 0xf040-0xf05f] Oct 18 20:38:54 creabox kernel: [ 0.438101] pci 0000:00:1c.0: PCI bridge to [bus 01] Oct 18 20:38:54 creabox kernel: [ 0.439894] pci 0000:02:00.0: [8086:088e] type 00 class 0x028000 Oct 18 20:38:54 creabox kernel: [ 0.440147] pci 0000:02:00.0: reg 0x10: [mem 0xf7c00000-0xf7c01fff 64bit] Oct 18 20:38:54 creabox kernel: [ 0.440943] pci 0000:02:00.0: PME# supported from D0 D3hot D3cold Oct 18 20:38:54 creabox kernel: [ 0.441173] pci 0000:02:00.0: System wakeup disabled by ACPI Oct 18 20:38:54 creabox kernel: [ 0.447727] pci 0000:00:1c.2: PCI bridge to [bus 02] Oct 18 20:38:54 creabox kernel: [ 0.447804] pci 0000:00:1c.2: bridge window [mem 0xf7c00000-0xf7cfffff] Oct 18 20:38:54 creabox kernel: [ 0.448569] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 10 *11 12 14 15) Oct 18 20:38:54 creabox kernel: [ 0.449200] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled. Oct 18 20:38:54 creabox kernel: [ 0.449932] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 *4 5 6 10 11 12 14 15) Oct 18 20:38:54 creabox kernel: [ 0.450557] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 *10 11 12 14 15) Oct 18 20:38:54 creabox kernel: [ 0.451178] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 *5 6 10 11 12 14 15) Oct 18 20:38:54 creabox kernel: [ 0.451810] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled. Oct 18 20:38:54 creabox kernel: [ 0.452537] ACPI: PCI Interrupt Link [LNKG] (IRQs *3 4 5 6 10 11 12 14 15) Oct 18 20:38:54 creabox kernel: [ 0.453165] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 10 *11 12 14 15) Oct 18 20:38:54 creabox kernel: [ 0.454007] ACPI: Enabled 6 GPEs in block 00 to 3F Oct 18 20:38:54 creabox kernel: [ 0.454167] ACPI: \_SB_.PCI0: notify handler is installed Oct 18 20:38:54 creabox kernel: [ 0.454309] Found 1 acpi root devices Oct 18 20:38:54 creabox kernel: [ 0.454485] vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none Oct 18 20:38:54 creabox kernel: [ 0.454572] vgaarb: loaded Oct 18 20:38:54 creabox kernel: [ 0.454638] vgaarb: bridge control possible 0000:00:02.0 Oct 18 20:38:54 creabox kernel: [ 0.454834] SCSI subsystem initialized Oct 18 20:38:54 creabox kernel: [ 0.454957] libata version 3.00 loaded. Oct 18 20:38:54 creabox kernel: [ 0.455049] ACPI: bus type USB registered Oct 18 20:38:54 creabox kernel: [ 0.455137] usbcore: registered new interface driver usbfs Oct 18 20:38:54 creabox kernel: [ 0.455219] usbcore: registered new interface driver hub Oct 18 20:38:54 creabox kernel: [ 0.455330] usbcore: registered new device driver usb Oct 18 20:38:54 creabox kernel: [ 0.455424] pps_core: LinuxPPS API ver. 1 registered Oct 18 20:38:54 creabox kernel: [ 0.455491] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it> Oct 18 20:38:54 creabox kernel: [ 0.455578] PTP clock support registered Oct 18 20:38:54 creabox kernel: [ 0.455687] wmi: Mapper loaded Oct 18 20:38:54 creabox kernel: [ 0.455778] Advanced Linux Sound Architecture Driver Initialized. Oct 18 20:38:54 creabox kernel: [ 0.455849] PCI: Using ACPI for IRQ routing Oct 18 20:38:54 creabox kernel: [ 0.457781] PCI: pci_cache_line_size set to 64 bytes Oct 18 20:38:54 creabox kernel: [ 0.457960] e820: reserve RAM buffer [mem 0x0009d800-0x0009ffff] Oct 18 20:38:54 creabox kernel: [ 0.458032] e820: reserve RAM buffer [mem 0x40004000-0x43ffffff] Oct 18 20:38:54 creabox kernel: [ 0.458100] e820: reserve RAM buffer [mem 0xdb9f1000-0xdbffffff] Oct 18 20:38:54 creabox kernel: [ 0.458168] e820: reserve RAM buffer [mem 0xdc20e000-0xdfffffff] Oct 18 20:38:54 creabox kernel: [ 0.458238] e820: reserve RAM buffer [mem 0xdd000000-0xdfffffff] Oct 18 20:38:54 creabox kernel: [ 0.458307] e820: reserve RAM buffer [mem 0x21e600000-0x21fffffff] Oct 18 20:38:54 creabox kernel: [ 0.458565] cfg80211: SEIK regulatory request...at 1 Oct 18 20:38:54 creabox kernel: [ 0.458636] cfg80211: SEIK regulatory request...at 2 Oct 18 20:38:54 creabox kernel: [ 0.458702] cfg80211: SEIK reg_process_hint begin Oct 18 20:38:54 creabox kernel: [ 0.458770] cfg80211: Calling CRDA to update world regulatory domain Oct 18 20:38:54 creabox kernel: [ 0.458845] cfg80211: SEIK regulatory request...at 3 Oct 18 20:38:54 creabox kernel: [ 0.459204] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0, 0, 0, 0, 0 Oct 18 20:38:54 creabox kernel: [ 0.459666] hpet0: 8 comparators, 64-bit 14.318180 MHz counter Oct 18 20:38:54 creabox kernel: [ 0.461762] Switched to clocksource hpet Oct 18 20:38:54 creabox kernel: [ 0.467410] FS-Cache: Loaded Oct 18 20:38:54 creabox kernel: [ 0.467540] CacheFiles: Loaded Oct 18 20:38:54 creabox kernel: [ 0.467621] pnp: PnP ACPI init Oct 18 20:38:54 creabox kernel: [ 0.467696] ACPI: bus type PNP registered Oct 18 20:38:54 creabox kernel: [ 0.467830] pnp 00:00: [dma 4] Oct 18 20:38:54 creabox kernel: [ 0.467923] pnp 00:00: Plug and Play ACPI device, IDs PNP0200 (active) Oct 18 20:38:54 creabox kernel: [ 0.468024] pnp 00:01: Plug and Play ACPI device, IDs INT0800 (active) Oct 18 20:38:54 creabox kernel: [ 0.468236] pnp 00:02: Plug and Play ACPI device, IDs PNP0103 (active) Oct 18 20:38:54 creabox kernel: [ 0.468362] system 00:03: [io 0x0680-0x069f] has been reserved Oct 18 20:38:54 creabox kernel: [ 0.468433] system 00:03: [io 0x1000-0x100f] has been reserved Oct 18 20:38:54 creabox kernel: [ 0.468502] system 00:03: [io 0xffff] has been reserved Oct 18 20:38:54 creabox kernel: [ 0.468570] system 00:03: [io 0xffff] has been reserved Oct 18 20:38:54 creabox kernel: [ 0.468640] system 00:03: [io 0x0400-0x0453] could not be reserved Oct 18 20:38:54 creabox kernel: [ 0.468711] system 00:03: [io 0x0458-0x047f] has been reserved Oct 18 20:38:54 creabox kernel: [ 0.468781] system 00:03: [io 0x0500-0x057f] has been reserved Oct 18 20:38:54 creabox kernel: [ 0.468850] system 00:03: [io 0x164e-0x164f] has been reserved Oct 18 20:38:54 creabox kernel: [ 0.468919] system 00:03: Plug and Play ACPI device, IDs PNP0c02 (active) Oct 18 20:38:54 creabox kernel: [ 0.469033] pnp 00:04: Plug and Play ACPI device, IDs PNP0b00 (active) Oct 18 20:38:54 creabox kernel: [ 0.469163] system 00:05: [io 0x0454-0x0457] has been reserved Oct 18 20:38:54 creabox kernel: [ 0.469234] system 00:05: Plug and Play ACPI device, IDs INT3f0d PNP0c02 (active) Oct 18 20:38:54 creabox kernel: [ 0.469491] system 00:06: [io 0x0a00-0x0a1f] has been reserved Oct 18 20:38:54 creabox kernel: [ 0.469561] system 00:06: [io 0x0a30-0x0a3f] has been reserved Oct 18 20:38:54 creabox kernel: [ 0.469632] system 00:06: [io 0x0a20-0x0a2f] has been reserved Oct 18 20:38:54 creabox kernel: [ 0.469701] system 00:06: Plug and Play ACPI device, IDs PNP0c02 (active) Oct 18 20:38:54 creabox kernel: [ 0.469881] system 00:07: [io 0x04d0-0x04d1] has been reserved Oct 18 20:38:54 creabox kernel: [ 0.469956] system 00:07: Plug and Play ACPI device, IDs PNP0c02 (active) Oct 18 20:38:54 creabox kernel: [ 0.470063] pnp 00:08: Plug and Play ACPI device, IDs PNP0c04 (active) Oct 18 20:38:54 creabox kernel: [ 0.470193] pnp 00:09: Plug and Play ACPI device, IDs PNP0c31 (active) Oct 18 20:38:54 creabox kernel: [ 0.470593] system 00:0a: [mem 0xfed1c000-0xfed1ffff] has been reserved Oct 18 20:38:54 creabox kernel: [ 0.470667] system 00:0a: [mem 0xfed10000-0xfed17fff] has been reserved Oct 18 20:38:54 creabox kernel: [ 0.470737] system 00:0a: [mem 0xfed18000-0xfed18fff] has been reserved Oct 18 20:38:54 creabox kernel: [ 0.470807] system 00:0a: [mem 0xfed19000-0xfed19fff] has been reserved Oct 18 20:38:54 creabox kernel: [ 0.470877] system 00:0a: [mem 0xf8000000-0xfbffffff] has been reserved Oct 18 20:38:54 creabox kernel: [ 0.470949] system 00:0a: [mem 0xfed20000-0xfed3ffff] has been reserved Oct 18 20:38:54 creabox kernel: [ 0.471021] system 00:0a: [mem 0xfed90000-0xfed93fff] could not be reserved Oct 18 20:38:54 creabox kernel: [ 0.471091] system 00:0a: [mem 0xfed45000-0xfed8ffff] has been reserved Oct 18 20:38:54 creabox kernel: [ 0.471162] system 00:0a: [mem 0xff000000-0xffffffff] has been reserved Oct 18 20:38:54 creabox kernel: [ 0.471232] system 00:0a: [mem 0xfee00000-0xfeefffff] could not be reserved Oct 18 20:38:54 creabox kernel: [ 0.471303] system 00:0a: [mem 0xdfa00000-0xdfa00fff] has been reserved Oct 18 20:38:54 creabox kernel: [ 0.471373] system 00:0a: Plug and Play ACPI device, IDs PNP0c02 (active) Oct 18 20:38:54 creabox kernel: [ 0.471714] system 00:0b: [mem 0x20000000-0x201fffff] has been reserved Oct 18 20:38:54 creabox kernel: [ 0.471788] system 00:0b: [mem 0x40004000-0x40004fff] has been reserved Oct 18 20:38:54 creabox kernel: [ 0.471859] system 00:0b: Plug and Play ACPI device, IDs PNP0c01 (active) Oct 18 20:38:54 creabox kernel: [ 0.471957] pnp: PnP ACPI: found 12 devices Oct 18 20:38:54 creabox kernel: [ 0.472024] ACPI: bus type PNP unregistered Oct 18 20:38:54 creabox kernel: [ 0.479427] pci 0000:00:1c.0: PCI bridge to [bus 01] Oct 18 20:38:54 creabox kernel: [ 0.479515] pci 0000:00:1c.2: PCI bridge to [bus 02] Oct 18 20:38:54 creabox kernel: [ 0.479588] pci 0000:00:1c.2: bridge window [mem 0xf7c00000-0xf7cfffff] Oct 18 20:38:54 creabox kernel: [ 0.479670] pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7] Oct 18 20:38:54 creabox kernel: [ 0.479740] pci_bus 0000:00: resource 5 [io 0x0d00-0xffff] Oct 18 20:38:54 creabox kernel: [ 0.479806] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff] Oct 18 20:38:54 creabox kernel: [ 0.479877] pci_bus 0000:00: resource 7 [mem 0x000d0000-0x000d3fff] Oct 18 20:38:54 creabox kernel: [ 0.479947] pci_bus 0000:00: resource 8 [mem 0x000d4000-0x000d7fff] Oct 18 20:38:54 creabox kernel: [ 0.480017] pci_bus 0000:00: resource 9 [mem 0x000d8000-0x000dbfff] Oct 18 20:38:54 creabox kernel: [ 0.480085] pci_bus 0000:00: resource 10 [mem 0x000dc000-0x000dffff] Oct 18 20:38:54 creabox kernel: [ 0.480155] pci_bus 0000:00: resource 11 [mem 0x000e0000-0x000e3fff] Oct 18 20:38:54 creabox kernel: [ 0.480225] pci_bus 0000:00: resource 12 [mem 0x000e4000-0x000e7fff] Oct 18 20:38:54 creabox kernel: [ 0.480295] pci_bus 0000:00: resource 13 [mem 0xdfa00000-0xfeafffff] Oct 18 20:38:54 creabox kernel: [ 0.480365] pci_bus 0000:02: resource 1 [mem 0xf7c00000-0xf7cfffff] Oct 18 20:38:54 creabox kernel: [ 0.480509] NET: Registered protocol family 2 Oct 18 20:38:54 creabox kernel: [ 0.480893] TCP established hash table entries: 65536 (order: 8, 1048576 bytes) Oct 18 20:38:54 creabox kernel: [ 0.481244] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) Oct 18 20:38:54 creabox kernel: [ 0.481492] TCP: Hash tables configured (established 65536 bind 65536) Oct 18 20:38:54 creabox kernel: [ 0.481586] TCP: reno registered Oct 18 20:38:54 creabox kernel: [ 0.481667] UDP hash table entries: 4096 (order: 5, 131072 bytes) Oct 18 20:38:54 creabox kernel: [ 0.481800] UDP-Lite hash table entries: 4096 (order: 5, 131072 bytes) Oct 18 20:38:54 creabox kernel: [ 0.481969] NET: Registered protocol family 1 Oct 18 20:38:54 creabox kernel: [ 0.482048] pci 0000:00:02.0: Boot video device Oct 18 20:38:54 creabox kernel: [ 0.521914] PCI: CLS 64 bytes, default 64 Oct 18 20:38:54 creabox kernel: [ 0.522028] Trying to unpack rootfs image as initramfs... Oct 18 20:38:54 creabox kernel: [ 0.716431] Freeing initrd memory: 9280K (ffff880036dd0000 - ffff8800376e0000) Oct 18 20:38:54 creabox kernel: [ 0.716528] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) Oct 18 20:38:54 creabox kernel: [ 0.716600] software IO TLB [mem 0xd79f1000-0xdb9f1000] (64MB) mapped at [ffff8800d79f1000-ffff8800db9f0fff] Oct 18 20:38:54 creabox kernel: [ 0.717567] microcode: CPU0 sig=0x306a9, pf=0x10, revision=0x17 Oct 18 20:38:54 creabox kernel: [ 0.717655] microcode: CPU1 sig=0x306a9, pf=0x10, revision=0x17 Oct 18 20:38:54 creabox kernel: [ 0.717732] microcode: CPU2 sig=0x306a9, pf=0x10, revision=0x17 Oct 18 20:38:54 creabox kernel: [ 0.717811] microcode: CPU3 sig=0x306a9, pf=0x10, revision=0x17 Oct 18 20:38:54 creabox kernel: [ 0.717927] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba Oct 18 20:38:54 creabox kernel: [ 0.725753] alg: No test for __gcm-aes-aesni (__driver-gcm-aes-aesni) Oct 18 20:38:54 creabox kernel: [ 0.728315] sha1_ssse3: Using AVX optimized SHA-1 implementation Oct 18 20:38:54 creabox kernel: [ 0.728716] audit: initializing netlink socket (disabled) Oct 18 20:38:54 creabox kernel: [ 0.728799] type=2000 audit(1382121527.724:1): initialized Oct 18 20:38:54 creabox kernel: [ 0.769866] bounce pool size: 64 pages Oct 18 20:38:54 creabox kernel: [ 0.769941] HugeTLB registered 2 MB page size, pre-allocated 0 pages Oct 18 20:38:54 creabox kernel: [ 0.770614] VFS: Disk quotas dquot_6.5.2 Oct 18 20:38:54 creabox kernel: [ 0.770712] Dquot-cache hash table entries: 512 (order 0, 4096 bytes) Oct 18 20:38:54 creabox kernel: [ 0.771209] FS-Cache: Netfs 'cifs' registered for caching Oct 18 20:38:54 creabox kernel: [ 0.771324] Key type cifs.spnego registered Oct 18 20:38:54 creabox kernel: [ 0.771401] Key type cifs.idmap registered Oct 18 20:38:54 creabox kernel: [ 0.771472] NTFS driver 2.1.30 [Flags: R/W]. Oct 18 20:38:54 creabox kernel: [ 0.771642] fuse init (API version 7.22) Oct 18 20:38:54 creabox kernel: [ 0.771851] bio: create slab <bio-1> at 1 Oct 18 20:38:54 creabox kernel: [ 0.772098] Btrfs loaded Oct 18 20:38:54 creabox kernel: [ 0.772174] msgmni has been set to 15821 Oct 18 20:38:54 creabox kernel: [ 0.777121] alg: No test for stdrng (krng) Oct 18 20:38:54 creabox kernel: [ 0.783352] alg: No test for fips(ansi_cprng) (fips_ansi_cprng) Oct 18 20:38:54 creabox kernel: [ 0.783506] NET: Registered protocol family 38 Oct 18 20:38:54 creabox kernel: [ 0.783602] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249) Oct 18 20:38:54 creabox kernel: [ 0.783687] io scheduler noop registered Oct 18 20:38:54 creabox kernel: [ 0.783753] io scheduler deadline registered Oct 18 20:38:54 creabox kernel: [ 0.783839] io scheduler cfq registered (default) Oct 18 20:38:54 creabox kernel: [ 0.784180] pcieport 0000:00:1c.0: irq 42 for MSI/MSI-X Oct 18 20:38:54 creabox kernel: [ 0.784499] pcieport 0000:00:1c.2: irq 43 for MSI/MSI-X Oct 18 20:38:54 creabox kernel: [ 0.784707] pcieport 0000:00:1c.0: Signaling PME through PCIe PME interrupt Oct 18 20:38:54 creabox kernel: [ 0.784786] pcie_pme 0000:00:1c.0:pcie01: service driver pcie_pme loaded Oct 18 20:38:54 creabox kernel: [ 0.784878] pcieport 0000:00:1c.2: Signaling PME through PCIe PME interrupt Oct 18 20:38:54 creabox kernel: [ 0.784952] pci 0000:02:00.0: Signaling PME through PCIe PME interrupt Oct 18 20:38:54 creabox kernel: [ 0.785027] pcie_pme 0000:00:1c.2:pcie01: service driver pcie_pme loaded Oct 18 20:38:54 creabox kernel: [ 0.785112] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 Oct 18 20:38:54 creabox kernel: [ 0.785197] pciehp: PCI Express Hot Plug Controller Driver version: 0.4 Oct 18 20:38:54 creabox kernel: [ 0.785270] cpcihp_zt5550: ZT5550 CompactPCI Hot Plug Driver version: 0.2 Oct 18 20:38:54 creabox kernel: [ 0.785355] cpcihp_generic: Generic port I/O CompactPCI Hot Plug Driver version: 0.1 Oct 18 20:38:54 creabox kernel: [ 0.785438] cpcihp_generic: not configured, disabling. Oct 18 20:38:54 creabox kernel: [ 0.785517] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 Oct 18 20:38:54 creabox kernel: [ 0.787487] acpiphp_ibm: ibm_acpiphp_init: acpi_walk_namespace failed Oct 18 20:38:54 creabox kernel: [ 0.787608] vmlfb: initializing Oct 18 20:38:54 creabox kernel: [ 0.787811] uvesafb: failed to execute /sbin/v86d Oct 18 20:38:54 creabox kernel: [ 0.787881] uvesafb: make sure that the v86d helper is installed and executable Oct 18 20:38:54 creabox kernel: [ 0.787964] uvesafb: Getting VBE info block failed (eax=0x4f00, err=-2) Oct 18 20:38:54 creabox kernel: [ 0.788034] uvesafb: vbe_init() failed with -22 Oct 18 20:38:54 creabox kernel: [ 0.788105] uvesafb: probe of uvesafb.0 failed with error -22 Oct 18 20:38:54 creabox kernel: [ 0.789642] vga16fb: initializing Oct 18 20:38:54 creabox kernel: [ 0.789707] vga16fb: mapped to 0xffff8800000a0000 Oct 18 20:38:54 creabox kernel: [ 0.883473] Console: switching to colour frame buffer device 80x30 Oct 18 20:38:54 creabox kernel: [ 0.890665] fb0: VGA16 VGA frame buffer device Oct 18 20:38:54 creabox kernel: [ 0.890930] intel_idle: MWAIT substates: 0x21120 Oct 18 20:38:54 creabox kernel: [ 0.891196] intel_idle: v0.4 model 0x3A Oct 18 20:38:54 creabox kernel: [ 0.891439] intel_idle: lapic_timer_reliable_states 0xffffffff Oct 18 20:38:54 creabox kernel: [ 0.891897] ipmi message handler version 39.2 Oct 18 20:38:54 creabox kernel: [ 0.904038] ipmi device interface Oct 18 20:38:54 creabox kernel: [ 0.916247] IPMI System Interface driver. Oct 18 20:38:54 creabox kernel: [ 0.928363] ipmi_si: Adding default-specified kcs state machine Oct 18 20:38:54 creabox kernel: [ 0.940563] ipmi_si: Trying default-specified kcs state machine at i/o address 0xca2, slave address 0x0, irq 0 Oct 18 20:38:54 creabox kernel: [ 0.964230] ipmi_si: Interface detection failed Oct 18 20:38:54 creabox kernel: [ 0.993556] ipmi_si: Adding default-specified smic state machine Oct 18 20:38:54 creabox kernel: [ 1.005504] ipmi_si: Trying default-specified smic state machine at i/o address 0xca9, slave address 0x0, irq 0 Oct 18 20:38:54 creabox kernel: [ 1.029477] ipmi_si: Interface detection failed Oct 18 20:38:54 creabox kernel: [ 1.085580] ipmi_si: Adding default-specified bt state machine Oct 18 20:38:54 creabox kernel: [ 1.097546] ipmi_si: Trying default-specified bt state machine at i/o address 0xe4, slave address 0x0, irq 0 Oct 18 20:38:54 creabox kernel: [ 1.120978] ipmi_si: Interface detection failed Oct 18 20:38:54 creabox kernel: [ 1.153594] ipmi_si: Unable to find any System Interface(s) Oct 18 20:38:54 creabox kernel: [ 1.165332] IPMI Watchdog: driver initialized Oct 18 20:38:54 creabox kernel: [ 1.176980] Copyright (C) 2004 MontaVista Software - IPMI Powerdown via sys_reboot. Oct 18 20:38:54 creabox kernel: [ 1.200056] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input0 Oct 18 20:38:54 creabox kernel: [ 1.222642] ACPI: Power Button [PWRB] Oct 18 20:38:54 creabox kernel: [ 1.234099] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1 Oct 18 20:38:54 creabox kernel: [ 1.256831] ACPI: Power Button [PWRF] Oct 18 20:38:54 creabox kernel: [ 1.268437] ACPI: Fan [FAN0] (off) Oct 18 20:38:54 creabox kernel: [ 1.279774] ACPI: Fan [FAN1] (off) Oct 18 20:38:54 creabox kernel: [ 1.291016] ACPI: Fan [FAN2] (off) Oct 18 20:38:54 creabox kernel: [ 1.302160] ACPI: Fan [FAN3] (off) Oct 18 20:38:54 creabox kernel: [ 1.313160] ACPI: Fan [FAN4] (off) Oct 18 20:38:54 creabox kernel: [ 1.324055] ACPI: Requesting acpi_cpufreq Oct 18 20:38:54 creabox kernel: [ 1.362156] thermal LNXTHERM:00: registered as thermal_zone0 Oct 18 20:38:54 creabox kernel: [ 1.373090] ACPI: Thermal Zone [TZ00] (28 C) Oct 18 20:38:54 creabox kernel: [ 1.384136] thermal LNXTHERM:01: registered as thermal_zone1 Oct 18 20:38:54 creabox kernel: [ 1.394846] ACPI: Thermal Zone [TZ01] (30 C) Oct 18 20:38:54 creabox kernel: [ 1.405325] GHES: HEST is not enabled! Oct 18 20:38:54 creabox kernel: [ 1.415589] ioatdma: Intel(R) QuickData Technology Driver 4.00 Oct 18 20:38:54 creabox kernel: [ 1.426146] xenfs: not registering filesystem on non-xen platform Oct 18 20:38:54 creabox kernel: [ 1.436557] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled Oct 18 20:38:54 creabox kernel: [ 1.467509] 0000:00:16.3: ttyS0 at I/O 0xf0e0 (irq = 19, base_baud = 115200) is a 16550A Oct 18 20:38:54 creabox kernel: [ 1.488436] Non-volatile memory driver v1.3 Oct 18 20:38:54 creabox kernel: [ 1.499202] Linux agpgart interface v0.103 Oct 18 20:38:54 creabox kernel: [ 1.509628] Hangcheck: starting hangcheck timer 0.9.1 (tick is 180 seconds, margin is 60 seconds). Oct 18 20:38:54 creabox kernel: [ 1.531420] Hangcheck: Using getrawmonotonic(). Oct 18 20:38:54 creabox kernel: [ 1.542677] tpm_tis 00:09: 1.2 TPM (device-id 0x0, rev-id 78) Oct 18 20:38:54 creabox kernel: [ 1.601408] [drm] Initialized drm 1.1.0 20060810 Oct 18 20:38:54 creabox kernel: [ 1.612014] drm/i810 does not support SMP Oct 18 20:38:54 creabox kernel: [ 1.623287] [drm] Memory usable by graphics device = 2048M Oct 18 20:38:54 creabox kernel: [ 1.633638] checking generic (a0000 10000) vs hw (e0000000 10000000) Oct 18 20:38:54 creabox kernel: [ 1.643982] fb: conflicting fb hw usage inteldrmfb vs VGA16 VGA - removing generic driver Oct 18 20:38:54 creabox kernel: [ 1.683615] Console: switching to colour VGA+ 80x25 Oct 18 20:38:54 creabox kernel: [ 1.684515] i915 0000:00:02.0: setting latency timer to 64 Oct 18 20:38:54 creabox kernel: [ 1.707257] i915 0000:00:02.0: irq 44 for MSI/MSI-X Oct 18 20:38:54 creabox kernel: [ 1.707338] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). Oct 18 20:38:54 creabox kernel: [ 1.707407] [drm] Driver supports precise vblank timestamp query. Oct 18 20:38:54 creabox kernel: [ 1.707602] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem Oct 18 20:38:54 creabox kernel: [ 1.713148] tsc: Refined TSC clocksource calibration: 2294.787 MHz Oct 18 20:38:54 creabox kernel: [ 1.805086] [drm] GMBUS [i915 gmbus vga] timed out, falling back to bit banging on pin 2 Oct 18 20:38:54 creabox kernel: [ 1.875295] fbcon: inteldrmfb (fb0) is primary device Oct 18 20:38:54 creabox kernel: [ 2.078247] Console: switching to colour frame buffer device 210x65 Oct 18 20:38:54 creabox kernel: [ 2.086197] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device Oct 18 20:38:54 creabox kernel: [ 2.086243] i915 0000:00:02.0: registered panic notifier Oct 18 20:38:54 creabox kernel: [ 2.114469] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) Oct 18 20:38:54 creabox kernel: [ 2.114598] input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input2 Oct 18 20:38:54 creabox kernel: [ 2.114693] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 Oct 18 20:38:54 creabox kernel: [ 2.116595] brd: module loaded Oct 18 20:38:54 creabox kernel: [ 2.117534] loop: module loaded Oct 18 20:38:54 creabox kernel: [ 2.117857] nbd: registered device at major 43 Oct 18 20:38:54 creabox kernel: [ 2.119495] events: mcg drbd: 7 Oct 18 20:38:54 creabox kernel: [ 2.123716] drbd: initialized. Version: 8.4.3 (api:1/proto:86-101) Oct 18 20:38:54 creabox kernel: [ 2.123772] drbd: built-in Oct 18 20:38:54 creabox kernel: [ 2.123795] drbd: registered as block device major 147 Oct 18 20:38:54 creabox kernel: [ 2.124031] mei_me 0000:00:16.0: setting latency timer to 64 Oct 18 20:38:54 creabox kernel: [ 2.124133] mei_me 0000:00:16.0: irq 45 for MSI/MSI-X Oct 18 20:38:54 creabox kernel: [ 2.128082] ACPI Warning: 0x0000000000000428-0x000000000000042f SystemIO conflicts with Region \PMIO 1 (20130725/utaddress-251) Oct 18 20:38:54 creabox kernel: [ 2.128180] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver Oct 18 20:38:54 creabox kernel: [ 2.128259] ACPI Warning: 0x0000000000000530-0x000000000000053f SystemIO conflicts with Region \GPIO 1 (20130725/utaddress-251) Oct 18 20:38:54 creabox kernel: [ 2.128349] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver Oct 18 20:38:54 creabox kernel: [ 2.128428] ACPI Warning: 0x0000000000000500-0x000000000000052f SystemIO conflicts with Region \GPIO 1 (20130725/utaddress-251) Oct 18 20:38:54 creabox kernel: [ 2.128520] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver Oct 18 20:38:54 creabox kernel: [ 2.128598] lpc_ich: Resource conflict(s) found affecting gpio_ich Oct 18 20:38:54 creabox kernel: [ 2.128690] Loading iSCSI transport class v2.0-870. Oct 18 20:38:54 creabox kernel: [ 2.128926] hv_vmbus: registering driver hv_storvsc Oct 18 20:38:54 creabox kernel: [ 2.129056] ahci 0000:00:1f.2: version 3.0 Oct 18 20:38:54 creabox kernel: [ 2.129263] ahci 0000:00:1f.2: irq 46 for MSI/MSI-X Oct 18 20:38:54 creabox kernel: [ 2.129377] ahci 0000:00:1f.2: AHCI 0001.0300 32 slots 6 ports 6 Gbps 0x1 impl SATA mode Oct 18 20:38:54 creabox kernel: [ 2.129440] ahci 0000:00:1f.2: flags: 64bit ncq pm led clo pio slum part ems apst Oct 18 20:38:54 creabox kernel: [ 2.129502] ahci 0000:00:1f.2: setting latency timer to 64 Oct 18 20:38:54 creabox kernel: [ 2.130267] scsi0 : ahci Oct 18 20:38:54 creabox kernel: [ 2.130526] scsi1 : ahci Oct 18 20:38:54 creabox kernel: [ 2.130698] scsi2 : ahci Oct 18 20:38:54 creabox kernel: [ 2.130850] scsi3 : ahci Oct 18 20:38:54 creabox kernel: [ 2.131013] scsi4 : ahci Oct 18 20:38:54 creabox kernel: [ 2.131158] scsi5 : ahci Oct 18 20:38:54 creabox kernel: [ 2.131235] ata1: SATA max UDMA/133 abar m2048@0xf7d36000 port 0xf7d36100 irq 46 Oct 18 20:38:54 creabox kernel: [ 2.131291] ata2: DUMMY Oct 18 20:38:54 creabox kernel: [ 2.131312] ata3: DUMMY Oct 18 20:38:54 creabox kernel: [ 2.131332] ata4: DUMMY Oct 18 20:38:54 creabox kernel: [ 2.131352] ata5: DUMMY Oct 18 20:38:54 creabox kernel: [ 2.132840] ata6: DUMMY Oct 18 20:38:54 creabox kernel: [ 2.134397] bonding: Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011) Oct 18 20:38:54 creabox kernel: [ 2.136467] eql: Equalizer2002: Simon Janes (simon@ncm.com) and David S. Miller (davem@redhat.com) Oct 18 20:38:54 creabox kernel: [ 2.138646] libphy: Fixed MDIO Bus: probed Oct 18 20:38:54 creabox kernel: [ 2.140374] tun: Universal TUN/TAP device driver, 1.6 Oct 18 20:38:54 creabox kernel: [ 2.142044] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com> Oct 18 20:38:54 creabox kernel: [ 2.143788] e100: Intel(R) PRO/100 Network Driver, 3.5.24-k2-NAPI Oct 18 20:38:54 creabox kernel: [ 2.145515] e100: Copyright(c) 1999-2006 Intel Corporation Oct 18 20:38:54 creabox kernel: [ 2.147322] e1000: Intel(R) PRO/1000 Network Driver - version 7.3.21-k8-NAPI Oct 18 20:38:54 creabox kernel: [ 2.149134] e1000: Copyright (c) 1999-2006 Intel Corporation. Oct 18 20:38:54 creabox kernel: [ 2.150969] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k Oct 18 20:38:54 creabox kernel: [ 2.152816] e1000e: Copyright(c) 1999 - 2013 Intel Corporation. Oct 18 20:38:54 creabox kernel: [ 2.154849] e1000e 0000:00:19.0: setting latency timer to 64 Oct 18 20:38:54 creabox kernel: [ 2.156820] e1000e 0000:00:19.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode Oct 18 20:38:54 creabox kernel: [ 2.158836] e1000e 0000:00:19.0: irq 47 for MSI/MSI-X Oct 18 20:38:54 creabox kernel: [ 2.365213] e1000e 0000:00:19.0 eth0: registered PHC clock Oct 18 20:38:54 creabox kernel: [ 2.367253] e1000e 0000:00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) ec:a8:6b:fa:7b:3c Oct 18 20:38:54 creabox kernel: [ 2.369341] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection Oct 18 20:38:54 creabox kernel: [ 2.371474] e1000e 0000:00:19.0 eth0: MAC: 10, PHY: 11, PBA No: FFFFFF-0FF Oct 18 20:38:54 creabox kernel: [ 2.373614] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.0.5-k Oct 18 20:38:54 creabox kernel: [ 2.375755] igb: Copyright (c) 2007-2013 Intel Corporation. Oct 18 20:38:54 creabox kernel: [ 2.377951] igbvf: Intel(R) Gigabit Virtual Function Network Driver - version 2.0.2-k Oct 18 20:38:54 creabox kernel: [ 2.380180] igbvf: Copyright (c) 2009 - 2012 Intel Corporation. Oct 18 20:38:54 creabox kernel: [ 2.382470] ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver - version 3.15.1-k Oct 18 20:38:54 creabox kernel: [ 2.384746] ixgbe: Copyright (c) 1999-2013 Intel Corporation. Oct 18 20:38:54 creabox kernel: [ 2.387031] ixgbevf: Intel(R) 10 Gigabit PCI Express Virtual Function Network Driver - version 2.7.12-k Oct 18 20:38:54 creabox kernel: [ 2.389338] ixgbevf: Copyright (c) 2009 - 2012 Intel Corporation. Oct 18 20:38:54 creabox kernel: [ 2.391656] ixgb: Intel(R) PRO/10GbE Network Driver - version 1.0.135-k2-NAPI Oct 18 20:38:54 creabox kernel: [ 2.393982] ixgb: Copyright (c) 1999-2008 Intel Corporation. Oct 18 20:38:54 creabox kernel: [ 2.396329] ipw2100: Intel(R) PRO/Wireless 2100 Network Driver, git-1.2.2 Oct 18 20:38:54 creabox kernel: [ 2.398616] ipw2100: Copyright(c) 2003-2006 Intel Corporation Oct 18 20:38:54 creabox kernel: [ 2.400913] ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, 1.2.2kdmprq Oct 18 20:38:54 creabox kernel: [ 2.403214] ipw2200: Copyright(c) 2003-2006 Intel Corporation Oct 18 20:38:54 creabox kernel: [ 2.405560] libipw: 802.11 data/management/control stack, git-1.1.13 Oct 18 20:38:54 creabox kernel: [ 2.407881] libipw: Copyright (C) 2004-2005 Intel Corporation <jketreno@linux.intel.com> Oct 18 20:38:54 creabox kernel: [ 2.410264] Intel(R) Wireless WiFi driver for Linux, in-tree:d Oct 18 20:38:54 creabox kernel: [ 2.412603] Copyright(c) 2003-2013 Intel Corporation Oct 18 20:38:54 creabox kernel: [ 2.415195] iwlwifi 0000:02:00.0: irq 48 for MSI/MSI-X Oct 18 20:38:54 creabox kernel: [ 2.417755] iwlwifi 0000:02:00.0: U iwl_request_firmware attempting to load firmware EXPERIMENTAL 'iwlwifi-6000g2b-exp.ucode' Oct 18 20:38:54 creabox kernel: [ 2.420254] iwl4965: Intel(R) Wireless WiFi 4965 driver for Linux, in-tree:d Oct 18 20:38:54 creabox kernel: [ 2.422654] iwl4965: Copyright(c) 2003-2011 Intel Corporation Oct 18 20:38:54 creabox kernel: [ 2.425038] iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, in-tree:ds Oct 18 20:38:54 creabox kernel: [ 2.427387] iwl3945: Copyright(c) 2003-2011 Intel Corporation Oct 18 20:38:54 creabox kernel: [ 2.429853] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver Oct 18 20:38:54 creabox kernel: [ 2.432150] ehci-pci: EHCI PCI platform driver Oct 18 20:38:54 creabox kernel: [ 2.434584] ehci-pci 0000:00:1a.0: setting latency timer to 64 Oct 18 20:38:54 creabox kernel: [ 2.436832] ehci-pci 0000:00:1a.0: EHCI Host Controller Oct 18 20:38:54 creabox kernel: [ 2.439165] ehci-pci 0000:00:1a.0: new USB bus registered, assigned bus number 1 Oct 18 20:38:54 creabox kernel: [ 2.441424] ehci-pci 0000:00:1a.0: debug port 2 Oct 18 20:38:54 creabox kernel: [ 2.447546] ehci-pci 0000:00:1a.0: cache line size of 64 is not supported Oct 18 20:38:54 creabox kernel: [ 2.449816] ehci-pci 0000:00:1a.0: irq 16, io mem 0xf7d38000 Oct 18 20:38:54 creabox kernel: [ 2.456846] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Oct 18 20:38:54 creabox kernel: [ 2.459841] ata1.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded Oct 18 20:38:54 creabox kernel: [ 2.462107] ata1.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out Oct 18 20:38:54 creabox kernel: [ 2.462148] ehci-pci 0000:00:1a.0: USB 2.0 started, EHCI 1.00 Oct 18 20:38:54 creabox kernel: [ 2.462206] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 Oct 18 20:38:54 creabox kernel: [ 2.462208] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 Oct 18 20:38:54 creabox kernel: [ 2.462209] usb usb1: Product: EHCI Host Controller Oct 18 20:38:54 creabox kernel: [ 2.462211] usb usb1: Manufacturer: Linux 3.12.0-rc5+ ehci_hcd Oct 18 20:38:54 creabox kernel: [ 2.462212] usb usb1: SerialNumber: 0000:00:1a.0 Oct 18 20:38:54 creabox kernel: [ 2.462409] hub 1-0:1.0: USB hub found Oct 18 20:38:54 creabox kernel: [ 2.462417] hub 1-0:1.0: 3 ports detected Oct 18 20:38:54 creabox kernel: [ 2.462746] ehci-pci 0000:00:1d.0: setting latency timer to 64 Oct 18 20:38:54 creabox kernel: [ 2.462753] ehci-pci 0000:00:1d.0: EHCI Host Controller Oct 18 20:38:54 creabox kernel: [ 2.462828] ehci-pci 0000:00:1d.0: new USB bus registered, assigned bus number 2 Oct 18 20:38:54 creabox kernel: [ 2.462845] ehci-pci 0000:00:1d.0: debug port 2 Oct 18 20:38:54 creabox kernel: [ 2.466733] ehci-pci 0000:00:1d.0: cache line size of 64 is not supported Oct 18 20:38:54 creabox kernel: [ 2.466756] ehci-pci 0000:00:1d.0: irq 23, io mem 0xf7d37000 Oct 18 20:38:54 creabox kernel: [ 2.472763] ehci-pci 0000:00:1d.0: USB 2.0 started, EHCI 1.00 Oct 18 20:38:54 creabox kernel: [ 2.472805] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002 Oct 18 20:38:54 creabox kernel: [ 2.472807] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 Oct 18 20:38:54 creabox kernel: [ 2.472808] usb usb2: Product: EHCI Host Controller Oct 18 20:38:54 creabox kernel: [ 2.472810] usb usb2: Manufacturer: Linux 3.12.0-rc5+ ehci_hcd Oct 18 20:38:54 creabox kernel: [ 2.472811] usb usb2: SerialNumber: 0000:00:1d.0 Oct 18 20:38:54 creabox kernel: [ 2.472969] hub 2-0:1.0: USB hub found Oct 18 20:38:54 creabox kernel: [ 2.472977] hub 2-0:1.0: 3 ports detected Oct 18 20:38:54 creabox kernel: [ 2.473157] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver Oct 18 20:38:54 creabox kernel: [ 2.473159] ohci-pci: OHCI PCI platform driver Oct 18 20:38:54 creabox kernel: [ 2.473173] ohci-platform: OHCI generic platform driver Oct 18 20:38:54 creabox kernel: [ 2.473182] uhci_hcd: USB Universal Host Controller Interface driver Oct 18 20:38:54 creabox kernel: [ 2.524793] ata1.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out Oct 18 20:38:54 creabox kernel: [ 2.524932] xhci_hcd 0000:00:14.0: setting latency timer to 64 Oct 18 20:38:54 creabox kernel: [ 2.524936] xhci_hcd 0000:00:14.0: xHCI Host Controller Oct 18 20:38:54 creabox kernel: [ 2.525012] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 3 Oct 18 20:38:54 creabox kernel: [ 2.525119] xhci_hcd 0000:00:14.0: cache line size of 64 is not supported Oct 18 20:38:54 creabox kernel: [ 2.525149] xhci_hcd 0000:00:14.0: irq 49 for MSI/MSI-X Oct 18 20:38:54 creabox kernel: [ 2.525224] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002 Oct 18 20:38:54 creabox kernel: [ 2.525226] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 Oct 18 20:38:54 creabox kernel: [ 2.525227] usb usb3: Product: xHCI Host Controller Oct 18 20:38:54 creabox kernel: [ 2.525229] usb usb3: Manufacturer: Linux 3.12.0-rc5+ xhci_hcd Oct 18 20:38:54 creabox kernel: [ 2.525230] usb usb3: SerialNumber: 0000:00:14.0 Oct 18 20:38:54 creabox kernel: [ 2.525372] hub 3-0:1.0: USB hub found Oct 18 20:38:54 creabox kernel: [ 2.525383] hub 3-0:1.0: 4 ports detected Oct 18 20:38:54 creabox kernel: [ 2.525843] xhci_hcd 0000:00:14.0: xHCI Host Controller Oct 18 20:38:54 creabox kernel: [ 2.525900] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 4 Oct 18 20:38:54 creabox kernel: [ 2.525948] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003 Oct 18 20:38:54 creabox kernel: [ 2.525950] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 Oct 18 20:38:54 creabox kernel: [ 2.525952] usb usb4: Product: xHCI Host Controller Oct 18 20:38:54 creabox kernel: [ 2.525953] usb usb4: Manufacturer: Linux 3.12.0-rc5+ xhci_hcd Oct 18 20:38:54 creabox kernel: [ 2.525954] usb usb4: SerialNumber: 0000:00:14.0 Oct 18 20:38:54 creabox kernel: [ 2.526084] hub 4-0:1.0: USB hub found Oct 18 20:38:54 creabox kernel: [ 2.526095] hub 4-0:1.0: 4 ports detected Oct 18 20:38:54 creabox kernel: [ 2.573313] ata1.00: supports DRM functions and may not be fully accessible Oct 18 20:38:54 creabox kernel: [ 2.578378] ata1.00: ATA-9: Crucial_CT120M500SSD3, MU03, max UDMA/133 Oct 18 20:38:54 creabox kernel: [ 2.580415] ata1.00: 234441648 sectors, multi 16: LBA48 NCQ (depth 31/32), AA Oct 18 20:38:54 creabox kernel: [ 2.586591] ata1.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded Oct 18 20:38:54 creabox kernel: [ 2.588615] ata1.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out Oct 18 20:38:54 creabox kernel: [ 2.588816] i8042: PNP: No PS/2 controller found. Probing ports directly. Oct 18 20:38:54 creabox kernel: [ 2.592630] ata1.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out Oct 18 20:38:54 creabox kernel: [ 2.594911] ata1.00: supports DRM functions and may not be fully accessible Oct 18 20:38:54 creabox kernel: [ 2.603683] ata1.00: configured for UDMA/133 Oct 18 20:38:54 creabox kernel: [ 2.606513] scsi 0:0:0:0: Direct-Access ATA Crucial_CT120M50 MU03 PQ: 0 ANSI: 5 Oct 18 20:38:54 creabox kernel: [ 2.608790] sd 0:0:0:0: Attached scsi generic sg0 type 0 Oct 18 20:38:54 creabox kernel: [ 2.608823] sd 0:0:0:0: [sda] 234441648 512-byte logical blocks: (120 GB/111 GiB) Oct 18 20:38:54 creabox kernel: [ 2.608825] sd 0:0:0:0: [sda] 4096-byte physical blocks Oct 18 20:38:54 creabox kernel: [ 2.608932] sd 0:0:0:0: [sda] Write Protect is off Oct 18 20:38:54 creabox kernel: [ 2.608935] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 Oct 18 20:38:54 creabox kernel: [ 2.608969] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Oct 18 20:38:54 creabox kernel: [ 2.609532] sda: sda1 Oct 18 20:38:54 creabox kernel: [ 2.609906] sd 0:0:0:0: [sda] Attached SCSI disk Oct 18 20:38:54 creabox kernel: [ 3.627952] i8042: No controller found Oct 18 20:38:54 creabox kernel: [ 3.630668] Switched to clocksource tsc Oct 18 20:38:54 creabox kernel: [ 3.630794] mousedev: PS/2 mouse device common for all mice Oct 18 20:38:54 creabox kernel: [ 3.630990] rtc_cmos 00:04: RTC can wake from S4 Oct 18 20:38:54 creabox kernel: [ 3.631140] rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0 Oct 18 20:38:54 creabox kernel: [ 3.631175] rtc_cmos 00:04: alarms up to one month, y3k, 242 bytes nvram, hpet irqs Oct 18 20:38:54 creabox kernel: [ 3.631352] i2c /dev entries driver Oct 18 20:38:54 creabox kernel: [ 3.631870] ACPI Warning: 0x000000000000f040-0x000000000000f05f SystemIO conflicts with Region \_SB_.PCI0.SBUS.SMBI 1 (20130725/utaddress-251) Oct 18 20:38:54 creabox kernel: [ 3.631872] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver Oct 18 20:38:54 creabox kernel: [ 3.631983] pps_ldisc: PPS line discipline registered Oct 18 20:38:54 creabox kernel: [ 3.637109] w83627ehf: Found NCT6776F chip at 0xa30 Oct 18 20:38:54 creabox kernel: [ 3.645223] sp5100_tco: SP5100/SB800 TCO WatchDog Timer Driver v0.05 Oct 18 20:38:54 creabox kernel: [ 3.645270] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.10 Oct 18 20:38:54 creabox kernel: [ 3.645295] iTCO_wdt: Found a Panther Point TCO device (Version=2, TCOBASE=0x0460) Oct 18 20:38:54 creabox kernel: [ 3.645359] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) Oct 18 20:38:54 creabox kernel: [ 3.645365] iTCO_vendor_support: vendor-support=0 Oct 18 20:38:54 creabox kernel: [ 3.645397] softdog: Software Watchdog Timer: 0.08 initialized. soft_noboot=0 soft_margin=60 sec soft_panic=0 (nowayout=0) Oct 18 20:38:54 creabox kernel: [ 3.651811] device-mapper: uevent: version 1.0.3 Oct 18 20:38:54 creabox kernel: [ 3.656306] device-mapper: ioctl: 4.26.0-ioctl (2013-08-15) initialised: dm-devel@redhat.com Oct 18 20:38:54 creabox kernel: [ 3.667598] Intel P-state driver initializing. Oct 18 20:38:54 creabox kernel: [ 3.667608] Intel pstate controlling: cpu 0 Oct 18 20:38:54 creabox kernel: [ 3.667629] Intel pstate controlling: cpu 1 Oct 18 20:38:54 creabox kernel: [ 3.667646] Intel pstate controlling: cpu 2 Oct 18 20:38:54 creabox kernel: [ 3.667660] Intel pstate controlling: cpu 3 Oct 18 20:38:54 creabox kernel: [ 3.667712] leds_ss4200: no LED devices found Oct 18 20:38:54 creabox kernel: [ 3.667729] hidraw: raw HID events driver (C) Jiri Kosina Oct 18 20:38:54 creabox kernel: [ 3.667823] usbcore: registered new interface driver usbhid Oct 18 20:38:54 creabox kernel: [ 3.667823] usbhid: USB HID core driver Oct 18 20:38:54 creabox kernel: [ 3.667827] hv_utils: Registering HyperV Utility Driver Oct 18 20:38:54 creabox kernel: [ 3.667828] hv_vmbus: registering driver hv_util Oct 18 20:38:54 creabox kernel: [ 3.667892] usbcore: registered new interface driver snd-usb-audio Oct 18 20:38:54 creabox kernel: [ 3.667903] usbcore: registered new interface driver snd-ua101 Oct 18 20:38:54 creabox kernel: [ 3.667913] usbcore: registered new interface driver snd-usb-usx2y Oct 18 20:38:54 creabox kernel: [ 3.667923] usbcore: registered new interface driver snd-usb-us122l Oct 18 20:38:54 creabox kernel: [ 3.667933] usbcore: registered new interface driver snd-usb-caiaq Oct 18 20:38:54 creabox kernel: [ 3.667941] usbcore: registered new interface driver snd-usb-6fire Oct 18 20:38:54 creabox kernel: [ 3.667951] usbcore: registered new interface driver snd-usb-hiface Oct 18 20:38:54 creabox kernel: [ 3.669209] drop_monitor: Initializing network drop monitor service Oct 18 20:38:54 creabox kernel: [ 3.669224] GACT probability on Oct 18 20:38:54 creabox kernel: [ 3.669225] Mirror/redirect action on Oct 18 20:38:54 creabox kernel: [ 3.669226] Simple TC action Loaded Oct 18 20:38:54 creabox kernel: [ 3.669307] netem: version 1.3 Oct 18 20:38:54 creabox kernel: [ 3.669308] u32 classifier Oct 18 20:38:54 creabox kernel: [ 3.669309] Performance counters on Oct 18 20:38:54 creabox kernel: [ 3.669309] input device check on Oct 18 20:38:54 creabox kernel: [ 3.669309] Actions configured Oct 18 20:38:54 creabox kernel: [ 3.669312] Netfilter messages via NETLINK v0.30. Oct 18 20:38:54 creabox kernel: [ 3.669314] nfnl_acct: registering with nfnetlink. Oct 18 20:38:54 creabox kernel: [ 3.669323] nf_conntrack version 0.5.0 (16384 buckets, 65536 max) Oct 18 20:38:54 creabox kernel: [ 3.672376] ctnetlink v0.93: registering with nfnetlink. Oct 18 20:38:54 creabox kernel: [ 3.673882] xt_time: kernel timezone is -0000 Oct 18 20:38:54 creabox kernel: [ 3.673884] ip_set: protocol 6 Oct 18 20:38:54 creabox kernel: [ 3.673889] IPVS: Registered protocols (TCP, UDP, SCTP, AH, ESP) Oct 18 20:38:54 creabox kernel: [ 3.675399] IPVS: Connection hash table configured (size=4096, memory=64Kbytes) Oct 18 20:38:54 creabox kernel: [ 3.675428] IPVS: Creating netns size=2048 id=0 Oct 18 20:38:54 creabox kernel: [ 3.675433] IPVS: ipvs loaded. Oct 18 20:38:54 creabox kernel: [ 3.675435] IPVS: [rr] scheduler registered. Oct 18 20:38:54 creabox kernel: [ 3.675435] IPVS: [wrr] scheduler registered. Oct 18 20:38:54 creabox kernel: [ 3.675436] IPVS: [lc] scheduler registered. Oct 18 20:38:54 creabox kernel: [ 3.675436] IPVS: [wlc] scheduler registered. Oct 18 20:38:54 creabox kernel: [ 3.675438] IPVS: [lblc] scheduler registered. Oct 18 20:38:54 creabox kernel: [ 3.675440] IPVS: [lblcr] scheduler registered. Oct 18 20:38:54 creabox kernel: [ 3.675441] IPVS: [dh] scheduler registered. Oct 18 20:38:54 creabox kernel: [ 3.675441] IPVS: [sh] scheduler registered. Oct 18 20:38:54 creabox kernel: [ 3.675442] IPVS: [sed] scheduler registered. Oct 18 20:38:54 creabox kernel: [ 3.675442] IPVS: [nq] scheduler registered. Oct 18 20:38:54 creabox kernel: [ 3.675525] ip_tables: (C) 2000-2006 Netfilter Core Team Oct 18 20:38:54 creabox kernel: [ 3.675558] ipt_CLUSTERIP: ClusterIP Version 0.8 loaded successfully Oct 18 20:38:54 creabox kernel: [ 3.675566] arp_tables: (C) 2002 David S. Miller Oct 18 20:38:54 creabox kernel: [ 3.675575] TCP: cubic registered Oct 18 20:38:54 creabox kernel: [ 3.675576] Initializing XFRM netlink socket Oct 18 20:38:54 creabox kernel: [ 3.675579] NET: Registered protocol family 17 Oct 18 20:38:54 creabox kernel: [ 3.675582] NET: Registered protocol family 15 Oct 18 20:38:54 creabox kernel: [ 3.676917] Bridge firewalling registered Oct 18 20:38:54 creabox kernel: [ 3.676919] Ebtables v2.0 registered Oct 18 20:38:54 creabox kernel: [ 3.684138] usb 1-1: new high-speed USB device number 2 using ehci-pci Oct 18 20:38:54 creabox kernel: [ 3.741573] [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp off Oct 18 20:38:54 creabox kernel: [ 3.756181] NET: Registered protocol family 33 Oct 18 20:38:54 creabox kernel: [ 3.757212] Key type rxrpc registered Oct 18 20:38:54 creabox kernel: [ 3.758214] Key type rxrpc_s registered Oct 18 20:38:54 creabox kernel: [ 3.759209] 8021q: 802.1Q VLAN Support v1.8 Oct 18 20:38:54 creabox kernel: [ 3.760218] lib80211: common routines for IEEE802.11 drivers Oct 18 20:38:54 creabox kernel: [ 3.761169] lib80211_crypt: registered algorithm 'NULL' Oct 18 20:38:54 creabox kernel: [ 3.762109] lib80211_crypt: registered algorithm 'WEP' Oct 18 20:38:54 creabox kernel: [ 3.763030] lib80211_crypt: registered algorithm 'CCMP' Oct 18 20:38:54 creabox kernel: [ 3.763945] lib80211_crypt: registered algorithm 'TKIP' Oct 18 20:38:54 creabox kernel: [ 3.764899] Key type dns_resolver registered Oct 18 20:38:54 creabox kernel: [ 3.766712] registered taskstats version 1 Oct 18 20:38:54 creabox kernel: [ 3.768154] console [netcon0] enabled Oct 18 20:38:54 creabox kernel: [ 3.769154] netconsole: network logging started Oct 18 20:38:54 creabox kernel: [ 3.770200] rtc_cmos 00:04: setting system clock to 2013-10-18 18:38:50 UTC (1382121530) Oct 18 20:38:54 creabox kernel: [ 3.771241] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found Oct 18 20:38:54 creabox kernel: [ 3.772230] EDD information not available. Oct 18 20:38:54 creabox kernel: [ 3.773237] ALSA device list: Oct 18 20:38:54 creabox kernel: [ 3.774188] No soundcards found. Oct 18 20:38:54 creabox kernel: [ 3.776327] Freeing unused kernel memory: 1140K (ffffffff81f1e000 - ffffffff8203b000) Oct 18 20:38:54 creabox kernel: [ 3.777319] Write protecting the kernel read-only data: 14336k Oct 18 20:38:54 creabox kernel: [ 3.780434] Freeing unused kernel memory: 816K (ffff880001934000 - ffff880001a00000) Oct 18 20:38:54 creabox kernel: [ 3.782175] Freeing unused kernel memory: 276K (ffff880001dbb000 - ffff880001e00000) Oct 18 20:38:54 creabox kernel: [ 3.816486] usb 1-1: New USB device found, idVendor=8087, idProduct=0024 Oct 18 20:38:54 creabox kernel: [ 3.818006] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 Oct 18 20:38:54 creabox kernel: [ 3.819778] hub 1-1:1.0: USB hub found Oct 18 20:38:54 creabox kernel: [ 3.821484] hub 1-1:1.0: 6 ports detected Oct 18 20:38:54 creabox kernel: [ 3.853966] iwlwifi 0000:02:00.0: U iwl_request_firmware attempting to load firmware 'iwlwifi-6000g2b-6.ucode' Oct 18 20:38:54 creabox kernel: [ 3.855820] iwlwifi 0000:02:00.0: U iwl_req_fw_callback Loaded firmware file 'iwlwifi-6000g2b-6.ucode' (679436 bytes). Oct 18 20:38:54 creabox kernel: [ 3.857441] iwlwifi 0000:02:00.0: U validate_sec_sizes f/w package hdr runtime inst size = 159932 Oct 18 20:38:54 creabox kernel: [ 3.859056] iwlwifi 0000:02:00.0: U validate_sec_sizes f/w package hdr runtime data size = 81920 Oct 18 20:38:54 creabox kernel: [ 3.860705] iwlwifi 0000:02:00.0: U validate_sec_sizes f/w package hdr init inst size = 130228 Oct 18 20:38:54 creabox kernel: [ 3.862319] iwlwifi 0000:02:00.0: U validate_sec_sizes f/w package hdr init data size = 81920 Oct 18 20:38:54 creabox kernel: [ 3.863826] iwlwifi 0000:02:00.0: loaded firmware version 18.168.6.1 op_mode iwldvm Oct 18 20:38:54 creabox kernel: [ 3.865466] iwlwifi 0000:02:00.0: CONFIG_IWLWIFI_DEBUG enabled Oct 18 20:38:54 creabox kernel: [ 3.867050] iwlwifi 0000:02:00.0: CONFIG_IWLWIFI_DEBUGFS enabled Oct 18 20:38:54 creabox kernel: [ 3.868611] iwlwifi 0000:02:00.0: CONFIG_IWLWIFI_DEVICE_TRACING enabled Oct 18 20:38:54 creabox kernel: [ 3.870066] iwlwifi 0000:02:00.0: U iwl_op_mode_dvm_start *** LOAD DRIVER *** Oct 18 20:38:54 creabox kernel: [ 3.871393] iwlwifi 0000:02:00.0: U iwl_op_mode_dvm_start BT channel inhibition is On Oct 18 20:38:54 creabox kernel: [ 3.872653] iwlwifi 0000:02:00.0: Detected Intel(R) Centrino(R) Advanced-N 6235 AGN, REV=0xB0 Oct 18 20:38:54 creabox kernel: [ 3.874020] iwlwifi 0000:02:00.0: U iwl_pcie_prepare_card_hw iwl_trans_prepare_card_hw enter Oct 18 20:38:54 creabox kernel: [ 3.875379] iwlwifi 0000:02:00.0: U iwl_pcie_set_hw_ready hardware ready Oct 18 20:38:54 creabox kernel: [ 3.876666] iwlwifi 0000:02:00.0: U iwl_pcie_apm_init Init card's basic functions Oct 18 20:38:54 creabox kernel: [ 3.877899] iwlwifi 0000:02:00.0: L1 Disabled; Enabling L0S Oct 18 20:38:54 creabox kernel: [ 3.885782] iwlwifi 0000:02:00.0: U iwl_read_eeprom NVM size = 2048 Oct 18 20:38:54 creabox kernel: [ 3.886942] iwlwifi 0000:02:00.0: U iwl_eeprom_verify_signature EEPROM signature=0x00000001 Oct 18 20:38:54 creabox kernel: [ 3.888150] iwlwifi 0000:02:00.0: U iwl_eeprom_acquire_semaphore Acquired semaphore after 1 tries. Oct 18 20:38:54 creabox kernel: [ 3.900344] iwlwifi 0000:02:00.0: U iwl_read_eeprom NVM Type: OTP Oct 18 20:38:54 creabox kernel: [ 3.901644] iwlwifi 0000:02:00.0: U iwl_pcie_apm_stop Stop card, put in low power state Oct 18 20:38:54 creabox kernel: [ 3.902837] iwlwifi 0000:02:00.0: U iwl_pcie_apm_stop_master stop master Oct 18 20:38:54 creabox kernel: [ 3.904091] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 1 [2.4GHz] VALID IBSS ACTIVE WIDE (0x6f 0dBm): Ad-Hoc supported Oct 18 20:38:54 creabox kernel: [ 3.905331] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 2 [2.4GHz] VALID IBSS ACTIVE WIDE (0x6f 0dBm): Ad-Hoc supported Oct 18 20:38:54 creabox kernel: [ 3.906554] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 3 [2.4GHz] VALID IBSS ACTIVE WIDE (0x6f 0dBm): Ad-Hoc supported Oct 18 20:38:54 creabox kernel: [ 3.907771] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 4 [2.4GHz] VALID IBSS ACTIVE WIDE (0x6f 0dBm): Ad-Hoc supported Oct 18 20:38:54 creabox kernel: [ 3.908968] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 5 [2.4GHz] VALID IBSS ACTIVE WIDE (0x6f 0dBm): Ad-Hoc supported Oct 18 20:38:54 creabox kernel: [ 3.910148] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 6 [2.4GHz] VALID IBSS ACTIVE WIDE (0x6f 0dBm): Ad-Hoc supported Oct 18 20:38:54 creabox kernel: [ 3.911314] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 7 [2.4GHz] VALID IBSS ACTIVE WIDE (0x6f 0dBm): Ad-Hoc supported Oct 18 20:38:54 creabox kernel: [ 3.912473] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 8 [2.4GHz] VALID IBSS ACTIVE WIDE (0x6f 0dBm): Ad-Hoc supported Oct 18 20:38:54 creabox kernel: [ 3.913645] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 9 [2.4GHz] VALID IBSS ACTIVE WIDE (0x6f 0dBm): Ad-Hoc supported Oct 18 20:38:54 creabox kernel: [ 3.914796] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 10 [2.4GHz] VALID IBSS ACTIVE WIDE (0x6f 0dBm): Ad-Hoc supported Oct 18 20:38:54 creabox kernel: [ 3.915955] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 11 [2.4GHz] VALID IBSS ACTIVE WIDE (0x6f 0dBm): Ad-Hoc supported Oct 18 20:38:54 creabox kernel: [ 3.917133] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 12 [2.4GHz] VALID WIDE (0x61 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 3.918279] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 13 [2.4GHz] VALID WIDE (0x61 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 3.919405] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 14 Flags 0 [2.4GHz] - No traffic Oct 18 20:38:54 creabox kernel: [ 3.920546] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 183 Flags 0 [5.2GHz] - No traffic Oct 18 20:38:54 creabox kernel: [ 3.921684] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 184 Flags 0 [5.2GHz] - No traffic Oct 18 20:38:54 creabox kernel: [ 3.922799] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 185 Flags 0 [5.2GHz] - No traffic Oct 18 20:38:54 creabox kernel: [ 3.923902] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 187 Flags 0 [5.2GHz] - No traffic Oct 18 20:38:54 creabox kernel: [ 3.925017] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 188 Flags 0 [5.2GHz] - No traffic Oct 18 20:38:54 creabox kernel: [ 3.926114] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 189 Flags 0 [5.2GHz] - No traffic Oct 18 20:38:54 creabox kernel: [ 3.927195] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 192 Flags 0 [5.2GHz] - No traffic Oct 18 20:38:54 creabox kernel: [ 3.928302] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 196 Flags 0 [5.2GHz] - No traffic Oct 18 20:38:54 creabox kernel: [ 3.929400] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 7 Flags 0 [5.2GHz] - No traffic Oct 18 20:38:54 creabox kernel: [ 3.930475] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 8 Flags 0 [5.2GHz] - No traffic Oct 18 20:38:54 creabox kernel: [ 3.931542] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 11 Flags 0 [5.2GHz] - No traffic Oct 18 20:38:54 creabox kernel: [ 3.932634] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 12 Flags 0 [5.2GHz] - No traffic Oct 18 20:38:54 creabox kernel: [ 3.933709] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 16 Flags 0 [5.2GHz] - No traffic Oct 18 20:38:54 creabox kernel: [ 3.934762] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 34 Flags 0 [5.2GHz] - No traffic Oct 18 20:38:54 creabox kernel: [ 3.935771] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 36 [5.2GHz] VALID WIDE DFS (0xe1 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 3.936010] usb 2-1: new high-speed USB device number 2 using ehci-pci Oct 18 20:38:54 creabox kernel: [ 3.937874] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 38 Flags 0 [5.2GHz] - No traffic Oct 18 20:38:54 creabox kernel: [ 3.938951] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 40 [5.2GHz] VALID WIDE DFS (0xe1 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 3.940033] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 42 Flags 0 [5.2GHz] - No traffic Oct 18 20:38:54 creabox kernel: [ 3.941099] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 44 [5.2GHz] VALID WIDE DFS (0xe1 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 3.942151] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 46 Flags 0 [5.2GHz] - No traffic Oct 18 20:38:54 creabox kernel: [ 3.943213] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 48 [5.2GHz] VALID WIDE DFS (0xe1 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 3.944300] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 52 [5.2GHz] VALID RADAR WIDE (0x31 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 3.945390] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 56 [5.2GHz] VALID RADAR WIDE (0x31 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 3.946435] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 60 [5.2GHz] VALID RADAR WIDE (0x31 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 3.947470] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 64 [5.2GHz] VALID RADAR WIDE (0x31 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 3.948522] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 100 [5.2GHz] VALID RADAR WIDE (0x31 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 3.949576] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 104 [5.2GHz] VALID RADAR WIDE (0x31 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 3.950580] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 108 [5.2GHz] VALID RADAR WIDE (0x31 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 3.951560] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 112 [5.2GHz] VALID RADAR WIDE (0x31 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 3.952540] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 116 [5.2GHz] VALID RADAR WIDE (0x31 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 3.953512] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 120 [5.2GHz] VALID RADAR WIDE (0x31 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 3.954463] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 124 [5.2GHz] VALID RADAR WIDE (0x31 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 3.955408] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 128 [5.2GHz] VALID RADAR WIDE (0x31 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 3.956360] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 132 [5.2GHz] VALID RADAR WIDE (0x31 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 3.957296] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 136 [5.2GHz] VALID RADAR WIDE (0x31 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 3.958206] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 140 [5.2GHz] VALID RADAR WIDE (0x31 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 3.959110] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 145 Flags 0 [5.2GHz] - No traffic Oct 18 20:38:54 creabox kernel: [ 3.960034] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 149 [5.2GHz] VALID WIDE DFS (0xe1 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 3.960978] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 153 [5.2GHz] VALID WIDE DFS (0xe1 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 3.961882] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 157 [5.2GHz] VALID WIDE DFS (0xe1 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 3.962764] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 161 [5.2GHz] VALID WIDE DFS (0xe1 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 3.963637] iwlwifi 0000:02:00.0: U iwl_init_channel_map Ch. 165 [5.2GHz] VALID WIDE DFS (0xe1 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 3.964521] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Common 0: VALID (0x01) Oct 18 20:38:54 creabox kernel: [ 3.965400] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x1d chain_B: 0X1c chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 3.966273] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x00 MIMO3: 0x00 High 20_on_40: 0x00 Low 20_on_40: 0x00 Oct 18 20:38:54 creabox kernel: [ 3.967156] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Common 0: VALID 40MHZ (0x09) Oct 18 20:38:54 creabox kernel: [ 3.968056] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x1d chain_B: 0X1c chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 3.968955] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x00 MIMO3: 0x00 High 20_on_40: 0x00 Low 20_on_40: 0x00 Oct 18 20:38:54 creabox kernel: [ 3.969845] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Common 0: VALID OFDM (0x05) Oct 18 20:38:54 creabox kernel: [ 3.970730] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x1e chain_B: 0X1e chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 3.971605] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x00 MIMO3: 0x00 High 20_on_40: 0x00 Low 20_on_40: 0x00 Oct 18 20:38:54 creabox kernel: [ 3.972529] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Common 0: VALID OFDM HT_AP (0x15) Oct 18 20:38:54 creabox kernel: [ 3.973464] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x1e chain_B: 0X1e chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 3.974391] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x18 MIMO3: 0x00 High 20_on_40: 0x00 Low 20_on_40: 0x00 Oct 18 20:38:54 creabox kernel: [ 3.975346] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Common 0: VALID OFDM 40MHZ HT_AP (0x1d) Oct 18 20:38:54 creabox kernel: [ 3.976341] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x18 chain_B: 0X16 chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 3.977349] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x16 MIMO3: 0x00 High 20_on_40: 0x04 Low 20_on_40: 0x04 Oct 18 20:38:54 creabox kernel: [ 3.978360] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Common 0: VALID BAND_52G OFDM (0x07) Oct 18 20:38:54 creabox kernel: [ 3.979381] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x1d chain_B: 0X1d chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 3.980424] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x00 MIMO3: 0x00 High 20_on_40: 0x00 Low 20_on_40: 0x00 Oct 18 20:38:54 creabox kernel: [ 3.981491] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Common 0: VALID BAND_52G OFDM HT_AP (0x17) Oct 18 20:38:54 creabox kernel: [ 3.982534] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x1d chain_B: 0X1d chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 3.983595] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x17 MIMO3: 0x00 High 20_on_40: 0x00 Low 20_on_40: 0x00 Oct 18 20:38:54 creabox kernel: [ 3.984686] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Common 0: VALID BAND_52G OFDM 40MHZ HT_AP (0x1f) Oct 18 20:38:54 creabox kernel: [ 3.985782] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x1d chain_B: 0X1d chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 3.986872] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x18 MIMO3: 0x00 High 20_on_40: 0x00 Low 20_on_40: 0x00 Oct 18 20:38:54 creabox kernel: [ 3.988012] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Common 60: VALID BAND_52G OFDM COMMON_TYPE (0x87) Oct 18 20:38:54 creabox kernel: [ 3.989162] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x1d chain_B: 0X1d chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 3.990306] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x00 MIMO3: 0x00 High 20_on_40: 0x00 Low 20_on_40: 0x00 Oct 18 20:38:54 creabox kernel: [ 3.991473] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Common 60: VALID BAND_52G OFDM HT_AP COMMON_TYPE (0x97) Oct 18 20:38:54 creabox kernel: [ 3.992699] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x1d chain_B: 0X1d chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 3.993918] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x18 MIMO3: 0x00 High 20_on_40: 0x00 Low 20_on_40: 0x00 Oct 18 20:38:54 creabox kernel: [ 3.995131] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Common 102: VALID BAND_52G OFDM 40MHZ HT_AP COMMON_TYPE (0x9f) Oct 18 20:38:54 creabox kernel: [ 3.996391] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x1d chain_B: 0X1d chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 3.997648] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x18 MIMO3: 0x00 High 20_on_40: 0x00 Low 20_on_40: 0x00 Oct 18 20:38:54 creabox kernel: [ 3.998911] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Common 120: VALID BAND_52G OFDM COMMON_TYPE (0x87) Oct 18 20:38:54 creabox kernel: [ 4.000210] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x1d chain_B: 0X1d chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 4.001523] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x00 MIMO3: 0x00 High 20_on_40: 0x00 Low 20_on_40: 0x00 Oct 18 20:38:54 creabox kernel: [ 4.002824] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Common 120: VALID BAND_52G OFDM HT_AP COMMON_TYPE (0x97) Oct 18 20:38:54 creabox kernel: [ 4.004145] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x1d chain_B: 0X1d chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 4.005436] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x18 MIMO3: 0x00 High 20_on_40: 0x00 Low 20_on_40: 0x00 Oct 18 20:38:54 creabox kernel: [ 4.006733] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Common 140: VALID BAND_52G OFDM COMMON_TYPE (0x87) Oct 18 20:38:54 creabox kernel: [ 4.008030] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x1d chain_B: 0X1d chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 4.009320] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x00 MIMO3: 0x00 High 20_on_40: 0x00 Low 20_on_40: 0x00 Oct 18 20:38:54 creabox kernel: [ 4.010597] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Common 136: VALID BAND_52G OFDM HT_AP COMMON_TYPE (0x97) Oct 18 20:38:54 creabox kernel: [ 4.011874] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x1d chain_B: 0X1d chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 4.013174] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x17 MIMO3: 0x00 High 20_on_40: 0x00 Low 20_on_40: 0x00 Oct 18 20:38:54 creabox kernel: [ 4.014497] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Channel 1: VALID (0x01) Oct 18 20:38:54 creabox kernel: [ 4.015808] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x1c chain_B: 0X1c chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 4.017157] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x00 MIMO3: 0x00 High 20_on_40: 0x00 Low 20_on_40: 0x00 Oct 18 20:38:54 creabox kernel: [ 4.018512] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Channel 1: VALID OFDM (0x05) Oct 18 20:38:54 creabox kernel: [ 4.019853] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x19 chain_B: 0X18 chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 4.021236] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x00 MIMO3: 0x00 High 20_on_40: 0x00 Low 20_on_40: 0x00 Oct 18 20:38:54 creabox kernel: [ 4.022642] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Channel 1: VALID OFDM HT_AP (0x15) Oct 18 20:38:54 creabox kernel: [ 4.024061] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x17 chain_B: 0X16 chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 4.025492] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x16 MIMO3: 0x00 High 20_on_40: 0x00 Low 20_on_40: 0x00 Oct 18 20:38:54 creabox kernel: [ 4.026930] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Channel 2: VALID OFDM (0x05) Oct 18 20:38:54 creabox kernel: [ 4.028398] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x1e chain_B: 0X1e chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 4.029880] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x00 MIMO3: 0x00 High 20_on_40: 0x00 Low 20_on_40: 0x00 Oct 18 20:38:54 creabox kernel: [ 4.031364] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Channel 2: VALID OFDM HT_AP (0x15) Oct 18 20:38:54 creabox kernel: [ 4.032887] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x1e chain_B: 0X1e chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 4.034402] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x18 MIMO3: 0x00 High 20_on_40: 0x00 Low 20_on_40: 0x00 Oct 18 20:38:54 creabox kernel: [ 4.035912] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Channel 10: VALID OFDM (0x05) Oct 18 20:38:54 creabox kernel: [ 4.037432] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x1e chain_B: 0X1e chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 4.038981] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x00 MIMO3: 0x00 High 20_on_40: 0x00 Low 20_on_40: 0x00 Oct 18 20:38:54 creabox kernel: [ 4.040556] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Channel 10: VALID OFDM HT_AP (0x15) Oct 18 20:38:54 creabox kernel: [ 4.042136] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x1e chain_B: 0X1e chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 4.043687] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x18 MIMO3: 0x00 High 20_on_40: 0x00 Low 20_on_40: 0x00 Oct 18 20:38:54 creabox kernel: [ 4.045278] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Channel 11: VALID OFDM (0x05) Oct 18 20:38:54 creabox kernel: [ 4.046850] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x19 chain_B: 0X18 chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 4.048427] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x00 MIMO3: 0x00 High 20_on_40: 0x00 Low 20_on_40: 0x00 Oct 18 20:38:54 creabox kernel: [ 4.050013] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Channel 11: VALID OFDM HT_AP (0x15) Oct 18 20:38:54 creabox kernel: [ 4.051564] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x16 chain_B: 0X16 chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 4.053166] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x14 MIMO3: 0x00 High 20_on_40: 0x00 Low 20_on_40: 0x00 Oct 18 20:38:54 creabox kernel: [ 4.054750] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Channel 13: VALID (0x01) Oct 18 20:38:54 creabox kernel: [ 4.056326] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x1c chain_B: 0X1c chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 4.057899] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x00 MIMO3: 0x00 High 20_on_40: 0x00 Low 20_on_40: 0x00 Oct 18 20:38:54 creabox kernel: [ 4.059469] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Channel 13: VALID OFDM (0x05) Oct 18 20:38:54 creabox kernel: [ 4.061048] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x1a chain_B: 0X1a chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 4.062623] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x00 MIMO3: 0x00 High 20_on_40: 0x00 Low 20_on_40: 0x00 Oct 18 20:38:54 creabox kernel: [ 4.064207] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Channel 13: VALID OFDM HT_AP (0x15) Oct 18 20:38:54 creabox kernel: [ 4.065781] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x1a chain_B: 0X1a chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 4.067329] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x17 MIMO3: 0x00 High 20_on_40: 0x00 Low 20_on_40: 0x00 Oct 18 20:38:54 creabox kernel: [ 4.068925] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Channel 3: VALID OFDM 40MHZ HT_AP (0x1d) Oct 18 20:38:54 creabox kernel: [ 4.070489] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x10 chain_B: 0X0f chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 4.072085] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x0c MIMO3: 0x00 High 20_on_40: 0x0c Low 20_on_40: 0x06 Oct 18 20:38:54 creabox kernel: [ 4.072247] usb 2-1: New USB device found, idVendor=8087, idProduct=0024 Oct 18 20:38:54 creabox kernel: [ 4.072249] usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 Oct 18 20:38:54 creabox kernel: [ 4.072528] hub 2-1:1.0: USB hub found Oct 18 20:38:54 creabox kernel: [ 4.072625] hub 2-1:1.0: 8 ports detected Oct 18 20:38:54 creabox kernel: [ 4.080594] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Channel 4: VALID OFDM 40MHZ HT_AP (0x1d) Oct 18 20:38:54 creabox kernel: [ 4.082269] microcode: CPU0 sig=0x306a9, pf=0x10, revision=0x17 Oct 18 20:38:54 creabox kernel: [ 4.084536] microcode: CPU0 updated to revision 0x19, date = 2013-06-13 Oct 18 20:38:54 creabox kernel: [ 4.086210] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x12 chain_B: 0X10 chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 4.086224] microcode: CPU1 sig=0x306a9, pf=0x10, revision=0x17 Oct 18 20:38:54 creabox kernel: [ 4.086550] microcode: CPU1 updated to revision 0x19, date = 2013-06-13 Oct 18 20:38:54 creabox kernel: [ 4.086572] microcode: CPU2 sig=0x306a9, pf=0x10, revision=0x17 Oct 18 20:38:54 creabox kernel: [ 4.086909] microcode: CPU2 updated to revision 0x19, date = 2013-06-13 Oct 18 20:38:54 creabox kernel: [ 4.086927] microcode: CPU3 sig=0x306a9, pf=0x10, revision=0x17 Oct 18 20:38:54 creabox kernel: [ 4.087261] microcode: CPU3 updated to revision 0x19, date = 2013-06-13 Oct 18 20:38:54 creabox kernel: [ 4.098426] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x10 MIMO3: 0x00 High 20_on_40: 0x0a Low 20_on_40: 0x06 Oct 18 20:38:54 creabox kernel: [ 4.100215] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Channel 5: VALID OFDM 40MHZ HT_AP (0x1d) Oct 18 20:38:54 creabox kernel: [ 4.101918] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x16 chain_B: 0X15 chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 4.103606] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x14 MIMO3: 0x00 High 20_on_40: 0x08 Low 20_on_40: 0x06 Oct 18 20:38:54 creabox kernel: [ 4.105305] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Channel 7: VALID OFDM 40MHZ HT_AP (0x1d) Oct 18 20:38:54 creabox kernel: [ 4.106893] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x14 chain_B: 0X14 chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 4.108482] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x12 MIMO3: 0x00 High 20_on_40: 0x06 Low 20_on_40: 0x08 Oct 18 20:38:54 creabox kernel: [ 4.110087] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Channel 8: VALID OFDM 40MHZ HT_AP (0x1d) Oct 18 20:38:54 creabox kernel: [ 4.111665] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x13 chain_B: 0X11 chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 4.113253] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x0f MIMO3: 0x00 High 20_on_40: 0x06 Low 20_on_40: 0x0a Oct 18 20:38:54 creabox kernel: [ 4.114850] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Channel 9: VALID OFDM 40MHZ HT_AP (0x1d) Oct 18 20:38:54 creabox kernel: [ 4.116444] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x11 chain_B: 0X0f chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 4.118028] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x0d MIMO3: 0x00 High 20_on_40: 0x06 Low 20_on_40: 0x0c Oct 18 20:38:54 creabox kernel: [ 4.119607] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Channel 10: VALID OFDM 40MHZ HT_AP (0x1d) Oct 18 20:38:54 creabox kernel: [ 4.121199] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x1a chain_B: 0X18 chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 4.122783] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x17 MIMO3: 0x00 High 20_on_40: 0x00 Low 20_on_40: 0x04 Oct 18 20:38:54 creabox kernel: [ 4.124399] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Channel 11: VALID OFDM 40MHZ HT_AP (0x1d) Oct 18 20:38:54 creabox kernel: [ 4.125978] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x18 chain_B: 0X17 chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 4.127540] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x16 MIMO3: 0x00 High 20_on_40: 0x00 Low 20_on_40: 0x00 Oct 18 20:38:54 creabox kernel: [ 4.129139] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Channel 36: VALID BAND_52G OFDM (0x07) Oct 18 20:38:54 creabox kernel: [ 4.130730] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x1a chain_B: 0X1c chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 4.132320] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x00 MIMO3: 0x00 High 20_on_40: 0x00 Low 20_on_40: 0x00 Oct 18 20:38:54 creabox kernel: [ 4.133916] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Channel 36: VALID BAND_52G OFDM HT_AP (0x17) Oct 18 20:38:54 creabox kernel: [ 4.135485] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x19 chain_B: 0X1b chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 4.137071] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x17 MIMO3: 0x00 High 20_on_40: 0x00 Low 20_on_40: 0x00 Oct 18 20:38:54 creabox kernel: [ 4.138667] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Channel 64: VALID BAND_52G OFDM (0x07) Oct 18 20:38:54 creabox kernel: [ 4.140263] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x1d chain_B: 0X1d chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 4.141849] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x00 MIMO3: 0x00 High 20_on_40: 0x00 Low 20_on_40: 0x00 Oct 18 20:38:54 creabox kernel: [ 4.143427] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Channel 64: VALID BAND_52G OFDM HT_AP (0x17) Oct 18 20:38:54 creabox kernel: [ 4.145024] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x1c chain_B: 0X1c chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 4.146725] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x18 MIMO3: 0x00 High 20_on_40: 0x00 Low 20_on_40: 0x00 Oct 18 20:38:54 creabox kernel: [ 4.148332] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Channel 100: VALID BAND_52G OFDM (0x07) Oct 18 20:38:54 creabox kernel: [ 4.149929] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x1d chain_B: 0X1d chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 4.151499] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x00 MIMO3: 0x00 High 20_on_40: 0x00 Low 20_on_40: 0x00 Oct 18 20:38:54 creabox kernel: [ 4.153101] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Channel 100: VALID BAND_52G OFDM HT_AP (0x17) Oct 18 20:38:54 creabox kernel: [ 4.154699] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x1d chain_B: 0X1d chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 4.156302] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x18 MIMO3: 0x00 High 20_on_40: 0x00 Low 20_on_40: 0x00 Oct 18 20:38:54 creabox kernel: [ 4.157905] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Channel 140: VALID BAND_52G OFDM (0x07) Oct 18 20:38:54 creabox kernel: [ 4.159478] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x1d chain_B: 0X1d chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 4.161071] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x00 MIMO3: 0x00 High 20_on_40: 0x00 Low 20_on_40: 0x00 Oct 18 20:38:54 creabox kernel: [ 4.162673] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Channel 140: VALID BAND_52G OFDM HT_AP (0x17) Oct 18 20:38:54 creabox kernel: [ 4.164272] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x1d chain_B: 0X1d chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 4.165866] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x18 MIMO3: 0x00 High 20_on_40: 0x00 Low 20_on_40: 0x00 Oct 18 20:38:54 creabox kernel: [ 4.167452] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Channel 38: VALID BAND_52G OFDM 40MHZ HT_AP (0x1f) Oct 18 20:38:54 creabox kernel: [ 4.169058] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x14 chain_B: 0X14 chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 4.170656] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x10 MIMO3: 0x00 High 20_on_40: 0x0a Low 20_on_40: 0x08 Oct 18 20:38:54 creabox kernel: [ 4.172366] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Channel 46: VALID BAND_52G OFDM 40MHZ HT_AP (0x1f) Oct 18 20:38:54 creabox kernel: [ 4.174129] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x1c chain_B: 0X1c chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 4.175825] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x18 MIMO3: 0x00 High 20_on_40: 0x00 Low 20_on_40: 0x00 Oct 18 20:38:54 creabox kernel: [ 4.177537] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Channel 62: VALID BAND_52G OFDM 40MHZ HT_AP (0x1f) Oct 18 20:38:54 creabox kernel: [ 4.179238] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x14 chain_B: 0X15 chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 4.180946] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x11 MIMO3: 0x00 High 20_on_40: 0x08 Low 20_on_40: 0x0a Oct 18 20:38:54 creabox kernel: [ 4.182636] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower Channel 102: VALID BAND_52G OFDM 40MHZ HT_AP (0x1f) Oct 18 20:38:54 creabox kernel: [ 4.184352] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower chain_A: 0x1a chain_B: 0X1a chain_C: 0X00 Oct 18 20:38:54 creabox kernel: [ 4.186057] iwlwifi 0000:02:00.0: U iwl_eeprom_enhanced_txpower MIMO2: 0x16 MIMO3: 0x00 High 20_on_40: 0x00 Low 20_on_40: 0x00 Oct 18 20:38:54 creabox kernel: [ 4.187757] iwlwifi 0000:02:00.0: U iwl_mod_ht40_chan_info HT40 Ch. 1 [2.4GHz] IBSS ACTIVE WIDE (0x6f 0dBm): Ad-Hoc supported Oct 18 20:38:54 creabox kernel: [ 4.189456] iwlwifi 0000:02:00.0: U iwl_mod_ht40_chan_info HT40 Ch. 5 [2.4GHz] IBSS ACTIVE WIDE (0x6f 0dBm): Ad-Hoc supported Oct 18 20:38:54 creabox kernel: [ 4.191137] iwlwifi 0000:02:00.0: U iwl_mod_ht40_chan_info HT40 Ch. 2 [2.4GHz] IBSS ACTIVE WIDE (0x6f 0dBm): Ad-Hoc supported Oct 18 20:38:54 creabox kernel: [ 4.192783] iwlwifi 0000:02:00.0: U iwl_mod_ht40_chan_info HT40 Ch. 6 [2.4GHz] IBSS ACTIVE WIDE (0x6f 0dBm): Ad-Hoc supported Oct 18 20:38:54 creabox kernel: [ 4.194395] iwlwifi 0000:02:00.0: U iwl_mod_ht40_chan_info HT40 Ch. 3 [2.4GHz] IBSS ACTIVE WIDE (0x6f 0dBm): Ad-Hoc supported Oct 18 20:38:54 creabox kernel: [ 4.195996] iwlwifi 0000:02:00.0: U iwl_mod_ht40_chan_info HT40 Ch. 7 [2.4GHz] IBSS ACTIVE WIDE (0x6f 0dBm): Ad-Hoc supported Oct 18 20:38:54 creabox kernel: [ 4.197580] iwlwifi 0000:02:00.0: U iwl_mod_ht40_chan_info HT40 Ch. 4 [2.4GHz] IBSS ACTIVE WIDE (0x6f 0dBm): Ad-Hoc supported Oct 18 20:38:54 creabox kernel: [ 4.199153] iwlwifi 0000:02:00.0: U iwl_mod_ht40_chan_info HT40 Ch. 8 [2.4GHz] IBSS ACTIVE WIDE (0x6f 0dBm): Ad-Hoc supported Oct 18 20:38:54 creabox kernel: [ 4.200711] iwlwifi 0000:02:00.0: U iwl_mod_ht40_chan_info HT40 Ch. 5 [2.4GHz] IBSS ACTIVE WIDE (0x6f 0dBm): Ad-Hoc supported Oct 18 20:38:54 creabox kernel: [ 4.202251] iwlwifi 0000:02:00.0: U iwl_mod_ht40_chan_info HT40 Ch. 9 [2.4GHz] IBSS ACTIVE WIDE (0x6f 0dBm): Ad-Hoc supported Oct 18 20:38:54 creabox kernel: [ 4.203749] iwlwifi 0000:02:00.0: U iwl_mod_ht40_chan_info HT40 Ch. 6 [2.4GHz] IBSS ACTIVE WIDE (0x6f 0dBm): Ad-Hoc supported Oct 18 20:38:54 creabox kernel: [ 4.205150] iwlwifi 0000:02:00.0: U iwl_mod_ht40_chan_info HT40 Ch. 10 [2.4GHz] IBSS ACTIVE WIDE (0x6f 0dBm): Ad-Hoc supported Oct 18 20:38:54 creabox kernel: [ 4.206552] iwlwifi 0000:02:00.0: U iwl_mod_ht40_chan_info HT40 Ch. 7 [2.4GHz] IBSS ACTIVE WIDE (0x6f 0dBm): Ad-Hoc supported Oct 18 20:38:54 creabox kernel: [ 4.207958] iwlwifi 0000:02:00.0: U iwl_mod_ht40_chan_info HT40 Ch. 11 [2.4GHz] IBSS ACTIVE WIDE (0x6f 0dBm): Ad-Hoc supported Oct 18 20:38:54 creabox kernel: [ 4.209361] iwlwifi 0000:02:00.0: U iwl_mod_ht40_chan_info HT40 Ch. 36 [5.2GHz] WIDE DFS (0xe1 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 4.210748] iwlwifi 0000:02:00.0: U iwl_mod_ht40_chan_info HT40 Ch. 40 [5.2GHz] WIDE DFS (0xe1 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 4.212151] iwlwifi 0000:02:00.0: U iwl_mod_ht40_chan_info HT40 Ch. 44 [5.2GHz] WIDE DFS (0xe1 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 4.213513] iwlwifi 0000:02:00.0: U iwl_mod_ht40_chan_info HT40 Ch. 48 [5.2GHz] WIDE DFS (0xe1 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 4.214842] iwlwifi 0000:02:00.0: U iwl_mod_ht40_chan_info HT40 Ch. 52 [5.2GHz] RADAR WIDE (0x31 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 4.216199] iwlwifi 0000:02:00.0: U iwl_mod_ht40_chan_info HT40 Ch. 56 [5.2GHz] RADAR WIDE (0x31 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 4.217532] iwlwifi 0000:02:00.0: U iwl_mod_ht40_chan_info HT40 Ch. 60 [5.2GHz] RADAR WIDE (0x31 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 4.218830] iwlwifi 0000:02:00.0: U iwl_mod_ht40_chan_info HT40 Ch. 64 [5.2GHz] RADAR WIDE (0x31 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 4.220136] iwlwifi 0000:02:00.0: U iwl_mod_ht40_chan_info HT40 Ch. 100 [5.2GHz] RADAR WIDE (0x31 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 4.221434] iwlwifi 0000:02:00.0: U iwl_mod_ht40_chan_info HT40 Ch. 104 [5.2GHz] RADAR WIDE (0x31 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 4.222701] iwlwifi 0000:02:00.0: U iwl_mod_ht40_chan_info HT40 Ch. 108 [5.2GHz] RADAR WIDE (0x31 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 4.223968] iwlwifi 0000:02:00.0: U iwl_mod_ht40_chan_info HT40 Ch. 112 [5.2GHz] RADAR WIDE (0x31 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 4.225215] iwlwifi 0000:02:00.0: U iwl_mod_ht40_chan_info HT40 Ch. 116 [5.2GHz] RADAR WIDE (0x31 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 4.226428] iwlwifi 0000:02:00.0: U iwl_mod_ht40_chan_info HT40 Ch. 120 [5.2GHz] RADAR WIDE (0x31 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 4.227623] iwlwifi 0000:02:00.0: U iwl_mod_ht40_chan_info HT40 Ch. 124 [5.2GHz] RADAR WIDE (0x31 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 4.228822] iwlwifi 0000:02:00.0: U iwl_mod_ht40_chan_info HT40 Ch. 128 [5.2GHz] RADAR WIDE (0x31 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 4.230005] iwlwifi 0000:02:00.0: U iwl_mod_ht40_chan_info HT40 Ch. 132 [5.2GHz] RADAR WIDE (0x31 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 4.231147] iwlwifi 0000:02:00.0: U iwl_mod_ht40_chan_info HT40 Ch. 136 [5.2GHz] RADAR WIDE (0x31 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 4.232293] iwlwifi 0000:02:00.0: U iwl_mod_ht40_chan_info HT40 Ch. 149 [5.2GHz] WIDE (0x61 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 4.233431] iwlwifi 0000:02:00.0: U iwl_mod_ht40_chan_info HT40 Ch. 153 [5.2GHz] WIDE (0x61 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 4.234533] iwlwifi 0000:02:00.0: U iwl_mod_ht40_chan_info HT40 Ch. 157 [5.2GHz] WIDE (0x61 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 4.235617] iwlwifi 0000:02:00.0: U iwl_mod_ht40_chan_info HT40 Ch. 161 [5.2GHz] WIDE (0x61 0dBm): Ad-Hoc not supported Oct 18 20:38:54 creabox kernel: [ 4.236713] iwlwifi 0000:02:00.0: U iwl_nvm_check_version device EEPROM VER=0x756, CALIB=0x6 Oct 18 20:38:54 creabox kernel: [ 4.237799] iwlwifi 0000:02:00.0: U iwl_eeprom_init_hw_params Device SKU: 24GHz enabled, 52GHz enabled, 11.n enabled Oct 18 20:38:54 creabox kernel: [ 4.238877] iwlwifi 0000:02:00.0: U iwl_eeprom_init_hw_params Valid Tx ant: 0x3, Valid Rx ant: 0x3 Oct 18 20:38:54 creabox kernel: [ 4.239973] iwlwifi 0000:02:00.0: U iwl_op_mode_dvm_start MAC address: b4:b6:76:b6:4b:3f Oct 18 20:38:54 creabox kernel: [ 4.241061] iwlwifi 0000:02:00.0: U iwlagn_set_rxon_chain rx_chain=0x2406 active=2 idle=1 Oct 18 20:38:54 creabox kernel: [ 4.242225] iwlwifi 0000:02:00.0: U iwl_tt_initialize Initialize Thermal Throttling Oct 18 20:38:54 creabox kernel: [ 4.243302] iwlwifi 0000:02:00.0: U iwl_tt_initialize Advanced Thermal Throttling Oct 18 20:38:54 creabox kernel: [ 4.244491] cfg80211: Ignoring regulatory request Set by core since the driver uses its own custom regulatory domain 1401ed Oct 18 20:38:54 creabox kernel: [ 4.245706] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs' Oct 18 20:38:54 creabox kernel: [ 4.248884] bio: create slab <bio-2> at 2 Oct 18 20:38:54 creabox kernel: [ 4.294665] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null) Oct 18 20:38:54 creabox kernel: [ 4.415813] usb 1-1.1: new full-speed USB device number 3 using ehci-pci Oct 18 20:38:54 creabox kernel: [ 4.512006] usb 1-1.1: New USB device found, idVendor=8087, idProduct=07da Oct 18 20:38:54 creabox kernel: [ 4.513659] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 Oct 18 20:38:54 creabox kernel: [ 4.741165] EXT4-fs (dm-0): re-mounted. Opts: (null) Oct 18 20:38:54 creabox kernel: [ 4.770619] EXT4-fs (dm-0): re-mounted. Opts: discard,errors=remount-ro Oct 18 20:38:54 creabox kernel: [ 4.967861] Adding 1949692k swap on /dev/mapper/creabox-creabox_swap. Priority:-1 extents:1 across:1949692k SS Oct 18 20:38:54 creabox kernel: [ 5.125964] iwlwifi 0000:02:00.0: U iwlagn_mac_start enter Oct 18 20:38:54 creabox kernel: [ 5.127398] iwlwifi 0000:02:00.0: I iwl_prep_station Add STA to driver ID 15: ff:ff:ff:ff:ff:ff Oct 18 20:38:54 creabox kernel: [ 5.128832] iwlwifi 0000:02:00.0: I iwl_prep_station Add STA to driver ID 14: ff:ff:ff:ff:ff:ff Oct 18 20:38:54 creabox kernel: [ 5.130201] iwlwifi 0000:02:00.0: U iwl_pcie_prepare_card_hw iwl_trans_prepare_card_hw enter Oct 18 20:38:54 creabox kernel: [ 5.131553] iwlwifi 0000:02:00.0: U iwl_pcie_set_hw_ready hardware ready Oct 18 20:38:54 creabox kernel: [ 5.132876] iwlwifi 0000:02:00.0: U iwl_pcie_apm_init Init card's basic functions Oct 18 20:38:54 creabox kernel: [ 5.134230] iwlwifi 0000:02:00.0: L1 Disabled; Enabling L0S Oct 18 20:38:54 creabox kernel: [ 5.142113] iwlwifi 0000:02:00.0: Radio type=0x2-0x1-0x0 Oct 18 20:38:54 creabox kernel: [ 5.189000] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command COEX_PRIORITY_TABLE_CMD Oct 18 20:38:54 creabox kernel: [ 5.191379] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command COEX_PRIORITY_TABLE_CMD Oct 18 20:38:54 creabox kernel: [ 5.193743] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command COEX_PRIORITY_TABLE_CMD (#5a), seq: 0x0900, 72 bytes at 0[0]:9 Oct 18 20:38:54 creabox kernel: [ 5.196211] iwlwifi 0000:02:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command COEX_PRIORITY_TABLE_CMD Oct 18 20:38:54 creabox kernel: [ 5.198680] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command REPLY_PHY_CALIBRATION_CMD Oct 18 20:38:54 creabox kernel: [ 5.200166] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command REPLY_PHY_CALIBRATION_CMD Oct 18 20:38:54 creabox kernel: [ 5.201619] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_PHY_CALIBRATION_CMD (#b0), seq: 0x0901, 12 bytes at 1[1]:9 Oct 18 20:38:54 creabox kernel: [ 5.203209] iwlwifi 0000:02:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command REPLY_PHY_CALIBRATION_CMD Oct 18 20:38:54 creabox kernel: [ 5.205857] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command REPLY_BT_COEX_PROT_ENV Oct 18 20:38:54 creabox kernel: [ 5.207423] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command REPLY_BT_COEX_PROT_ENV Oct 18 20:38:54 creabox kernel: [ 5.208965] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_BT_COEX_PROT_ENV (#cd), seq: 0x0902, 8 bytes at 2[2]:9 Oct 18 20:38:54 creabox kernel: [ 5.210591] iwlwifi 0000:02:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command REPLY_BT_COEX_PROT_ENV Oct 18 20:38:54 creabox kernel: [ 5.213235] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command CALIBRATION_CFG_CMD Oct 18 20:38:54 creabox kernel: [ 5.214889] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command CALIBRATION_CFG_CMD Oct 18 20:38:54 creabox kernel: [ 5.216504] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command CALIBRATION_CFG_CMD (#65), seq: 0x0903, 96 bytes at 3[3]:9 Oct 18 20:38:54 creabox kernel: [ 5.218253] iwlwifi 0000:02:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command CALIBRATION_CFG_CMD Oct 18 20:38:54 creabox kernel: [ 5.445009] iwlwifi 0000:02:00.0: U iwl_pcie_apm_stop Stop card, put in low power state Oct 18 20:38:54 creabox kernel: [ 5.446708] iwlwifi 0000:02:00.0: U iwl_pcie_apm_stop_master stop master Oct 18 20:38:54 creabox kernel: [ 5.448400] iwlwifi 0000:02:00.0: U iwl_pcie_prepare_card_hw iwl_trans_prepare_card_hw enter Oct 18 20:38:54 creabox kernel: [ 5.450061] iwlwifi 0000:02:00.0: U iwl_pcie_set_hw_ready hardware ready Oct 18 20:38:54 creabox kernel: [ 5.451711] iwlwifi 0000:02:00.0: U iwl_pcie_apm_init Init card's basic functions Oct 18 20:38:54 creabox kernel: [ 5.453372] iwlwifi 0000:02:00.0: L1 Disabled; Enabling L0S Oct 18 20:38:54 creabox kernel: [ 5.461504] iwlwifi 0000:02:00.0: Radio type=0x2-0x1-0x0 Oct 18 20:38:54 creabox kernel: [ 5.508853] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command COEX_PRIORITY_TABLE_CMD Oct 18 20:38:54 creabox kernel: [ 5.510526] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command COEX_PRIORITY_TABLE_CMD Oct 18 20:38:54 creabox kernel: [ 5.512165] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command COEX_PRIORITY_TABLE_CMD (#5a), seq: 0x0900, 72 bytes at 0[0]:9 Oct 18 20:38:54 creabox kernel: [ 5.513855] iwlwifi 0000:02:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command COEX_PRIORITY_TABLE_CMD Oct 18 20:38:54 creabox kernel: [ 5.515531] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command REPLY_PHY_CALIBRATION_CMD Oct 18 20:38:54 creabox kernel: [ 5.517179] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command REPLY_PHY_CALIBRATION_CMD Oct 18 20:38:54 creabox kernel: [ 5.518800] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_PHY_CALIBRATION_CMD (#b0), seq: 0x0901, 12 bytes at 1[1]:9 Oct 18 20:38:54 creabox kernel: [ 5.520495] iwlwifi 0000:02:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command REPLY_PHY_CALIBRATION_CMD Oct 18 20:38:54 creabox kernel: [ 5.522146] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command REPLY_PHY_CALIBRATION_CMD Oct 18 20:38:54 creabox kernel: [ 5.523789] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command REPLY_PHY_CALIBRATION_CMD Oct 18 20:38:54 creabox kernel: [ 5.525388] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_PHY_CALIBRATION_CMD (#b0), seq: 0x0902, 12 bytes at 2[2]:9 Oct 18 20:38:54 creabox kernel: [ 5.527057] iwlwifi 0000:02:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command REPLY_PHY_CALIBRATION_CMD Oct 18 20:38:54 creabox kernel: [ 5.528702] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command REPLY_PHY_CALIBRATION_CMD Oct 18 20:38:54 creabox kernel: [ 5.530297] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command REPLY_PHY_CALIBRATION_CMD Oct 18 20:38:54 creabox kernel: [ 5.531870] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_PHY_CALIBRATION_CMD (#b0), seq: 0x0903, 12 bytes at 3[3]:9 Oct 18 20:38:54 creabox kernel: [ 5.533537] iwlwifi 0000:02:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command REPLY_PHY_CALIBRATION_CMD Oct 18 20:38:54 creabox kernel: [ 5.535178] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command REPLY_PHY_CALIBRATION_CMD Oct 18 20:38:54 creabox kernel: [ 5.536807] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command REPLY_PHY_CALIBRATION_CMD Oct 18 20:38:54 creabox kernel: [ 5.538411] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_PHY_CALIBRATION_CMD (#b0), seq: 0x0904, 520 bytes at 4[4]:9 Oct 18 20:38:54 creabox kernel: [ 5.540137] iwlwifi 0000:02:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command REPLY_PHY_CALIBRATION_CMD Oct 18 20:38:54 creabox kernel: [ 5.541838] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command REPLY_PHY_CALIBRATION_CMD Oct 18 20:38:54 creabox kernel: [ 5.543492] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command REPLY_PHY_CALIBRATION_CMD Oct 18 20:38:54 creabox kernel: [ 5.545123] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_PHY_CALIBRATION_CMD (#b0), seq: 0x0905, 1352 bytes at 5[5]:9 Oct 18 20:38:54 creabox kernel: [ 5.546925] iwlwifi 0000:02:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command REPLY_PHY_CALIBRATION_CMD Oct 18 20:38:54 creabox kernel: [ 5.548610] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command REPLY_PHY_CALIBRATION_CMD Oct 18 20:38:54 creabox kernel: [ 5.550476] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command REPLY_PHY_CALIBRATION_CMD Oct 18 20:38:54 creabox kernel: [ 5.552229] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_PHY_CALIBRATION_CMD (#b0), seq: 0x0906, 92 bytes at 6[6]:9 Oct 18 20:38:54 creabox kernel: [ 5.554042] iwlwifi 0000:02:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command REPLY_PHY_CALIBRATION_CMD Oct 18 20:38:54 creabox kernel: [ 5.556377] iwlwifi 0000:02:00.0: U iwl_alive_start Runtime Alive received. Oct 18 20:38:54 creabox kernel: [ 5.558599] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command REPLY_BT_CONFIG Oct 18 20:38:54 creabox kernel: [ 5.560376] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command REPLY_BT_CONFIG Oct 18 20:38:54 creabox kernel: [ 5.562252] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_BT_CONFIG (#9b), seq: 0x0907, 76 bytes at 7[7]:9 Oct 18 20:38:54 creabox kernel: [ 5.564087] iwlwifi 0000:02:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command REPLY_BT_CONFIG Oct 18 20:38:54 creabox kernel: [ 5.565893] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command REPLY_BT_COEX_PRIO_TABLE Oct 18 20:38:54 creabox kernel: [ 5.567696] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command REPLY_BT_COEX_PRIO_TABLE Oct 18 20:38:54 creabox kernel: [ 5.569456] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_BT_COEX_PRIO_TABLE (#cc), seq: 0x0908, 20 bytes at 8[8]:9 Oct 18 20:38:54 creabox kernel: [ 5.571285] iwlwifi 0000:02:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command REPLY_BT_COEX_PRIO_TABLE Oct 18 20:38:54 creabox kernel: [ 5.573002] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command REPLY_BT_COEX_PROT_ENV Oct 18 20:38:54 creabox kernel: [ 5.574842] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command REPLY_BT_COEX_PROT_ENV Oct 18 20:38:54 creabox kernel: [ 5.576659] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_BT_COEX_PROT_ENV (#cd), seq: 0x0909, 8 bytes at 9[9]:9 Oct 18 20:38:54 creabox kernel: [ 5.578510] iwlwifi 0000:02:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command REPLY_BT_COEX_PROT_ENV Oct 18 20:38:54 creabox kernel: [ 5.580298] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command REPLY_BT_COEX_PROT_ENV Oct 18 20:38:54 creabox kernel: [ 5.582160] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command REPLY_BT_COEX_PROT_ENV Oct 18 20:38:54 creabox kernel: [ 5.583998] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_BT_COEX_PROT_ENV (#cd), seq: 0x090A, 8 bytes at 10[10]:9 Oct 18 20:38:54 creabox kernel: [ 5.585854] iwlwifi 0000:02:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command REPLY_BT_COEX_PROT_ENV Oct 18 20:38:54 creabox kernel: [ 5.587623] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command CALIBRATION_CFG_CMD Oct 18 20:38:54 creabox kernel: [ 5.589337] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command CALIBRATION_CFG_CMD Oct 18 20:38:54 creabox kernel: [ 5.591037] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command CALIBRATION_CFG_CMD (#65), seq: 0x090B, 96 bytes at 11[11]:9 Oct 18 20:38:54 creabox kernel: [ 5.592878] iwlwifi 0000:02:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command CALIBRATION_CFG_CMD Oct 18 20:38:54 creabox kernel: [ 5.594611] iwlwifi 0000:02:00.0: U iwlagn_send_tx_ant_config select valid tx ant: 3 Oct 18 20:38:54 creabox kernel: [ 5.596361] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command TX_ANT_CONFIGURATION_CMD Oct 18 20:38:54 creabox kernel: [ 5.598084] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command TX_ANT_CONFIGURATION_CMD Oct 18 20:38:54 creabox kernel: [ 5.599809] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command TX_ANT_CONFIGURATION_CMD (#98), seq: 0x090C, 8 bytes at 12[12]:9 Oct 18 20:38:54 creabox kernel: [ 5.620752] iwlwifi 0000:02:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command TX_ANT_CONFIGURATION_CMD Oct 18 20:38:54 creabox kernel: [ 5.622514] iwlwifi 0000:02:00.0: U iwlagn_set_rxon_chain rx_chain=0x2406 active=2 idle=1 Oct 18 20:38:54 creabox kernel: [ 5.624264] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x090D, 8 bytes at 13[13]:9 Oct 18 20:38:54 creabox kernel: [ 5.626006] iwlwifi 0000:02:00.0: U iwl_print_rx_config_cmd RX CONFIG: Oct 18 20:38:54 creabox kernel: [ 5.626073] iwlwifi 0000:02:00.0: U iwl_tt_handler Queueing thermal throttling work. Oct 18 20:38:54 creabox kernel: [ 5.629464] iwl data: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Oct 18 20:38:54 creabox kernel: [ 5.631202] iwl data: 00000010: 00 00 00 00 00 00 00 00 03 00 06 24 15 0f 00 00 ...........$.... Oct 18 20:38:54 creabox kernel: [ 5.632927] iwl data: 00000020: 05 80 00 00 00 00 00 00 01 00 ff ff ff 00 00 00 ................ Oct 18 20:38:54 creabox kernel: [ 5.634644] iwl data: 00000030: 00 00 .. Oct 18 20:38:54 creabox kernel: [ 5.636402] iwlwifi 0000:02:00.0: U iwl_print_rx_config_cmd u16 channel: 0x1 Oct 18 20:38:54 creabox kernel: [ 5.638131] iwlwifi 0000:02:00.0: U iwl_print_rx_config_cmd u32 flags: 0x00008005 Oct 18 20:38:54 creabox kernel: [ 5.639864] iwlwifi 0000:02:00.0: U iwl_print_rx_config_cmd u32 filter_flags: 0x00000000 Oct 18 20:38:54 creabox kernel: [ 5.641577] iwlwifi 0000:02:00.0: U iwl_print_rx_config_cmd u8 dev_type: 0x3 Oct 18 20:38:54 creabox kernel: [ 5.643286] iwlwifi 0000:02:00.0: U iwl_print_rx_config_cmd u8 ofdm_basic_rates: 0x15 Oct 18 20:38:54 creabox kernel: [ 5.644980] iwlwifi 0000:02:00.0: U iwl_print_rx_config_cmd u8 cck_basic_rates: 0x0f Oct 18 20:38:54 creabox kernel: [ 5.646650] iwlwifi 0000:02:00.0: U iwl_print_rx_config_cmd u8[6] node_addr: 00:00:00:00:00:00 Oct 18 20:38:54 creabox kernel: [ 5.648313] iwlwifi 0000:02:00.0: U iwl_print_rx_config_cmd u8[6] bssid_addr: 00:00:00:00:00:00 Oct 18 20:38:54 creabox kernel: [ 5.649975] iwlwifi 0000:02:00.0: U iwl_print_rx_config_cmd u16 assoc_id: 0x0 Oct 18 20:38:54 creabox kernel: [ 5.651608] iwlwifi 0000:02:00.0: U iwl_full_rxon_required need full RXON - !iwl_is_associated_ctx(ctx) Oct 18 20:38:54 creabox kernel: [ 5.653243] iwlwifi 0000:02:00.0: U iwlagn_commit_rxon Going to commit RXON Oct 18 20:38:54 creabox kernel: [ 5.653243] * without RXON_FILTER_ASSOC_MSK Oct 18 20:38:54 creabox kernel: [ 5.653243] * channel = 1 Oct 18 20:38:54 creabox kernel: [ 5.653243] * bssid = 00:00:00:00:00:00 Oct 18 20:38:54 creabox kernel: [ 5.659691] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command REPLY_RXON Oct 18 20:38:54 creabox kernel: [ 5.661307] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command REPLY_RXON Oct 18 20:38:54 creabox kernel: [ 5.662920] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_RXON (#10), seq: 0x090E, 54 bytes at 14[14]:9 Oct 18 20:38:54 creabox kernel: [ 5.665818] iwlwifi 0000:02:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command REPLY_RXON Oct 18 20:38:54 creabox kernel: [ 5.667484] iwlwifi 0000:02:00.0: U iwl_tt_handler Queueing thermal throttling work. Oct 18 20:38:54 creabox kernel: [ 5.667490] iwlwifi 0000:02:00.0: U iwl_clear_ucode_stations Clearing ucode stations in driver Oct 18 20:38:54 creabox kernel: [ 5.667492] iwlwifi 0000:02:00.0: U iwl_clear_ucode_stations No active stations found to be cleared Oct 18 20:38:54 creabox kernel: [ 5.667495] iwlwifi 0000:02:00.0: U iwl_restore_stations Restoring all known stations ... start. Oct 18 20:38:54 creabox kernel: [ 5.667496] iwlwifi 0000:02:00.0: I iwl_restore_stations Restoring sta ff:ff:ff:ff:ff:ff Oct 18 20:38:54 creabox kernel: [ 5.667499] iwlwifi 0000:02:00.0: U iwl_send_add_sta Adding sta 15 (ff:ff:ff:ff:ff:ff) synchronously Oct 18 20:38:54 creabox kernel: [ 5.667500] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command REPLY_ADD_STA Oct 18 20:38:54 creabox kernel: [ 5.667502] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command REPLY_ADD_STA Oct 18 20:38:54 creabox kernel: [ 5.667504] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_ADD_STA (#18), seq: 0x090F, 96 bytes at 15[15]:9 Oct 18 20:38:54 creabox kernel: [ 5.681860] iwlwifi 0000:02:00.0: U iwl_process_add_sta_resp Processing response for adding station 15 Oct 18 20:38:54 creabox kernel: [ 5.683472] iwlwifi 0000:02:00.0: I iwl_process_add_sta_resp REPLY_ADD_STA PASSED Oct 18 20:38:54 creabox kernel: [ 5.685037] iwlwifi 0000:02:00.0: I iwl_sta_ucode_activate Added STA id 15 addr ff:ff:ff:ff:ff:ff to uCode Oct 18 20:38:54 creabox kernel: [ 5.686600] iwlwifi 0000:02:00.0: I iwl_process_add_sta_resp Added station id 15 addr ff:ff:ff:ff:ff:ff Oct 18 20:38:54 creabox kernel: [ 5.688152] iwlwifi 0000:02:00.0: I iwl_process_add_sta_resp Added station according to cmd buffer ff:ff:ff:ff:ff:ff Oct 18 20:38:54 creabox kernel: [ 5.689702] iwlwifi 0000:02:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command REPLY_ADD_STA Oct 18 20:38:54 creabox kernel: [ 5.691292] iwlwifi 0000:02:00.0: U is_lq_table_valid Channel 0 is not an HT channel Oct 18 20:38:54 creabox kernel: [ 5.692856] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command REPLY_TX_LINK_QUALITY_CMD Oct 18 20:38:54 creabox kernel: [ 5.694412] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command REPLY_TX_LINK_QUALITY_CMD Oct 18 20:38:54 creabox kernel: [ 5.695966] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_TX_LINK_QUALITY_CMD (#4e), seq: 0x0910, 92 bytes at 16[16]:9 Oct 18 20:38:54 creabox kernel: [ 5.697643] iwlwifi 0000:02:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command REPLY_TX_LINK_QUALITY_CMD Oct 18 20:38:54 creabox kernel: [ 5.699286] iwlwifi 0000:02:00.0: U iwl_send_lq_cmd init LQ command complete, clearing sta addition status for sta 15 Oct 18 20:38:54 creabox kernel: [ 5.700873] iwlwifi 0000:02:00.0: U iwl_restore_stations Restoring all known stations .... complete. Oct 18 20:38:54 creabox kernel: [ 5.702440] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command REPLY_CT_KILL_CONFIG_CMD Oct 18 20:38:54 creabox kernel: [ 5.704034] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command REPLY_CT_KILL_CONFIG_CMD Oct 18 20:38:54 creabox kernel: [ 5.705606] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_CT_KILL_CONFIG_CMD (#a4), seq: 0x0911, 16 bytes at 17[17]:9 Oct 18 20:38:54 creabox kernel: [ 5.707224] iwlwifi 0000:02:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command REPLY_CT_KILL_CONFIG_CMD Oct 18 20:38:54 creabox kernel: [ 5.708847] iwlwifi 0000:02:00.0: U iwl_rf_kill_ct_config REPLY_CT_KILL_CONFIG_CMD succeeded, critical temperature enter is 114,exit is 95 Oct 18 20:38:54 creabox kernel: [ 5.710484] iwlwifi 0000:02:00.0: U iwl_alive_start ALIVE processing complete. Oct 18 20:38:54 creabox kernel: [ 5.712097] iwlwifi 0000:02:00.0: U iwl_power_sleep_cam_cmd Sleep command for CAM Oct 18 20:38:54 creabox kernel: [ 5.713702] iwlwifi 0000:02:00.0: U iwl_set_power Sending power/sleep command Oct 18 20:38:54 creabox kernel: [ 5.715282] iwlwifi 0000:02:00.0: U iwl_set_power Flags value = 0x00000008 Oct 18 20:38:54 creabox kernel: [ 5.716855] iwlwifi 0000:02:00.0: U iwl_set_power Tx timeout = 0 Oct 18 20:38:54 creabox kernel: [ 5.718430] iwlwifi 0000:02:00.0: U iwl_set_power Rx timeout = 0 Oct 18 20:38:54 creabox kernel: [ 5.719952] iwlwifi 0000:02:00.0: U iwl_set_power Sleep interval vector = { 0 , 0 , 0 , 0 , 0 } Oct 18 20:38:54 creabox kernel: [ 5.721478] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command POWER_TABLE_CMD Oct 18 20:38:54 creabox kernel: [ 5.723004] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command POWER_TABLE_CMD Oct 18 20:38:54 creabox kernel: [ 5.724554] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command POWER_TABLE_CMD (#77), seq: 0x0912, 40 bytes at 18[18]:9 Oct 18 20:38:54 creabox kernel: [ 5.726138] iwlwifi 0000:02:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command POWER_TABLE_CMD Oct 18 20:38:54 creabox kernel: [ 5.727695] iwlwifi 0000:02:00.0: U iwlagn_set_rxon_chain rx_chain=0x2406 active=2 idle=1 Oct 18 20:38:54 creabox kernel: [ 5.729219] iwlwifi 0000:02:00.0: U iwlagn_set_rxon_chain rx_chain=0x2406 active=2 idle=1 Oct 18 20:38:54 creabox kernel: [ 5.730703] iwlwifi 0000:02:00.0: U iwlagn_mac_start Start UP work done. Oct 18 20:38:54 creabox kernel: [ 5.732186] iwlwifi 0000:02:00.0: U iwlagn_mac_start leave Oct 18 20:38:54 creabox kernel: [ 5.733639] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_LEDS_CMD (#48), seq: 0x0913, 12 bytes at 19[19]:9 Oct 18 20:38:54 creabox kernel: [ 5.735117] iwlwifi 0000:02:00.0: U iwlagn_mac_add_interface enter: type 2, addr b4:b6:76:b6:4b:3f Oct 18 20:38:54 creabox kernel: [ 5.736625] iwlwifi 0000:02:00.0: U iwlagn_set_rxon_chain rx_chain=0x2406 active=2 idle=1 Oct 18 20:38:54 creabox kernel: [ 5.738119] iwlwifi 0000:02:00.0: U iwl_print_rx_config_cmd RX CONFIG: Oct 18 20:38:54 creabox kernel: [ 5.739598] iwl data: 00000000: b4 b6 76 b6 4b 3f 00 00 00 00 00 00 00 00 00 00 ..v.K?.......... Oct 18 20:38:54 creabox kernel: [ 5.741088] iwl data: 00000010: 00 00 00 00 00 00 00 00 03 00 06 24 15 0f 00 00 ...........$.... Oct 18 20:38:54 creabox kernel: [ 5.742588] iwl data: 00000020: 05 80 00 00 04 00 00 00 01 00 ff ff ff 00 00 00 ................ Oct 18 20:38:54 creabox kernel: [ 5.744117] iwl data: 00000030: 00 00 .. Oct 18 20:38:54 creabox kernel: [ 5.745655] iwlwifi 0000:02:00.0: U iwl_print_rx_config_cmd u16 channel: 0x1 Oct 18 20:38:54 creabox kernel: [ 5.747187] iwlwifi 0000:02:00.0: U iwl_print_rx_config_cmd u32 flags: 0x00008005 Oct 18 20:38:54 creabox kernel: [ 5.748710] iwlwifi 0000:02:00.0: U iwl_print_rx_config_cmd u32 filter_flags: 0x00000004 Oct 18 20:38:54 creabox kernel: [ 5.750241] iwlwifi 0000:02:00.0: U iwl_print_rx_config_cmd u8 dev_type: 0x3 Oct 18 20:38:54 creabox kernel: [ 5.751761] iwlwifi 0000:02:00.0: U iwl_print_rx_config_cmd u8 ofdm_basic_rates: 0x15 Oct 18 20:38:54 creabox kernel: [ 5.753283] iwlwifi 0000:02:00.0: U iwl_print_rx_config_cmd u8 cck_basic_rates: 0x0f Oct 18 20:38:54 creabox kernel: [ 5.754785] iwlwifi 0000:02:00.0: U iwl_print_rx_config_cmd u8[6] node_addr: b4:b6:76:b6:4b:3f Oct 18 20:38:54 creabox kernel: [ 5.756288] iwlwifi 0000:02:00.0: U iwl_print_rx_config_cmd u8[6] bssid_addr: 00:00:00:00:00:00 Oct 18 20:38:54 creabox kernel: [ 5.757778] iwlwifi 0000:02:00.0: U iwl_print_rx_config_cmd u16 assoc_id: 0x0 Oct 18 20:38:54 creabox kernel: [ 5.759268] iwlwifi 0000:02:00.0: U iwl_full_rxon_required need full RXON - !iwl_is_associated_ctx(ctx) Oct 18 20:38:54 creabox kernel: [ 5.760780] iwlwifi 0000:02:00.0: U iwlagn_commit_rxon Going to commit RXON Oct 18 20:38:54 creabox kernel: [ 5.760780] * without RXON_FILTER_ASSOC_MSK Oct 18 20:38:54 creabox kernel: [ 5.760780] * channel = 1 Oct 18 20:38:54 creabox kernel: [ 5.760780] * bssid = 00:00:00:00:00:00 Oct 18 20:38:54 creabox kernel: [ 5.766686] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command REPLY_RXON Oct 18 20:38:54 creabox kernel: [ 5.768194] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command REPLY_RXON Oct 18 20:38:54 creabox kernel: [ 5.769668] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_RXON (#10), seq: 0x0914, 54 bytes at 20[20]:9 Oct 18 20:38:54 creabox kernel: [ 5.771428] iwlwifi 0000:02:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command REPLY_RXON Oct 18 20:38:54 creabox kernel: [ 5.772976] iwlwifi 0000:02:00.0: U iwl_tt_handler Queueing thermal throttling work. Oct 18 20:38:54 creabox kernel: [ 5.772989] iwlwifi 0000:02:00.0: U iwl_clear_ucode_stations Clearing ucode stations in driver Oct 18 20:38:54 creabox kernel: [ 5.772991] iwlwifi 0000:02:00.0: I iwl_clear_ucode_stations Clearing ucode active for station 15 Oct 18 20:38:54 creabox kernel: [ 5.772994] iwlwifi 0000:02:00.0: U iwl_restore_stations Restoring all known stations ... start. Oct 18 20:38:54 creabox kernel: [ 5.772995] iwlwifi 0000:02:00.0: I iwl_restore_stations Restoring sta ff:ff:ff:ff:ff:ff Oct 18 20:38:54 creabox kernel: [ 5.772997] iwlwifi 0000:02:00.0: U iwl_send_add_sta Adding sta 15 (ff:ff:ff:ff:ff:ff) synchronously Oct 18 20:38:54 creabox kernel: [ 5.772999] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command REPLY_ADD_STA Oct 18 20:38:54 creabox kernel: [ 5.773000] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command REPLY_ADD_STA Oct 18 20:38:54 creabox kernel: [ 5.773002] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_ADD_STA (#18), seq: 0x0915, 96 bytes at 21[21]:9 Oct 18 20:38:54 creabox kernel: [ 5.786416] iwlwifi 0000:02:00.0: U iwl_process_add_sta_resp Processing response for adding station 15 Oct 18 20:38:54 creabox kernel: [ 5.787913] iwlwifi 0000:02:00.0: I iwl_process_add_sta_resp REPLY_ADD_STA PASSED Oct 18 20:38:54 creabox kernel: [ 5.789392] iwlwifi 0000:02:00.0: I iwl_sta_ucode_activate Added STA id 15 addr ff:ff:ff:ff:ff:ff to uCode Oct 18 20:38:54 creabox kernel: [ 5.790881] iwlwifi 0000:02:00.0: I iwl_process_add_sta_resp Added station id 15 addr ff:ff:ff:ff:ff:ff Oct 18 20:38:54 creabox kernel: [ 5.792363] iwlwifi 0000:02:00.0: I iwl_process_add_sta_resp Added station according to cmd buffer ff:ff:ff:ff:ff:ff Oct 18 20:38:54 creabox kernel: [ 5.793852] iwlwifi 0000:02:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command REPLY_ADD_STA Oct 18 20:38:54 creabox kernel: [ 5.795358] iwlwifi 0000:02:00.0: U is_lq_table_valid Channel 1 is not an HT channel Oct 18 20:38:54 creabox kernel: [ 5.796835] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command REPLY_TX_LINK_QUALITY_CMD Oct 18 20:38:54 creabox kernel: [ 5.798304] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command REPLY_TX_LINK_QUALITY_CMD Oct 18 20:38:54 creabox kernel: [ 5.799771] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_TX_LINK_QUALITY_CMD (#4e), seq: 0x0916, 92 bytes at 22[22]:9 Oct 18 20:38:54 creabox kernel: [ 5.801340] iwlwifi 0000:02:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command REPLY_TX_LINK_QUALITY_CMD Oct 18 20:38:54 creabox kernel: [ 5.802886] iwlwifi 0000:02:00.0: U iwl_send_lq_cmd init LQ command complete, clearing sta addition status for sta 15 Oct 18 20:38:54 creabox kernel: [ 5.804387] iwlwifi 0000:02:00.0: U iwl_restore_stations Restoring all known stations .... complete. Oct 18 20:38:54 creabox kernel: [ 5.805862] iwlwifi 0000:02:00.0: U iwlagn_mac_add_interface leave Oct 18 20:38:54 creabox kernel: [ 5.807328] iwlwifi 0000:02:00.0: U iwlagn_set_rxon_chain rx_chain=0x2406 active=2 idle=1 Oct 18 20:38:54 creabox kernel: [ 5.808762] iwlwifi 0000:02:00.0: U iwl_print_rx_config_cmd RX CONFIG: Oct 18 20:38:54 creabox kernel: [ 5.810197] iwl data: 00000000: b4 b6 76 b6 4b 3f 00 00 00 00 00 00 00 00 00 00 ..v.K?.......... Oct 18 20:38:54 creabox kernel: [ 5.811655] iwl data: 00000010: 00 00 00 00 00 00 00 00 03 00 06 24 15 0f 00 00 ...........$.... Oct 18 20:38:54 creabox kernel: [ 5.813143] iwl data: 00000020: 05 80 00 00 44 00 00 00 01 00 ff ff ff 00 00 00 ....D........... Oct 18 20:38:54 creabox kernel: [ 5.814615] iwl data: 00000030: 00 00 .. Oct 18 20:38:54 creabox kernel: [ 5.816106] iwlwifi 0000:02:00.0: U iwl_print_rx_config_cmd u16 channel: 0x1 Oct 18 20:38:54 creabox kernel: [ 5.817593] iwlwifi 0000:02:00.0: U iwl_print_rx_config_cmd u32 flags: 0x00008005 Oct 18 20:38:54 creabox kernel: [ 5.819068] iwlwifi 0000:02:00.0: U iwl_print_rx_config_cmd u32 filter_flags: 0x00000044 Oct 18 20:38:54 creabox kernel: [ 5.820560] iwlwifi 0000:02:00.0: U iwl_print_rx_config_cmd u8 dev_type: 0x3 Oct 18 20:38:54 creabox kernel: [ 5.822016] iwlwifi 0000:02:00.0: U iwl_print_rx_config_cmd u8 ofdm_basic_rates: 0x15 Oct 18 20:38:54 creabox kernel: [ 5.823453] iwlwifi 0000:02:00.0: U iwl_print_rx_config_cmd u8 cck_basic_rates: 0x0f Oct 18 20:38:54 creabox kernel: [ 5.824868] iwlwifi 0000:02:00.0: U iwl_print_rx_config_cmd u8[6] node_addr: b4:b6:76:b6:4b:3f Oct 18 20:38:54 creabox kernel: [ 5.826302] iwlwifi 0000:02:00.0: U iwl_print_rx_config_cmd u8[6] bssid_addr: 00:00:00:00:00:00 Oct 18 20:38:54 creabox kernel: [ 5.827731] iwlwifi 0000:02:00.0: U iwl_print_rx_config_cmd u16 assoc_id: 0x0 Oct 18 20:38:54 creabox kernel: [ 5.829176] iwlwifi 0000:02:00.0: U iwl_full_rxon_required need full RXON - !iwl_is_associated_ctx(ctx) Oct 18 20:38:54 creabox kernel: [ 5.830599] iwlwifi 0000:02:00.0: U iwlagn_commit_rxon Going to commit RXON Oct 18 20:38:54 creabox kernel: [ 5.830599] * without RXON_FILTER_ASSOC_MSK Oct 18 20:38:54 creabox kernel: [ 5.830599] * channel = 1 Oct 18 20:38:54 creabox kernel: [ 5.830599] * bssid = 00:00:00:00:00:00 Oct 18 20:38:54 creabox kernel: [ 5.836136] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command REPLY_RXON Oct 18 20:38:54 creabox kernel: [ 5.837534] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command REPLY_RXON Oct 18 20:38:54 creabox kernel: [ 5.838929] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_RXON (#10), seq: 0x0917, 54 bytes at 23[23]:9 Oct 18 20:38:54 creabox kernel: [ 5.840621] iwlwifi 0000:02:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command REPLY_RXON Oct 18 20:38:54 creabox kernel: [ 5.842072] iwlwifi 0000:02:00.0: U iwl_tt_handler Queueing thermal throttling work. Oct 18 20:38:54 creabox kernel: [ 5.842085] iwlwifi 0000:02:00.0: U iwl_clear_ucode_stations Clearing ucode stations in driver Oct 18 20:38:54 creabox kernel: [ 5.842087] iwlwifi 0000:02:00.0: I iwl_clear_ucode_stations Clearing ucode active for station 15 Oct 18 20:38:54 creabox kernel: [ 5.842090] iwlwifi 0000:02:00.0: U iwl_restore_stations Restoring all known stations ... start. Oct 18 20:38:54 creabox kernel: [ 5.842091] iwlwifi 0000:02:00.0: I iwl_restore_stations Restoring sta ff:ff:ff:ff:ff:ff Oct 18 20:38:54 creabox kernel: [ 5.842093] iwlwifi 0000:02:00.0: U iwl_send_add_sta Adding sta 15 (ff:ff:ff:ff:ff:ff) synchronously Oct 18 20:38:54 creabox kernel: [ 5.842095] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command REPLY_ADD_STA Oct 18 20:38:54 creabox kernel: [ 5.842096] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command REPLY_ADD_STA Oct 18 20:38:54 creabox kernel: [ 5.842098] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_ADD_STA (#18), seq: 0x0918, 96 bytes at 24[24]:9 Oct 18 20:38:54 creabox kernel: [ 5.855110] iwlwifi 0000:02:00.0: U iwl_process_add_sta_resp Processing response for adding station 15 Oct 18 20:38:54 creabox kernel: [ 5.856583] iwlwifi 0000:02:00.0: I iwl_process_add_sta_resp REPLY_ADD_STA PASSED Oct 18 20:38:54 creabox kernel: [ 5.858048] iwlwifi 0000:02:00.0: I iwl_sta_ucode_activate Added STA id 15 addr ff:ff:ff:ff:ff:ff to uCode Oct 18 20:38:54 creabox kernel: [ 5.859540] iwlwifi 0000:02:00.0: I iwl_process_add_sta_resp Added station id 15 addr ff:ff:ff:ff:ff:ff Oct 18 20:38:54 creabox kernel: [ 5.861035] iwlwifi 0000:02:00.0: I iwl_process_add_sta_resp Added station according to cmd buffer ff:ff:ff:ff:ff:ff Oct 18 20:38:54 creabox kernel: [ 5.862524] iwlwifi 0000:02:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command REPLY_ADD_STA Oct 18 20:38:54 creabox kernel: [ 5.864055] iwlwifi 0000:02:00.0: U is_lq_table_valid Channel 1 is not an HT channel Oct 18 20:38:54 creabox kernel: [ 5.865562] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command REPLY_TX_LINK_QUALITY_CMD Oct 18 20:38:54 creabox kernel: [ 5.867068] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command REPLY_TX_LINK_QUALITY_CMD Oct 18 20:38:54 creabox kernel: [ 5.868554] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_TX_LINK_QUALITY_CMD (#4e), seq: 0x0919, 92 bytes at 25[25]:9 Oct 18 20:38:54 creabox kernel: [ 5.870153] iwlwifi 0000:02:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command REPLY_TX_LINK_QUALITY_CMD Oct 18 20:38:54 creabox kernel: [ 5.871744] iwlwifi 0000:02:00.0: U iwl_send_lq_cmd init LQ command complete, clearing sta addition status for sta 15 Oct 18 20:38:54 creabox kernel: [ 5.873286] iwlwifi 0000:02:00.0: U iwl_restore_stations Restoring all known stations .... complete. Oct 18 20:38:54 creabox kernel: [ 5.874850] iwlwifi 0000:02:00.0: U iwlagn_mac_conf_tx enter Oct 18 20:38:54 creabox kernel: [ 5.876400] iwlwifi 0000:02:00.0: U iwlagn_mac_conf_tx leave Oct 18 20:38:54 creabox kernel: [ 5.877918] iwlwifi 0000:02:00.0: U iwlagn_mac_conf_tx enter Oct 18 20:38:54 creabox kernel: [ 5.879425] iwlwifi 0000:02:00.0: U iwlagn_mac_conf_tx leave Oct 18 20:38:54 creabox kernel: [ 5.880933] iwlwifi 0000:02:00.0: U iwlagn_mac_conf_tx enter Oct 18 20:38:54 creabox kernel: [ 5.882385] iwlwifi 0000:02:00.0: U iwlagn_mac_conf_tx leave Oct 18 20:38:54 creabox kernel: [ 5.883823] iwlwifi 0000:02:00.0: U iwlagn_mac_conf_tx enter Oct 18 20:38:54 creabox kernel: [ 5.885238] iwlwifi 0000:02:00.0: U iwlagn_mac_conf_tx leave Oct 18 20:38:54 creabox kernel: [ 5.886634] iwlwifi 0000:02:00.0: U iwlagn_update_qos send QoS cmd with Qos active=0 FLAGS=0x0 Oct 18 20:38:54 creabox kernel: [ 5.888052] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command REPLY_QOS_PARAM Oct 18 20:38:54 creabox kernel: [ 5.889466] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command REPLY_QOS_PARAM Oct 18 20:38:54 creabox kernel: [ 5.890870] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_QOS_PARAM (#13), seq: 0x091A, 40 bytes at 26[26]:9 Oct 18 20:38:54 creabox kernel: [ 5.892327] iwlwifi 0000:02:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command REPLY_QOS_PARAM Oct 18 20:38:54 creabox kernel: [ 5.893783] iwlwifi 0000:02:00.0: U iwlagn_set_rxon_chain rx_chain=0x2406 active=2 idle=1 Oct 18 20:38:54 creabox kernel: [ 5.895211] iwlwifi 0000:02:00.0: U iwlagn_mac_config enter: changed 0xffffffff Oct 18 20:38:54 creabox kernel: [ 5.896598] iwlwifi 0000:02:00.0: U iwlagn_set_rxon_chain rx_chain=0x2406 active=2 idle=1 Oct 18 20:38:54 creabox kernel: [ 5.897977] iwlwifi 0000:02:00.0: U iwlagn_set_rxon_chain rx_chain=0x2406 active=2 idle=1 Oct 18 20:38:54 creabox kernel: [ 5.899365] iwlwifi 0000:02:00.0: U iwl_power_sleep_cam_cmd Sleep command for CAM Oct 18 20:38:54 creabox kernel: [ 5.900711] iwlwifi 0000:02:00.0: U iwlagn_mac_config TX Power old=0 new=15 Oct 18 20:38:54 creabox kernel: [ 5.902051] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command REPLY_TX_POWER_DBM_CMD Oct 18 20:38:54 creabox kernel: [ 5.903457] iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command REPLY_TX_POWER_DBM_CMD Oct 18 20:38:54 creabox kernel: [ 5.904798] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_TX_POWER_DBM_CMD (#95), seq: 0x091B, 8 bytes at 27[27]:9 Oct 18 20:38:54 creabox kernel: [ 5.906572] iwlwifi 0000:02:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command REPLY_TX_POWER_DBM_CMD Oct 18 20:38:54 creabox kernel: [ 5.908027] iwlwifi 0000:02:00.0: U iwlagn_mac_config leave Oct 18 20:38:54 creabox kernel: [ 5.909432] iwlwifi 0000:02:00.0: U iwlagn_configure_filter Enter: changed: 0x0, total: 0x80000000 Oct 18 20:38:54 creabox kernel: [ 5.911058] iwlwifi 0000:02:00.0: U iwlagn_configure_filter Enter: changed: 0x0, total: 0x80000000 Oct 18 20:38:54 creabox kernel: [ 5.926627] device eth0 entered promiscuous mode Oct 18 20:38:54 creabox kernel: [ 6.057953] e1000e 0000:00:19.0: irq 47 for MSI/MSI-X Oct 18 20:38:54 creabox kernel: [ 6.163035] e1000e 0000:00:19.0: irq 47 for MSI/MSI-X Oct 18 20:38:54 creabox kernel: [ 7.676129] e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx Oct 18 20:38:54 creabox kernel: [ 7.679122] e1000e 0000:00:19.0 eth0: 10/100 speed: disabling TSO Oct 18 20:38:54 creabox kernel: [ 7.681910] xen_bridge: port 1(eth0) entered forwarding state Oct 18 20:38:54 creabox kernel: [ 7.684662] xen_bridge: port 1(eth0) entered forwarding state Oct 18 20:38:54 creabox acpid: starting up with netlink and the input layer Oct 18 20:38:54 creabox acpid: 1 rule loaded Oct 18 20:38:54 creabox acpid: waiting for events: event logging is off Oct 18 20:38:54 creabox /usr/sbin/cron[2897]: (CRON) INFO (pidfile fd = 3) Oct 18 20:38:54 creabox /usr/sbin/cron[2912]: (CRON) STARTUP (fork ok) Oct 18 20:38:54 creabox /usr/sbin/cron[2912]: (CRON) INFO (Running @reboot jobs) Oct 18 20:39:52 creabox kernel: [ 65.980221] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x091C, 8 bytes at 28[28]:9 Oct 18 20:39:52 creabox kernel: [ 65.980486] iwlwifi 0000:02:00.0: U iwl_tt_handler Queueing thermal throttling work. Oct 18 20:39:52 creabox kernel: [ 65.980649] iwlwifi 0000:02:00.0: U iwl_advance_tt_handler Temperature increase 10 degree Celsius Oct 18 20:40:52 creabox kernel: [ 126.109405] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x091D, 8 bytes at 29[29]:9 Oct 18 20:41:53 creabox kernel: [ 186.238563] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x091E, 8 bytes at 30[30]:9 Oct 18 20:42:53 creabox kernel: [ 246.367716] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x091F, 8 bytes at 31[31]:9 Oct 18 20:42:53 creabox kernel: [ 246.367968] iwlwifi 0000:02:00.0: U iwl_tt_handler Queueing thermal throttling work. Oct 18 20:43:53 creabox kernel: [ 306.496878] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x0920, 8 bytes at 32[0]:9 Oct 18 20:43:53 creabox kernel: [ 306.497128] iwlwifi 0000:02:00.0: U iwl_tt_handler Queueing thermal throttling work. Oct 18 20:44:53 creabox kernel: [ 366.626055] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x0921, 8 bytes at 33[1]:9 Oct 18 20:44:53 creabox kernel: [ 366.626321] iwlwifi 0000:02:00.0: U iwl_tt_handler Queueing thermal throttling work. Oct 18 20:45:53 creabox kernel: [ 426.755213] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x0922, 8 bytes at 34[2]:9 Oct 18 20:45:53 creabox kernel: [ 426.755494] iwlwifi 0000:02:00.0: U iwl_tt_handler Queueing thermal throttling work. Oct 18 20:46:53 creabox kernel: [ 486.884369] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x0923, 8 bytes at 35[3]:9 Oct 18 20:46:53 creabox kernel: [ 486.886313] iwlwifi 0000:02:00.0: U iwl_tt_handler Queueing thermal throttling work. Oct 18 20:47:54 creabox kernel: [ 547.013528] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x0924, 8 bytes at 36[4]:9 Oct 18 20:48:54 creabox kernel: [ 607.142678] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x0925, 8 bytes at 37[5]:9 Oct 18 20:49:54 creabox kernel: [ 667.271836] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x0926, 8 bytes at 38[6]:9 Oct 18 20:50:54 creabox kernel: [ 727.400996] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x0927, 8 bytes at 39[7]:9 Oct 18 20:51:54 creabox kernel: [ 787.530149] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x0928, 8 bytes at 40[8]:9 Oct 18 20:52:54 creabox kernel: [ 847.659322] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x0929, 8 bytes at 41[9]:9 Oct 18 20:53:54 creabox kernel: [ 907.788475] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x092A, 8 bytes at 42[10]:9 Oct 18 20:54:55 creabox kernel: [ 967.917629] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x092B, 8 bytes at 43[11]:9 Oct 18 20:54:55 creabox kernel: [ 967.917907] iwlwifi 0000:02:00.0: U iwl_tt_handler Queueing thermal throttling work. Oct 18 20:55:55 creabox kernel: [ 1028.046789] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x092C, 8 bytes at 44[12]:9 Oct 18 20:56:55 creabox kernel: [ 1088.175949] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x092D, 8 bytes at 45[13]:9 Oct 18 20:56:55 creabox kernel: [ 1088.176204] iwlwifi 0000:02:00.0: U iwl_tt_handler Queueing thermal throttling work. Oct 18 20:57:55 creabox kernel: [ 1148.305122] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x092E, 8 bytes at 46[14]:9 Oct 18 20:57:55 creabox kernel: [ 1148.305414] iwlwifi 0000:02:00.0: U iwl_tt_handler Queueing thermal throttling work. Oct 18 20:58:55 creabox kernel: [ 1208.434265] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x092F, 8 bytes at 47[15]:9 Oct 18 20:58:55 creabox kernel: [ 1208.434517] iwlwifi 0000:02:00.0: U iwl_tt_handler Queueing thermal throttling work. Oct 18 20:59:55 creabox kernel: [ 1268.563419] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x0930, 8 bytes at 48[16]:9 Oct 18 21:00:56 creabox kernel: [ 1328.692582] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x0931, 8 bytes at 49[17]:9 Oct 18 21:00:56 creabox kernel: [ 1328.692834] iwlwifi 0000:02:00.0: U iwl_tt_handler Queueing thermal throttling work. Oct 18 21:01:56 creabox kernel: [ 1388.821742] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x0932, 8 bytes at 50[18]:9 Oct 18 21:01:56 creabox kernel: [ 1388.822019] iwlwifi 0000:02:00.0: U iwl_tt_handler Queueing thermal throttling work. Oct 18 21:02:56 creabox kernel: [ 1448.950898] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x0933, 8 bytes at 51[19]:9 Oct 18 21:03:56 creabox kernel: [ 1509.080067] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x0934, 8 bytes at 52[20]:9 Oct 18 21:04:56 creabox kernel: [ 1569.209217] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x0935, 8 bytes at 53[21]:9 Oct 18 21:05:56 creabox kernel: [ 1629.338378] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x0936, 8 bytes at 54[22]:9 Oct 18 21:06:57 creabox kernel: [ 1689.467536] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x0937, 8 bytes at 55[23]:9 Oct 18 21:07:57 creabox kernel: [ 1749.596707] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x0938, 8 bytes at 56[24]:9 Oct 18 21:08:57 creabox kernel: [ 1809.725852] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x0939, 8 bytes at 57[25]:9 Oct 18 21:08:57 creabox kernel: [ 1809.726106] iwlwifi 0000:02:00.0: U iwl_tt_handler Queueing thermal throttling work. Oct 18 21:09:57 creabox kernel: [ 1869.855014] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x093A, 8 bytes at 58[26]:9 Oct 18 21:10:57 creabox kernel: [ 1929.984169] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x093B, 8 bytes at 59[27]:9 Oct 18 21:11:57 creabox kernel: [ 1990.113331] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x093C, 8 bytes at 60[28]:9 Oct 18 21:12:58 creabox kernel: [ 2050.242462] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x093D, 8 bytes at 61[29]:9 Oct 18 21:13:58 creabox kernel: [ 2110.371646] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x093E, 8 bytes at 62[30]:9 Oct 18 21:14:58 creabox kernel: [ 2170.500780] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x093F, 8 bytes at 63[31]:9 Oct 18 21:15:58 creabox kernel: [ 2230.629964] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x0940, 8 bytes at 64[0]:9 Oct 18 21:16:58 creabox kernel: [ 2290.759123] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x0941, 8 bytes at 65[1]:9 Oct 18 21:17:01 creabox /USR/SBIN/CRON[3388]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Oct 18 21:17:58 creabox kernel: [ 2350.888289] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x0942, 8 bytes at 66[2]:9 Oct 18 21:18:58 creabox kernel: [ 2411.017442] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x0943, 8 bytes at 67[3]:9 Oct 18 21:19:59 creabox kernel: [ 2471.146603] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x0944, 8 bytes at 68[4]:9 Oct 18 21:20:59 creabox kernel: [ 2531.275758] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x0945, 8 bytes at 69[5]:9 Oct 18 21:21:59 creabox kernel: [ 2591.404922] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x0946, 8 bytes at 70[6]:9 Oct 18 21:22:59 creabox kernel: [ 2651.534078] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x0947, 8 bytes at 71[7]:9 Oct 18 21:23:59 creabox kernel: [ 2711.663231] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x0948, 8 bytes at 72[8]:9 Oct 18 21:23:59 creabox kernel: [ 2711.663474] iwlwifi 0000:02:00.0: U iwl_tt_handler Queueing thermal throttling work. Oct 18 21:24:59 creabox kernel: [ 2771.792396] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x0949, 8 bytes at 73[9]:9 Oct 18 21:24:59 creabox kernel: [ 2771.792637] iwlwifi 0000:02:00.0: U iwl_tt_handler Queueing thermal throttling work. Oct 18 21:26:00 creabox kernel: [ 2831.921569] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x094A, 8 bytes at 74[10]:9 Oct 18 21:26:09 creabox kernel: [ 2840.946472] cfg80211: Pending regulatory request, waiting for it to be processed... Oct 18 21:27:00 creabox kernel: [ 2892.050714] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x094B, 8 bytes at 75[11]:9 Oct 18 21:28:00 creabox kernel: [ 2952.179870] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x094C, 8 bytes at 76[12]:9 Oct 18 21:29:00 creabox kernel: [ 3012.309029] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x094D, 8 bytes at 77[13]:9 Oct 18 21:30:00 creabox kernel: [ 3072.438189] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x094E, 8 bytes at 78[14]:9 Oct 18 21:31:00 creabox kernel: [ 3132.567348] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x094F, 8 bytes at 79[15]:9 Oct 18 21:32:01 creabox kernel: [ 3192.696505] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x0950, 8 bytes at 80[16]:9 Oct 18 21:33:01 creabox kernel: [ 3252.825666] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x0951, 8 bytes at 81[17]:9 Oct 18 21:34:01 creabox kernel: [ 3312.954824] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x0952, 8 bytes at 82[18]:9 Oct 18 21:35:01 creabox kernel: [ 3373.083990] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x0953, 8 bytes at 83[19]:9 Oct 18 21:36:01 creabox kernel: [ 3433.213140] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x0954, 8 bytes at 84[20]:9 Oct 18 21:37:01 creabox kernel: [ 3493.342299] iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command REPLY_STATISTICS_CMD (#9c), seq: 0x0955, 8 bytes at 85[21]:9 [-- Attachment #4: iw-info.txt --] [-- Type: text/plain, Size: 5981 bytes --] Wiphy phy0 Band 1: Capabilities: 0x1072 HT20/HT40 Static SM Power Save RX Greenfield RX HT20 SGI RX HT40 SGI No RX STBC Max AMSDU length: 3839 bytes DSSS/CCK HT40 Maximum RX AMPDU length 65535 bytes (exponent: 0x003) Minimum RX AMPDU time spacing: 4 usec (0x05) HT TX/RX MCS rate indexes supported: 0-15, 32 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 (non-HT): * 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 Band 2: Capabilities: 0x1072 HT20/HT40 Static SM Power Save RX Greenfield RX HT20 SGI RX HT40 SGI No RX STBC Max AMSDU length: 3839 bytes DSSS/CCK HT40 Maximum RX AMPDU length 65535 bytes (exponent: 0x003) Minimum RX AMPDU time spacing: 4 usec (0x05) HT TX/RX MCS rate indexes supported: 0-15, 32 Frequencies: * 5180 MHz [36] (15.0 dBm) (passive scanning, no IBSS) * 5200 MHz [40] (15.0 dBm) (passive scanning, no IBSS) * 5220 MHz [44] (15.0 dBm) (passive scanning, no IBSS) * 5240 MHz [48] (15.0 dBm) (passive scanning, no IBSS) * 5260 MHz [52] (15.0 dBm) (passive scanning, no IBSS, radar detection) * 5280 MHz [56] (15.0 dBm) (passive scanning, no IBSS, radar detection) * 5300 MHz [60] (15.0 dBm) (passive scanning, no IBSS, radar detection) * 5320 MHz [64] (15.0 dBm) (passive scanning, no IBSS, radar detection) * 5500 MHz [100] (15.0 dBm) (passive scanning, no IBSS, radar detection) * 5520 MHz [104] (15.0 dBm) (passive scanning, no IBSS, radar detection) * 5540 MHz [108] (15.0 dBm) (passive scanning, no IBSS, radar detection) * 5560 MHz [112] (15.0 dBm) (passive scanning, no IBSS, radar detection) * 5580 MHz [116] (15.0 dBm) (passive scanning, no IBSS, radar detection) * 5600 MHz [120] (15.0 dBm) (passive scanning, no IBSS, radar detection) * 5620 MHz [124] (15.0 dBm) (passive scanning, no IBSS, radar detection) * 5640 MHz [128] (15.0 dBm) (passive scanning, no IBSS, radar detection) * 5660 MHz [132] (15.0 dBm) (passive scanning, no IBSS, radar detection) * 5680 MHz [136] (15.0 dBm) (passive scanning, no IBSS, radar detection) * 5700 MHz [140] (15.0 dBm) (passive scanning, no IBSS, radar detection) * 5745 MHz [149] (15.0 dBm) (passive scanning, no IBSS) * 5765 MHz [153] (15.0 dBm) (passive scanning, no IBSS) * 5785 MHz [157] (15.0 dBm) (passive scanning, no IBSS) * 5805 MHz [161] (15.0 dBm) (passive scanning, no IBSS) * 5825 MHz [165] (15.0 dBm) (passive scanning, no IBSS) Bitrates (non-HT): * 6.0 Mbps * 9.0 Mbps * 12.0 Mbps * 18.0 Mbps * 24.0 Mbps * 36.0 Mbps * 48.0 Mbps * 54.0 Mbps max # scan SSIDs: 20 max scan IEs length: 195 bytes Coverage class: 0 (up to 0m) Supported Ciphers: * WEP40 (00-0f-ac:1) * WEP104 (00-0f-ac:5) * TKIP (00-0f-ac:2) * CCMP (00-0f-ac:4) Available Antennas: TX 0 RX 0 Supported interface modes: * IBSS * managed * AP * AP/VLAN * monitor software interface modes (can always be added): * AP/VLAN * monitor valid interface combinations: * #{ managed } <= 1, #{ AP } <= 1, total <= 2, #channels <= 1, STA/AP BI must match * #{ managed } <= 2, total <= 2, #channels <= 1 Supported commands: * new_interface * set_interface * new_key * new_beacon * new_station * new_mpath * set_mesh_params * set_bss * authenticate * associate * deauthenticate * disassociate * join_ibss * join_mesh * set_tx_bitrate_mask * action * frame_wait_cancel * set_wiphy_netns * set_channel * set_wds_peer * Unknown command (84) * Unknown command (87) * Unknown command (85) * Unknown command (89) * Unknown command (92) * connect * disconnect Supported TX frame types: * IBSS: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * AP/VLAN: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * mesh point: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * Unknown mode (10): 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 Supported RX frame types: * IBSS: 0x40 0xb0 0xc0 0xd0 * managed: 0x40 0xd0 * AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0 * AP/VLAN: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0 * mesh point: 0xb0 0xc0 0xd0 * P2P-client: 0x40 0xd0 * P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0 * Unknown mode (10): 0x40 0xd0 Device supports RSN-IBSS. WoWLAN support: * wake up on disconnect * wake up on magic packet * wake up on pattern match, up to 20 patterns of 16-128 bytes * can do GTK rekeying * wake up on GTK rekey failure * wake up on EAP identity request * wake up on rfkill release HT Capability overrides: * MCS: ff ff ff ff ff ff ff ff ff ff * maximum A-MSDU length * supported channel width * short GI for 40 MHz * max A-MPDU length exponent * min MPDU start spacing Device supports TX status socket option. Device supports HT-IBSS. ^ permalink raw reply related [flat|nested] 38+ messages in thread
* Re: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work. 2013-10-23 12:28 ` [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work Sander Eikelenboom @ 2013-12-11 15:17 ` Sander Eikelenboom 2013-12-11 15:38 ` Luis R. Rodriguez 0 siblings, 1 reply; 38+ messages in thread From: Sander Eikelenboom @ 2013-12-11 15:17 UTC (permalink / raw) To: Berg, Johannes Cc: Luis R. Rodriguez, Grumbach, Emmanuel, linux-kernel, ilw@linux.intel.com, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, John W. Linville Since i haven't got a response to this yet and after having the troubled machine back: The problem is still present in linux 3.13-rc3 The problem seems to be in this piece of code: root@creabox:/usr/src/linux-tip# git blame -L 1567,1601 net/wireless/reg.c fe33eb39 (Luis R. Rodriguez 2009-02-21 00:04:30 -0500 1567) b2e253cf (Luis R. Rodriguez 2010-11-17 21:46:09 -0800 1568) /* b2e253cf (Luis R. Rodriguez 2010-11-17 21:46:09 -0800 1569) * Processes regulatory hints, this is all the NL80211_REGDOM_SET_BY_* b2e253cf (Luis R. Rodriguez 2010-11-17 21:46:09 -0800 1570) * Regulatory hints come on a first come first serve basis and we b2e253cf (Luis R. Rodriguez 2010-11-17 21:46:09 -0800 1571) * must process each one atomically. b2e253cf (Luis R. Rodriguez 2010-11-17 21:46:09 -0800 1572) */ fe33eb39 (Luis R. Rodriguez 2009-02-21 00:04:30 -0500 1573) static void reg_process_pending_hints(void) b0e2880b (Luis R. Rodriguez 2010-11-17 21:46:08 -0800 1574) { c492db37 (Johannes Berg 2012-12-06 16:29:25 +0100 1575) struct regulatory_request *reg_request, *lr; fe33eb39 (Luis R. Rodriguez 2009-02-21 00:04:30 -0500 1576) c492db37 (Johannes Berg 2012-12-06 16:29:25 +0100 1577) lr = get_last_request(); b0e2880b (Luis R. Rodriguez 2010-11-17 21:46:08 -0800 1578) b2e253cf (Luis R. Rodriguez 2010-11-17 21:46:09 -0800 1579) /* When last_request->processed becomes true this will be rescheduled */ c492db37 (Johannes Berg 2012-12-06 16:29:25 +0100 1580) if (lr && !lr->processed) { 1a919318 (Johannes Berg 2012-12-03 17:21:11 +0100 1581) REG_DBG_PRINT("Pending regulatory request, waiting for it to be processed...\n"); 5fe231e8 (Johannes Berg 2013-05-08 21:45:15 +0200 1582) return; If i "comment out" the return above, setting the regulatory domain with "iw reg set XX" does work. b2e253cf (Luis R. Rodriguez 2010-11-17 21:46:09 -0800 1583) } b2e253cf (Luis R. Rodriguez 2010-11-17 21:46:09 -0800 1584) fe33eb39 (Luis R. Rodriguez 2009-02-21 00:04:30 -0500 1585) spin_lock(®_requests_lock); fe33eb39 (Luis R. Rodriguez 2009-02-21 00:04:30 -0500 1586) b2e253cf (Luis R. Rodriguez 2010-11-17 21:46:09 -0800 1587) if (list_empty(®_requests_list)) { d951c1dd (Luis R. Rodriguez 2009-02-21 00:24:15 -0500 1588) spin_unlock(®_requests_lock); 5fe231e8 (Johannes Berg 2013-05-08 21:45:15 +0200 1589) return; fe33eb39 (Luis R. Rodriguez 2009-02-21 00:04:30 -0500 1590) } b2e253cf (Luis R. Rodriguez 2010-11-17 21:46:09 -0800 1591) b2e253cf (Luis R. Rodriguez 2010-11-17 21:46:09 -0800 1592) reg_request = list_first_entry(®_requests_list, b2e253cf (Luis R. Rodriguez 2010-11-17 21:46:09 -0800 1593) struct regulatory_request, b2e253cf (Luis R. Rodriguez 2010-11-17 21:46:09 -0800 1594) list); b2e253cf (Luis R. Rodriguez 2010-11-17 21:46:09 -0800 1595) list_del_init(®_request->list); b2e253cf (Luis R. Rodriguez 2010-11-17 21:46:09 -0800 1596) fe33eb39 (Luis R. Rodriguez 2009-02-21 00:04:30 -0500 1597) spin_unlock(®_requests_lock); b0e2880b (Luis R. Rodriguez 2010-11-17 21:46:08 -0800 1598) 8848bef0 (Luis R. Rodriguez 2011-12-20 12:23:36 -0800 1599) reg_process_hint(reg_request, reg_request->initiator); fe33eb39 (Luis R. Rodriguez 2009-02-21 00:04:30 -0500 1600) } fe33eb39 (Luis R. Rodriguez 2009-02-21 00:04:30 -0500 1601) -- Sander Wednesday, October 23, 2013, 2:28:49 PM, you wrote: > Ping ? > Friday, October 18, 2013, 7:43:49 PM, you wrote: >> Hi, >> I'm trying to change the regulatory domain for my wireless adapter: >> Intel Corporation Centrino Advanced-N 6235 >> But it fails to change from "world" to anything else (say "US") >> I enabled debug options used iwlwifi.debug=0x00043FFF for boot and added some printk's which i think should be triggered .. but they are not. >> It seems in function "reg_process_pending_hints" the processing is deferred, >> but from the code i don't see how it would ever be triggered to complete ? >> Hope some can give some hints to what could be going on ... >> Attached: >> - full syslog from boot till "iw set reg US", which is done at "Oct 18 21:26:09" >> - patch.diff with the added debug printk's against 3.12-rc5 (it also contains the patch that was needed to suppress another warning in the iwlwifi driver. >> -- >> Sander ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work. 2013-12-11 15:17 ` Sander Eikelenboom @ 2013-12-11 15:38 ` Luis R. Rodriguez 2013-12-11 16:53 ` Sander Eikelenboom [not found] ` <CAJwzM1nwFa7z5gwh42aj39M2dxVXnuecDrhQkVyL+DDFAXwwbg@mail.gmail.com> 0 siblings, 2 replies; 38+ messages in thread From: Luis R. Rodriguez @ 2013-12-11 15:38 UTC (permalink / raw) To: Sander Eikelenboom Cc: Berg, Johannes, Grumbach, Emmanuel, linux-kernel@vger.kernel.org, ilw@linux.intel.com, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, John W. Linville On Wed, Dec 11, 2013 at 4:17 PM, Sander Eikelenboom <linux@eikelenboom.it> wrote: > Since i haven't got a response to this yet and after having the troubled machine back: > The problem is still present in linux 3.13-rc3 Keep in mind regulatory hints for Intel or Atheros cards do nothing other than help compliance further given that the cards already have their own regulatory data, the user input / hint is only going to reduce the card's channels further. That said the fact that you are not seeing a regulatory domain being set is an issue provided you have CRDA installed or use CONFIG_CFG80211_INTERNAL_REGDB. Keep in mind that the latest version of wireless-regdb had a signature issue reported by users and not sure if that is cleared yet, so that would also prevent the wireless-regdb being read even if CRDA was present. To rule that out try putting the db.txt into net/wireless/db.txt and compile with CONFIG_CFG80211_INTERNAL_REGDB for now. Then send the dmesg output, no need for all that fluffy intel debug log as its not useful in this case. Luis ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work. 2013-12-11 15:38 ` Luis R. Rodriguez @ 2013-12-11 16:53 ` Sander Eikelenboom 2013-12-11 17:14 ` Luis R. Rodriguez [not found] ` <CAJwzM1nwFa7z5gwh42aj39M2dxVXnuecDrhQkVyL+DDFAXwwbg@mail.gmail.com> 1 sibling, 1 reply; 38+ messages in thread From: Sander Eikelenboom @ 2013-12-11 16:53 UTC (permalink / raw) To: Luis R. Rodriguez Cc: Berg, Johannes, Grumbach, Emmanuel, linux-kernel@vger.kernel.org, ilw@linux.intel.com, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, John W. Linville Wednesday, December 11, 2013, 4:38:13 PM, you wrote: > On Wed, Dec 11, 2013 at 4:17 PM, Sander Eikelenboom > <linux@eikelenboom.it> wrote: >> Since i haven't got a response to this yet and after having the troubled machine back: >> The problem is still present in linux 3.13-rc3 > Keep in mind regulatory hints for Intel or Atheros cards do nothing > other than help compliance further given that the cards already have > their own regulatory data, the user input / hint is only going to > reduce the card's channels further. So in essence what you are saying is that the firmware/eeprom already dictates the limited channels available based on .. errr .. yeah based on what ... And setting the regulatory domain yourself only limits this list of limited channels available only further ? I now spotted this from the dmesg: [ 4.818467] cfg80211: Ignoring regulatory request set by core since the driver uses its own custom regulatory domain Joy o joy who ever came up with that great idea .. Would be nice it that error came up again when you would try to set the domain, instead of silently ignoring it. So now the only thing left is to try to find out if some one has hacked these bloody cards, what a mess. Do other cards like broadcom or whatever have the same issue ? > That said the fact that you are > not seeing a regulatory domain being set is an issue provided you have > CRDA installed or use CONFIG_CFG80211_INTERNAL_REGDB. Keep in mind > that the latest version of wireless-regdb had a signature issue > reported by users and not sure if that is cleared yet, so that would > also prevent the wireless-regdb being read even if CRDA was present. > To rule that out try putting the db.txt into net/wireless/db.txt and > compile with CONFIG_CFG80211_INTERNAL_REGDB for now. I did have CRDA installed (debian). And also compiled the db.txt in. > Then send the dmesg output, no need for all that fluffy intel debug > log as its not useful in this case. Compiled with db.txt in: ~# iw reg set US ~# iw reg get country 00: (2402 - 2472 @ 40), (6, 20) (2457 - 2482 @ 40), (6, 20), PASSIVE-SCAN, NO-IBSS (2474 - 2494 @ 20), (6, 20), NO-OFDM, PASSIVE-SCAN, NO-IBSS (5170 - 5250 @ 160), (6, 20), PASSIVE-SCAN, NO-IBSS (5250 - 5330 @ 160), (6, 20), DFS, PASSIVE-SCAN, NO-IBSS (5490 - 5730 @ 160), (6, 20), DFS, PASSIVE-SCAN, NO-IBSS [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Initializing cgroup subsys cpuacct [ 0.000000] Linux version 3.13.0-rc3-20131211b+ (root@creabox) (gcc version 4.7.2 (Debian 4.7.2-5) ) #1 SMP Wed Dec 11 19:30:50 CET 2013 [ 0.000000] Command line: placeholder root=/dev/mapper/creabox-creabox_dom0 ro vga=794 nomodeset quiet [ 0.000000] Freeing 9d-100 pfn range: 99 pages freed [ 0.000000] 1-1 mapping on 9d->100 [ 0.000000] Freeing 20000-20200 pfn range: 512 pages freed [ 0.000000] 1-1 mapping on 20000->20200 [ 0.000000] Freeing 40004-40005 pfn range: 1 pages freed [ 0.000000] 1-1 mapping on 40004->40005 [ 0.000000] 1-1 mapping on db9f1->dc20d [ 0.000000] 1-1 mapping on dc20e->dc251 [ 0.000000] 1-1 mapping on dd000->100000 [ 0.000000] Released 612 pages of unused memory [ 0.000000] Set 146115 page(s) to 1-1 mapping [ 0.000000] Populating 60000-60264 pfn range: 612 pages added [ 0.000000] e820: BIOS-provided physical RAM map: [ 0.000000] Xen: [mem 0x0000000000000000-0x000000000009cfff] usable [ 0.000000] Xen: [mem 0x000000000009d800-0x00000000000fffff] reserved [ 0.000000] Xen: [mem 0x0000000000100000-0x000000001fffffff] usable [ 0.000000] Xen: [mem 0x0000000020000000-0x00000000201fffff] reserved [ 0.000000] Xen: [mem 0x0000000020200000-0x0000000040003fff] usable [ 0.000000] Xen: [mem 0x0000000040004000-0x0000000040004fff] reserved [ 0.000000] Xen: [mem 0x0000000040005000-0x0000000060263fff] usable [ 0.000000] Xen: [mem 0x0000000060264000-0x00000000db9f0fff] unusable [ 0.000000] Xen: [mem 0x00000000db9f1000-0x00000000dbe6ffff] reserved [ 0.000000] Xen: [mem 0x00000000dbe70000-0x00000000dbe7ffff] ACPI data [ 0.000000] Xen: [mem 0x00000000dbe80000-0x00000000dbf9dfff] ACPI NVS [ 0.000000] Xen: [mem 0x00000000dbf9e000-0x00000000dc20cfff] reserved [ 0.000000] Xen: [mem 0x00000000dc20d000-0x00000000dc20dfff] unusable [ 0.000000] Xen: [mem 0x00000000dc20e000-0x00000000dc250fff] ACPI NVS [ 0.000000] Xen: [mem 0x00000000dc251000-0x00000000dcffffff] unusable [ 0.000000] Xen: [mem 0x00000000dd000000-0x00000000df9fffff] reserved [ 0.000000] Xen: [mem 0x00000000f8000000-0x00000000fbffffff] reserved [ 0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec00fff] reserved [ 0.000000] Xen: [mem 0x00000000fed00000-0x00000000fed03fff] reserved [ 0.000000] Xen: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved [ 0.000000] Xen: [mem 0x00000000fee00000-0x00000000fee00fff] reserved [ 0.000000] Xen: [mem 0x00000000ff000000-0x00000000ffffffff] reserved [ 0.000000] Xen: [mem 0x0000000100000000-0x000000021e5fffff] unusable [ 0.000000] NX (Execute Disable) protection: active [ 0.000000] SMBIOS 2.7 present. [ 0.000000] DMI: /D53427RKE, BIOS RKPPT10H.86A.0017.2013.0425.1251 04/25/2013 [ 0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved [ 0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable [ 0.000000] No AGP bridge found [ 0.000000] e820: last_pfn = 0x60264 max_arch_pfn = 0x400000000 [ 0.000000] Base memory trampoline at [ffff880000097000] 97000 size 24576 [ 0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff] [ 0.000000] [mem 0x00000000-0x000fffff] page 4k [ 0.000000] init_memory_mapping: [mem 0x60000000-0x601fffff] [ 0.000000] [mem 0x60000000-0x601fffff] page 4k [ 0.000000] BRK [0x02133000, 0x02133fff] PGTABLE [ 0.000000] BRK [0x02134000, 0x02134fff] PGTABLE [ 0.000000] init_memory_mapping: [mem 0x5c000000-0x5fffffff] [ 0.000000] [mem 0x5c000000-0x5fffffff] page 4k [ 0.000000] BRK [0x02135000, 0x02135fff] PGTABLE [ 0.000000] BRK [0x02136000, 0x02136fff] PGTABLE [ 0.000000] BRK [0x02137000, 0x02137fff] PGTABLE [ 0.000000] BRK [0x02138000, 0x02138fff] PGTABLE [ 0.000000] init_memory_mapping: [mem 0x00100000-0x1fffffff] [ 0.000000] [mem 0x00100000-0x1fffffff] page 4k [ 0.000000] init_memory_mapping: [mem 0x20200000-0x40003fff] [ 0.000000] [mem 0x20200000-0x40003fff] page 4k [ 0.000000] init_memory_mapping: [mem 0x40005000-0x5bffffff] [ 0.000000] [mem 0x40005000-0x5bffffff] page 4k [ 0.000000] init_memory_mapping: [mem 0x60200000-0x60263fff] [ 0.000000] [mem 0x60200000-0x60263fff] page 4k [ 0.000000] RAMDISK: [mem 0x02541000-0x03792fff] [ 0.000000] ACPI: RSDP 00000000000f0490 000024 (v02 Intel) [ 0.000000] ACPI: XSDT 00000000dbe74080 00007C (v01 Intel D53427RK 00000011 AMI 00010013) [ 0.000000] ACPI: FACP 00000000dbe7e100 00010C (v05 Intel D53427RK 00000011 AMI 00010013) [ 0.000000] ACPI: DSDT 00000000dbe74188 009F72 (v02 Intel D53427RK 00000011 INTL 20051117) [ 0.000000] ACPI: FACS 00000000dbf9c080 000040 [ 0.000000] ACPI: APIC 00000000dbe7e210 000072 (v03 Intel D53427RK 00000011 AMI 00010013) [ 0.000000] ACPI: FPDT 00000000dbe7e288 000044 (v01 Intel D53427RK 00000011 AMI 00010013) [ 0.000000] ACPI: TCPA 00000000dbe7e2d0 000032 (v02 APTIO4 NAPAASF 00000011 MSFT 01000013) [ 0.000000] ACPI: MCFG 00000000dbe7e308 00003C (v01 Intel D53427RK 00000011 MSFT 00000097) [ 0.000000] ACPI: HPET 00000000dbe7e348 000038 (v01 Intel D53427RK 00000011 AMI. 00000005) [ 0.000000] ACPI: SSDT 00000000dbe7e380 000315 (v01 SataRe SataTabl 00000011 INTL 20091112) [ 0.000000] ACPI: SSDT 00000000dbe7e698 0009AA (v01 PmRef Cpu0Ist 00000011 INTL 20051117) [ 0.000000] ACPI: SSDT 00000000dbe7f048 000B22 (v01 PmRef CpuPm 00000011 INTL 20051117) [ 0.000000] ACPI: XMAR 00000000dbe7fb70 0000B8 (v01 INTEL SNB 00000011 INTL 00000001) [ 0.000000] ACPI: ASF! 00000000dbe7fc28 0000A5 (v32 INTEL HCG 00000011 TFSM 000F4240) [ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] NUMA turned off [ 0.000000] Faking a node at [mem 0x0000000000000000-0x0000000060263fff] [ 0.000000] Initmem setup node 0 [mem 0x00000000-0x60263fff] [ 0.000000] NODE_DATA [mem 0x60260000-0x60263fff] [ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x00001000-0x00ffffff] [ 0.000000] DMA32 [mem 0x01000000-0xffffffff] [ 0.000000] Normal empty [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x00001000-0x0009cfff] [ 0.000000] node 0: [mem 0x00100000-0x1fffffff] [ 0.000000] node 0: [mem 0x20200000-0x40003fff] [ 0.000000] node 0: [mem 0x40005000-0x60263fff] [ 0.000000] On node 0 totalpages: 393215 [ 0.000000] DMA zone: 56 pages used for memmap [ 0.000000] DMA zone: 21 pages reserved [ 0.000000] DMA zone: 3996 pages, LIFO batch:0 [ 0.000000] DMA32 zone: 5329 pages used for memmap [ 0.000000] DMA32 zone: 389219 pages, LIFO batch:31 [ 0.000000] ACPI: PM-Timer IO Port: 0x408 [ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x01] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1]) [ 0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) [ 0.000000] IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [ 0.000000] ACPI: IRQ0 used by override. [ 0.000000] ACPI: IRQ2 used by override. [ 0.000000] ACPI: IRQ9 used by override. [ 0.000000] Using ACPI (MADT) for SMP configuration information [ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000 [ 0.000000] smpboot: Allowing 4 CPUs, 0 hotplug CPUs [ 0.000000] nr_irqs_gsi: 40 [ 0.000000] e820: [mem 0xdfa00000-0xf7ffffff] available for PCI devices [ 0.000000] Booting paravirtualized kernel on Xen [ 0.000000] Xen version: 4.3.0 (preserve-AD) [ 0.000000] setup_percpu: NR_CPUS:16 nr_cpumask_bits:16 nr_cpu_ids:4 nr_node_ids:1 [ 0.000000] PERCPU: Embedded 28 pages/cpu @ffff88005fa00000 s84800 r8192 d21696 u524288 [ 0.000000] pcpu-alloc: s84800 r8192 d21696 u524288 alloc=1*2097152 [ 0.000000] pcpu-alloc: [0] 0 1 2 3 [ 3.455877] Built 1 zonelists in Node order, mobility grouping on. Total pages: 387809 [ 3.455879] Policy zone: DMA32 [ 3.455881] Kernel command line: placeholder root=/dev/mapper/creabox-creabox_dom0 ro vga=794 nomodeset quiet [ 3.456148] PID hash table entries: 4096 (order: 3, 32768 bytes) [ 3.456200] xsave: enabled xstate_bv 0x7, cntxt size 0x340 [ 3.485246] software IO TLB [mem 0x59c00000-0x5dc00000] (64MB) mapped at [ffff880059c00000-ffff88005dbfffff] [ 3.490516] Memory: 1440360K/1572860K available (9180K kernel code, 1152K rwdata, 3720K rodata, 1148K init, 868K bss, 132500K reserved) [ 3.490597] Hierarchical RCU implementation. [ 3.490598] RCU dyntick-idle grace-period acceleration is enabled. [ 3.490600] RCU restricting CPUs from NR_CPUS=16 to nr_cpu_ids=4. [ 3.490607] NR_IRQS:4352 nr_irqs:712 16 [ 3.490690] xen: sci override: global_irq=9 trigger=0 polarity=0 [ 3.490692] xen: registering gsi 9 triggering 0 polarity 0 [ 3.490705] xen: --> pirq=9 -> irq=9 (gsi=9) [ 3.490731] xen: acpi sci 9 [ 3.490735] xen: --> pirq=1 -> irq=1 (gsi=1) [ 3.490739] xen: --> pirq=2 -> irq=2 (gsi=2) [ 3.490742] xen: --> pirq=3 -> irq=3 (gsi=3) [ 3.490745] xen: --> pirq=4 -> irq=4 (gsi=4) [ 3.490749] xen: --> pirq=5 -> irq=5 (gsi=5) [ 3.490752] xen: --> pirq=6 -> irq=6 (gsi=6) [ 3.490756] xen: --> pirq=7 -> irq=7 (gsi=7) [ 3.490759] xen: --> pirq=8 -> irq=8 (gsi=8) [ 3.490763] xen: --> pirq=10 -> irq=10 (gsi=10) [ 3.490766] xen: --> pirq=11 -> irq=11 (gsi=11) [ 3.490770] xen: --> pirq=12 -> irq=12 (gsi=12) [ 3.490773] xen: --> pirq=13 -> irq=13 (gsi=13) [ 3.490776] xen: --> pirq=14 -> irq=14 (gsi=14) [ 3.490780] xen: --> pirq=15 -> irq=15 (gsi=15) [ 3.490868] Console: colour dummy device 80x25 [ 3.490973] console [tty0] enabled [ 3.491005] Xen: using vcpuop timer interface [ 3.491010] installing Xen timer for CPU 0 [ 3.491035] tsc: Detected 2294.840 MHz processor [ 3.491040] Calibrating delay loop (skipped), value calculated using timer frequency.. 4589.68 BogoMIPS (lpj=9179360) [ 3.491043] pid_max: default: 32768 minimum: 301 [ 3.491073] Security Framework initialized [ 3.491505] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) [ 3.492350] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) [ 3.492678] Mount-cache hash table entries: 256 [ 3.492891] Initializing cgroup subsys devices [ 3.492894] Initializing cgroup subsys freezer [ 3.492896] Initializing cgroup subsys net_cls [ 3.492898] Initializing cgroup subsys blkio [ 3.492900] Initializing cgroup subsys perf_event [ 3.492973] ENERGY_PERF_BIAS: Set to 'normal', was 'performance' [ 3.492973] ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8) [ 3.492978] CPU: Physical Processor ID: 0 [ 3.492980] CPU: Processor Core ID: 0 [ 3.493501] mce: CPU supports 2 MCE banks [ 3.493522] Last level iTLB entries: 4KB 512, 2MB 0, 4MB 0 [ 3.493522] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32 [ 3.493522] tlb_flushall_shift: 1 [ 3.493675] Freeing SMP alternatives memory: 20K (ffffffff82040000 - ffffffff82045000) [ 3.494393] ACPI: Core revision 20131115 [ 3.501663] ACPI: All ACPI Tables successfully acquired [ 3.503034] Performance Events: unsupported p6 CPU model 58 no PMU driver, software events only. [ 3.503318] NMI watchdog: disabled (cpu0): hardware events not enabled [ 3.503426] installing Xen timer for CPU 1 [ 3.504376] installing Xen timer for CPU 2 [ 3.505272] installing Xen timer for CPU 3 [ 3.506059] x86: Booted up 1 node, 4 CPUs [ 3.506492] devtmpfs: initialized [ 3.507507] xor: automatically using best checksumming function: [ 3.547815] avx : 12277.000 MB/sec [ 3.547837] xen:grant_table: Grant tables using version 2 layout [ 3.547854] Grant table initialized [ 3.547975] NET: Registered protocol family 16 [ 3.548581] ACPI: bus type PCI registered [ 3.548584] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 [ 3.548792] dca service started, version 1.12.1 [ 3.548831] PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xf8000000-0xfbffffff] (base 0xf8000000) [ 3.548834] PCI: MMCONFIG at [mem 0xf8000000-0xfbffffff] reserved in E820 [ 3.559456] PCI: Using configuration type 1 for base access [ 3.562760] bio: create slab <bio-0> at 0 [ 3.628910] raid6: sse2x1 4631 MB/s [ 3.697825] raid6: sse2x2 5833 MB/s [ 3.766734] raid6: sse2x4 6582 MB/s [ 3.766736] raid6: using algorithm sse2x4 (6582 MB/s) [ 3.766738] raid6: using ssse3x2 recovery algorithm [ 3.766799] ACPI: Added _OSI(Module Device) [ 3.766802] ACPI: Added _OSI(Processor Device) [ 3.766805] ACPI: Added _OSI(3.0 _SCP Extensions) [ 3.766807] ACPI: Added _OSI(Processor Aggregator Device) [ 3.770647] ACPI: Executed 1 blocks of module-level executable AML code [ 3.783867] ACPI: SSDT 00000000dbe1d018 00083B (v01 PmRef Cpu0Cst 00003001 INTL 20051117) [ 3.784350] ACPI: Dynamic OEM Table Load: [ 3.784354] ACPI: SSDT (null) 00083B (v01 PmRef Cpu0Cst 00003001 INTL 20051117) [ 3.795839] ACPI: SSDT 00000000dbe1ea98 000303 (v01 PmRef ApIst 00003000 INTL 20051117) [ 3.796365] ACPI: Dynamic OEM Table Load: [ 3.796369] ACPI: SSDT (null) 000303 (v01 PmRef ApIst 00003000 INTL 20051117) [ 3.807973] ACPI: SSDT 00000000dbe1fc18 000119 (v01 PmRef ApCst 00003000 INTL 20051117) [ 3.808452] ACPI: Dynamic OEM Table Load: [ 3.808455] ACPI: SSDT (null) 000119 (v01 PmRef ApCst 00003000 INTL 20051117) [ 3.821033] ACPI: Interpreter enabled [ 3.821047] ACPI: (supports S0 S5) [ 3.821050] ACPI: Using IOAPIC for interrupt routing [ 3.821113] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug [ 3.821325] ACPI: No dock devices found. [ 3.831643] ACPI: Power Resource [FN00] (off) [ 3.831758] ACPI: Power Resource [FN01] (off) [ 3.831871] ACPI: Power Resource [FN02] (off) [ 3.831981] ACPI: Power Resource [FN03] (off) [ 3.832090] ACPI: Power Resource [FN04] (off) [ 3.832983] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-3e]) [ 3.832991] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI] [ 3.834077] acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug PME AER PCIeCapability] [ 3.834837] ACPI: \_SB_.PCI0.TPMX: can't evaluate _ADR (0x5) [ 3.835133] ACPI: \_SB_.PCI0.PDRC: can't evaluate _ADR (0x5) [ 3.835136] ACPI: \_SB_.PCI0.ITPM: can't evaluate _ADR (0x5) [ 3.835139] ACPI: \_SB_.PCI0.DOCK: can't evaluate _ADR (0x5) [ 3.835141] PCI host bridge to bus 0000:00 [ 3.835144] pci_bus 0000:00: root bus resource [bus 00-3e] [ 3.835147] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7] [ 3.835150] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff] [ 3.835153] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff] [ 3.835155] pci_bus 0000:00: root bus resource [mem 0x000d0000-0x000d3fff] [ 3.835158] pci_bus 0000:00: root bus resource [mem 0x000d4000-0x000d7fff] [ 3.835160] pci_bus 0000:00: root bus resource [mem 0x000d8000-0x000dbfff] [ 3.835163] pci_bus 0000:00: root bus resource [mem 0x000dc000-0x000dffff] [ 3.835165] pci_bus 0000:00: root bus resource [mem 0x000e0000-0x000e3fff] [ 3.835168] pci_bus 0000:00: root bus resource [mem 0x000e4000-0x000e7fff] [ 3.835171] pci_bus 0000:00: root bus resource [mem 0xdfa00000-0xfeafffff] [ 3.835191] pci 0000:00:00.0: [8086:0154] type 00 class 0x060000 [ 3.835444] pci 0000:00:02.0: [8086:0166] type 00 class 0x030000 [ 3.835485] pci 0000:00:02.0: reg 0x10: [mem 0xf7800000-0xf7bfffff 64bit] [ 3.835508] pci 0000:00:02.0: reg 0x18: [mem 0xe0000000-0xefffffff 64bit pref] [ 3.835523] pci 0000:00:02.0: reg 0x20: [io 0xf000-0xf03f] [ 3.835813] pci 0000:00:14.0: [8086:1e31] type 00 class 0x0c0330 [ 3.835876] pci 0000:00:14.0: reg 0x10: [mem 0xf7d20000-0xf7d2ffff 64bit] [ 3.836089] pci 0000:00:14.0: PME# supported from D3hot D3cold [ 3.836178] pci 0000:00:14.0: System wakeup disabled by ACPI [ 3.836263] pci 0000:00:16.0: [8086:1e3a] type 00 class 0x078000 [ 3.836327] pci 0000:00:16.0: reg 0x10: [mem 0xf7d3c000-0xf7d3c00f 64bit] [ 3.836552] pci 0000:00:16.0: PME# supported from D0 D3hot D3cold [ 3.836720] pci 0000:00:16.3: [8086:1e3d] type 00 class 0x070002 [ 3.836772] pci 0000:00:16.3: reg 0x10: [io 0xf0e0-0xf0e7] [ 3.836798] pci 0000:00:16.3: reg 0x14: [mem 0xf7d3a000-0xf7d3afff] [ 3.837174] pci 0000:00:19.0: [8086:1502] type 00 class 0x020000 [ 3.837229] pci 0000:00:19.0: reg 0x10: [mem 0xf7d00000-0xf7d1ffff] [ 3.837252] pci 0000:00:19.0: reg 0x14: [mem 0xf7d39000-0xf7d39fff] [ 3.837276] pci 0000:00:19.0: reg 0x18: [io 0xf080-0xf09f] [ 3.837474] pci 0000:00:19.0: PME# supported from D0 D3hot D3cold [ 3.837567] pci 0000:00:19.0: System wakeup disabled by ACPI [ 3.837650] pci 0000:00:1a.0: [8086:1e2d] type 00 class 0x0c0320 [ 3.837705] pci 0000:00:1a.0: reg 0x10: [mem 0xf7d38000-0xf7d383ff] [ 3.837953] pci 0000:00:1a.0: PME# supported from D0 D3hot D3cold [ 3.838067] pci 0000:00:1a.0: System wakeup disabled by ACPI [ 3.838147] pci 0000:00:1b.0: [8086:1e20] type 00 class 0x040300 [ 3.838193] pci 0000:00:1b.0: reg 0x10: [mem 0xf7d30000-0xf7d33fff 64bit] [ 3.838415] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold [ 3.838511] pci 0000:00:1b.0: System wakeup disabled by ACPI [ 3.838589] pci 0000:00:1c.0: [8086:1e10] type 01 class 0x060400 [ 3.838831] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold [ 3.838933] pci 0000:00:1c.0: System wakeup disabled by ACPI [ 3.839012] pci 0000:00:1c.2: [8086:1e14] type 01 class 0x060400 [ 3.839250] pci 0000:00:1c.2: PME# supported from D0 D3hot D3cold [ 3.839353] pci 0000:00:1c.2: System wakeup disabled by ACPI [ 3.839470] pci 0000:00:1d.0: [8086:1e26] type 00 class 0x0c0320 [ 3.839528] pci 0000:00:1d.0: reg 0x10: [mem 0xf7d37000-0xf7d373ff] [ 3.839781] pci 0000:00:1d.0: PME# supported from D0 D3hot D3cold [ 3.839901] pci 0000:00:1d.0: System wakeup disabled by ACPI [ 3.839975] pci 0000:00:1f.0: [8086:1e56] type 00 class 0x060100 [ 3.840380] pci 0000:00:1f.2: [8086:1e03] type 00 class 0x010601 [ 3.840457] pci 0000:00:1f.2: reg 0x10: [io 0xf0d0-0xf0d7] [ 3.840483] pci 0000:00:1f.2: reg 0x14: [io 0xf0c0-0xf0c3] [ 3.840506] pci 0000:00:1f.2: reg 0x18: [io 0xf0b0-0xf0b7] [ 3.840530] pci 0000:00:1f.2: reg 0x1c: [io 0xf0a0-0xf0a3] [ 3.840554] pci 0000:00:1f.2: reg 0x20: [io 0xf060-0xf07f] [ 3.840578] pci 0000:00:1f.2: reg 0x24: [mem 0xf7d36000-0xf7d367ff] [ 3.840737] pci 0000:00:1f.2: PME# supported from D3hot [ 3.840890] pci 0000:00:1f.3: [8086:1e22] type 00 class 0x0c0500 [ 3.840939] pci 0000:00:1f.3: reg 0x10: [mem 0xf7d35000-0xf7d350ff 64bit] [ 3.841005] pci 0000:00:1f.3: reg 0x20: [io 0xf040-0xf05f] [ 3.841341] pci 0000:00:1c.0: PCI bridge to [bus 01] [ 3.841855] pci 0000:02:00.0: [8086:088e] type 00 class 0x028000 [ 3.842214] pci 0000:02:00.0: reg 0x10: [mem 0xf7c00000-0xf7c01fff 64bit] [ 3.844029] pci 0000:02:00.0: PME# supported from D0 D3hot D3cold [ 3.844333] pci 0000:02:00.0: System wakeup disabled by ACPI [ 3.852928] pci 0000:00:1c.2: PCI bridge to [bus 02] [ 3.852952] pci 0000:00:1c.2: bridge window [mem 0xf7c00000-0xf7cfffff] [ 3.853762] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 10 *11 12 14 15) [ 3.853856] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled. [ 3.853944] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 *4 5 6 10 11 12 14 15) [ 3.854032] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 *10 11 12 14 15) [ 3.854119] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 *5 6 10 11 12 14 15) [ 3.854207] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled. [ 3.854295] ACPI: PCI Interrupt Link [LNKG] (IRQs *3 4 5 6 10 11 12 14 15) [ 3.854381] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 10 *11 12 14 15) [ 3.854738] ACPI: Enabled 6 GPEs in block 00 to 3F [ 3.854749] ACPI: \_SB_.PCI0: notify handler is installed [ 3.854814] Found 1 acpi root devices [ 3.854878] xen:balloon: Initialising balloon driver [ 3.855020] xen_balloon: Initialising balloon driver [ 3.855150] vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none [ 3.855156] vgaarb: loaded [ 3.855157] vgaarb: bridge control possible 0000:00:02.0 [ 3.855370] SCSI subsystem initialized [ 3.855435] libata version 3.00 loaded. [ 3.855463] ACPI: bus type USB registered [ 3.855491] usbcore: registered new interface driver usbfs [ 3.855503] usbcore: registered new interface driver hub [ 3.855560] usbcore: registered new device driver usb [ 3.855588] pps_core: LinuxPPS API ver. 1 registered [ 3.855590] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it> [ 3.855597] PTP clock support registered [ 3.855638] wmi: Mapper loaded [ 3.855661] Advanced Linux Sound Architecture Driver Initialized. [ 3.855663] PCI: Using ACPI for IRQ routing [ 3.861714] PCI: pci_cache_line_size set to 64 bytes [ 3.861873] e820: reserve RAM buffer [mem 0x0009d000-0x0009ffff] [ 3.861877] e820: reserve RAM buffer [mem 0x40004000-0x43ffffff] [ 3.861879] e820: reserve RAM buffer [mem 0x60264000-0x63ffffff] [ 3.862108] cfg80211: Calling CRDA to update world regulatory domain [ 3.862596] Switched to clocksource xen [ 3.868179] FS-Cache: Loaded [ 3.868304] CacheFiles: Loaded [ 3.868328] pnp: PnP ACPI init [ 3.868341] ACPI: bus type PNP registered [ 3.868411] pnp 00:00: [dma 4] [ 3.868439] pnp 00:00: Plug and Play ACPI device, IDs PNP0200 (active) [ 3.868468] pnp 00:01: Plug and Play ACPI device, IDs INT0800 (active) [ 3.868605] pnp 00:02: Plug and Play ACPI device, IDs PNP0103 (active) [ 3.868666] system 00:03: [io 0x0680-0x069f] has been reserved [ 3.868671] system 00:03: [io 0x1000-0x100f] has been reserved [ 3.868674] system 00:03: [io 0xffff] has been reserved [ 3.868677] system 00:03: [io 0xffff] has been reserved [ 3.868680] system 00:03: [io 0x0400-0x0453] could not be reserved [ 3.868683] system 00:03: [io 0x0458-0x047f] has been reserved [ 3.868686] system 00:03: [io 0x0500-0x057f] has been reserved [ 3.868688] system 00:03: [io 0x164e-0x164f] has been reserved [ 3.868692] system 00:03: Plug and Play ACPI device, IDs PNP0c02 (active) [ 3.868704] xen: registering gsi 8 triggering 1 polarity 0 [ 3.868755] pnp 00:04: Plug and Play ACPI device, IDs PNP0b00 (active) [ 3.868818] system 00:05: [io 0x0454-0x0457] has been reserved [ 3.868821] system 00:05: Plug and Play ACPI device, IDs INT3f0d PNP0c02 (active) [ 3.868994] system 00:06: [io 0x0a00-0x0a1f] has been reserved [ 3.868997] system 00:06: [io 0x0a30-0x0a3f] has been reserved [ 3.869000] system 00:06: [io 0x0a20-0x0a2f] has been reserved [ 3.869003] system 00:06: Plug and Play ACPI device, IDs PNP0c02 (active) [ 3.869096] system 00:07: [io 0x04d0-0x04d1] has been reserved [ 3.869100] system 00:07: Plug and Play ACPI device, IDs PNP0c02 (active) [ 3.869110] xen: registering gsi 13 triggering 1 polarity 0 [ 3.869160] pnp 00:08: Plug and Play ACPI device, IDs PNP0c04 (active) [ 3.869218] pnp 00:09: Plug and Play ACPI device, IDs PNP0c31 (active) [ 3.869549] system 00:0a: [mem 0xfed1c000-0xfed1ffff] has been reserved [ 3.869552] system 00:0a: [mem 0xfed10000-0xfed17fff] has been reserved [ 3.869555] system 00:0a: [mem 0xfed18000-0xfed18fff] has been reserved [ 3.869558] system 00:0a: [mem 0xfed19000-0xfed19fff] has been reserved [ 3.869561] system 00:0a: [mem 0xf8000000-0xfbffffff] has been reserved [ 3.869564] system 00:0a: [mem 0xfed20000-0xfed3ffff] has been reserved [ 3.869567] system 00:0a: [mem 0xfed90000-0xfed93fff] has been reserved [ 3.869570] system 00:0a: [mem 0xfed45000-0xfed8ffff] has been reserved [ 3.869573] system 00:0a: [mem 0xff000000-0xffffffff] has been reserved [ 3.869576] system 00:0a: [mem 0xfee00000-0xfeefffff] could not be reserved [ 3.869579] system 00:0a: [mem 0xdfa00000-0xdfa00fff] has been reserved [ 3.869582] system 00:0a: Plug and Play ACPI device, IDs PNP0c02 (active) [ 3.869860] system 00:0b: [mem 0x20000000-0x201fffff] has been reserved [ 3.869863] system 00:0b: [mem 0x40004000-0x40004fff] has been reserved [ 3.869866] system 00:0b: Plug and Play ACPI device, IDs PNP0c01 (active) [ 3.869892] pnp: PnP ACPI: found 12 devices [ 3.869893] ACPI: bus type PNP unregistered [ 3.880399] PM-Timer failed consistency check (0xffffff) - aborting. [ 3.880455] pci 0000:00:1c.0: PCI bridge to [bus 01] [ 3.880491] pci 0000:00:1c.2: PCI bridge to [bus 02] [ 3.880504] pci 0000:00:1c.2: bridge window [mem 0xf7c00000-0xf7cfffff] [ 3.880528] pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7] [ 3.880530] pci_bus 0000:00: resource 5 [io 0x0d00-0xffff] [ 3.880533] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff] [ 3.880536] pci_bus 0000:00: resource 7 [mem 0x000d0000-0x000d3fff] [ 3.880538] pci_bus 0000:00: resource 8 [mem 0x000d4000-0x000d7fff] [ 3.880540] pci_bus 0000:00: resource 9 [mem 0x000d8000-0x000dbfff] [ 3.880543] pci_bus 0000:00: resource 10 [mem 0x000dc000-0x000dffff] [ 3.880545] pci_bus 0000:00: resource 11 [mem 0x000e0000-0x000e3fff] [ 3.880548] pci_bus 0000:00: resource 12 [mem 0x000e4000-0x000e7fff] [ 3.880550] pci_bus 0000:00: resource 13 [mem 0xdfa00000-0xfeafffff] [ 3.880553] pci_bus 0000:02: resource 1 [mem 0xf7c00000-0xf7cfffff] [ 3.880677] NET: Registered protocol family 2 [ 3.880981] TCP established hash table entries: 16384 (order: 5, 131072 bytes) [ 3.881065] TCP bind hash table entries: 16384 (order: 6, 262144 bytes) [ 3.881110] TCP: Hash tables configured (established 16384 bind 16384) [ 3.881132] TCP: reno registered [ 3.881143] UDP hash table entries: 1024 (order: 3, 32768 bytes) [ 3.881159] UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes) [ 3.881248] NET: Registered protocol family 1 [ 3.881270] pci 0000:00:02.0: Boot video device [ 3.881395] xen: registering gsi 16 triggering 0 polarity 1 [ 3.881410] xen: --> pirq=16 -> irq=16 (gsi=16) [ 3.881755] xen: registering gsi 16 triggering 0 polarity 1 [ 3.881758] Already setup the GSI :16 [ 3.898924] xen: registering gsi 23 triggering 0 polarity 1 [ 3.898934] xen: --> pirq=23 -> irq=23 (gsi=23) [ 3.918993] PCI: CLS 64 bytes, default 64 [ 3.919072] Trying to unpack rootfs image as initramfs... [ 3.942014] Freeing initrd memory: 18760K (ffff880002541000 - ffff880003793000) [ 3.943150] microcode: CPU0 sig=0x306a9, pf=0x10, revision=0x17 [ 3.943199] microcode: CPU1 sig=0x306a9, pf=0x10, revision=0x17 [ 3.943221] microcode: CPU2 sig=0x306a9, pf=0x10, revision=0x17 [ 3.943238] microcode: CPU3 sig=0x306a9, pf=0x10, revision=0x17 [ 3.943307] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba [ 3.953861] alg: No test for __gcm-aes-aesni (__driver-gcm-aes-aesni) [ 3.958651] sha1_ssse3: Using AVX optimized SHA-1 implementation [ 3.959037] audit: initializing netlink socket (disabled) [ 3.959053] type=2000 audit(1386787513.951:1): initialized [ 4.003787] bounce pool size: 64 pages [ 4.003794] HugeTLB registered 2 MB page size, pre-allocated 0 pages [ 4.004264] VFS: Disk quotas dquot_6.5.2 [ 4.004301] Dquot-cache hash table entries: 512 (order 0, 4096 bytes) [ 4.004851] FS-Cache: Netfs 'cifs' registered for caching [ 4.004926] Key type cifs.spnego registered [ 4.004936] Key type cifs.idmap registered [ 4.004940] NTFS driver 2.1.30 [Flags: R/W]. [ 4.005082] fuse init (API version 7.22) [ 4.005294] bio: create slab <bio-1> at 1 [ 4.005544] Btrfs loaded [ 4.005557] msgmni has been set to 2849 [ 4.011893] alg: No test for stdrng (krng) [ 4.018059] alg: No test for fips(ansi_cprng) (fips_ansi_cprng) [ 4.018164] NET: Registered protocol family 38 [ 4.018198] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249) [ 4.018201] io scheduler noop registered [ 4.018203] io scheduler deadline registered [ 4.018234] io scheduler cfq registered (default) [ 4.018465] xen: registering gsi 16 triggering 0 polarity 1 [ 4.018470] Already setup the GSI :16 [ 4.018845] xen: registering gsi 18 triggering 0 polarity 1 [ 4.018858] xen: --> pirq=18 -> irq=18 (gsi=18) [ 4.019173] pcieport 0000:00:1c.0: Signaling PME through PCIe PME interrupt [ 4.019186] pcie_pme 0000:00:1c.0:pcie01: service driver pcie_pme loaded [ 4.019229] pcieport 0000:00:1c.2: Signaling PME through PCIe PME interrupt [ 4.019231] pci 0000:02:00.0: Signaling PME through PCIe PME interrupt [ 4.019243] pcie_pme 0000:00:1c.2:pcie01: service driver pcie_pme loaded [ 4.019260] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [ 4.019277] pciehp: PCI Express Hot Plug Controller Driver version: 0.4 [ 4.019279] cpcihp_zt5550: ZT5550 CompactPCI Hot Plug Driver version: 0.2 [ 4.019294] cpcihp_generic: Generic port I/O CompactPCI Hot Plug Driver version: 0.1 [ 4.019296] cpcihp_generic: not configured, disabling. [ 4.019312] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 [ 4.021097] acpiphp_ibm: ibm_acpiphp_init: acpi_walk_namespace failed [ 4.021148] vmlfb: initializing [ 4.021332] uvesafb: failed to execute /sbin/v86d [ 4.021336] uvesafb: make sure that the v86d helper is installed and executable [ 4.021340] uvesafb: Getting VBE info block failed (eax=0x4f00, err=-2) [ 4.021343] uvesafb: vbe_init() failed with -22 [ 4.021349] uvesafb: probe of uvesafb.0 failed with error -22 [ 4.021363] vesafb: mode is 1280x1024x32, linelength=5120, pages=0 [ 4.021365] vesafb: scrolling: redraw [ 4.021367] vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0 [ 4.023186] vesafb: framebuffer at 0xe0000000, mapped to 0xffffc90004480000, using 10240k, total 32704k [ 4.142774] Console: switching to colour frame buffer device 160x64 [ 4.262244] fb0: VESA VGA frame buffer device [ 4.262360] vga16fb: initializing [ 4.262365] vga16fb: mapped to 0xffff8800000a0000 [ 4.262370] checking generic (e0000000 1ff0000) vs hw (a0000 10000) [ 4.262453] fb1: VGA16 VGA frame buffer device [ 4.262461] intel_idle: MWAIT substates: 0x21120 [ 4.262463] intel_idle: v0.4 model 0x3A [ 4.262464] intel_idle: lapic_timer_reliable_states 0xffffffff [ 4.262537] intel_idle: intel_idle yielding to none [ 4.262548] ipmi message handler version 39.2 [ 4.262554] ipmi device interface [ 4.262569] IPMI System Interface driver. [ 4.262597] ipmi_si: Adding default-specified kcs state machine [ 4.262601] ipmi_si: Trying default-specified kcs state machine at i/o address 0xca2, slave address 0x0, irq 0 [ 4.262610] ipmi_si: Interface detection failed [ 4.294780] ipmi_si: Adding default-specified smic state machine [ 4.294790] ipmi_si: Trying default-specified smic state machine at i/o address 0xca9, slave address 0x0, irq 0 [ 4.294806] ipmi_si: Interface detection failed [ 4.342773] ipmi_si: Adding default-specified bt state machine [ 4.342781] ipmi_si: Trying default-specified bt state machine at i/o address 0xe4, slave address 0x0, irq 0 [ 4.342797] ipmi_si: Interface detection failed [ 4.390804] ipmi_si: Unable to find any System Interface(s) [ 4.390812] IPMI Watchdog: driver initialized [ 4.390813] Copyright (C) 2004 MontaVista Software - IPMI Powerdown via sys_reboot. [ 4.391795] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input0 [ 4.391804] ACPI: Power Button [PWRB] [ 4.391861] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1 [ 4.391866] ACPI: Power Button [PWRF] [ 4.391986] ACPI: Fan [FAN0] (off) [ 4.392031] ACPI: Fan [FAN1] (off) [ 4.392074] ACPI: Fan [FAN2] (off) [ 4.392115] ACPI: Fan [FAN3] (off) [ 4.392154] ACPI: Fan [FAN4] (off) [ 4.439122] Monitor-Mwait will be used to enter C-1 state [ 4.439134] Monitor-Mwait will be used to enter C-2 state [ 4.440269] Warning: Processor Platform Limit not supported. [ 4.487195] thermal LNXTHERM:00: registered as thermal_zone0 [ 4.487199] ACPI: Thermal Zone [TZ00] (28 C) [ 4.487491] thermal LNXTHERM:01: registered as thermal_zone1 [ 4.487493] ACPI: Thermal Zone [TZ01] (30 C) [ 4.487574] Error: Driver 'processor_aggregator' is already registered, aborting... [ 4.488608] GHES: HEST is not enabled! [ 4.488610] ioatdma: Intel(R) QuickData Technology Driver 4.00 [ 4.488942] xen:xen_evtchn: Event-channel device installed [ 4.489146] xen_pciback: backend is vpci [ 4.489771] xen_acpi_processor: Uploading Xen processor PM info [ 4.491569] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [ 4.492239] xen: registering gsi 19 triggering 0 polarity 1 [ 4.492254] xen: --> pirq=19 -> irq=19 (gsi=19) [ 4.513108] 0000:00:16.3: ttyS0 at I/O 0xf0e0 (irq = 19, base_baud = 115200) is a 16550A [ 4.513299] hpet_acpi_add: no address or irqs in _CRS [ 4.513353] Non-volatile memory driver v1.3 [ 4.513420] Linux agpgart interface v0.103 [ 4.513460] Hangcheck: starting hangcheck timer 0.9.1 (tick is 180 seconds, margin is 60 seconds). [ 4.513461] Hangcheck: Using getrawmonotonic(). [ 4.513557] tpm_tis 00:09: 1.2 TPM (device-id 0x0, rev-id 78) [ 4.571021] [drm] Initialized drm 1.1.0 20060810 [ 4.571078] drm/i810 does not support SMP [ 4.572597] xen: registering gsi 16 triggering 0 polarity 1 [ 4.572608] Already setup the GSI :16 [ 4.572618] [drm:drm_pci_agp_init] *ERROR* Cannot initialize the agpgart module. [ 4.579164] brd: module loaded [ 4.580489] loop: module loaded [ 4.580701] nbd: registered device at major 43 [ 4.584499] drbd: initialized. Version: 8.4.3 (api:1/proto:86-101) [ 4.584502] drbd: built-in [ 4.584504] drbd: registered as block device major 147 [ 4.584617] xen: registering gsi 16 triggering 0 polarity 1 [ 4.584620] Already setup the GSI :16 [ 4.588781] ACPI Warning: 0x0000000000000428-0x000000000000042f SystemIO conflicts with Region \PMIO 1 (20131115/utaddress-251) [ 4.588785] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [ 4.588792] ACPI Warning: 0x0000000000000530-0x000000000000053f SystemIO conflicts with Region \GPIO 1 (20131115/utaddress-251) [ 4.588795] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [ 4.588796] ACPI Warning: 0x0000000000000500-0x000000000000052f SystemIO conflicts with Region \GPIO 1 (20131115/utaddress-251) [ 4.588798] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [ 4.588799] lpc_ich: Resource conflict(s) found affecting gpio_ich [ 4.588825] Loading iSCSI transport class v2.0-870. [ 4.588945] hv_vmbus: registering driver hv_storvsc [ 4.589015] ahci 0000:00:1f.2: version 3.0 [ 4.589085] xen: registering gsi 19 triggering 0 polarity 1 [ 4.589087] Already setup the GSI :19 [ 4.589192] ahci 0000:00:1f.2: AHCI 0001.0300 32 slots 6 ports 6 Gbps 0x1 impl SATA mode [ 4.589196] ahci 0000:00:1f.2: flags: 64bit ncq pm led clo pio slum part ems apst [ 4.589627] scsi0 : ahci [ 4.589756] scsi1 : ahci [ 4.589826] scsi2 : ahci [ 4.589944] scsi3 : ahci [ 4.590024] scsi4 : ahci [ 4.590093] scsi5 : ahci [ 4.590136] ata1: SATA max UDMA/133 abar m2048@0xf7d36000 port 0xf7d36100 irq 70 [ 4.590138] ata2: DUMMY [ 4.590139] ata3: DUMMY [ 4.590140] ata4: DUMMY [ 4.590141] ata5: DUMMY [ 4.590141] ata6: DUMMY [ 4.590256] bonding: Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011) [ 4.590696] eql: Equalizer2002: Simon Janes (simon@ncm.com) and David S. Miller (davem@redhat.com) [ 4.591102] libphy: Fixed MDIO Bus: probed [ 4.591176] tun: Universal TUN/TAP device driver, 1.6 [ 4.591177] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com> [ 4.591277] e100: Intel(R) PRO/100 Network Driver, 3.5.24-k2-NAPI [ 4.591278] e100: Copyright(c) 1999-2006 Intel Corporation [ 4.591296] e1000: Intel(R) PRO/1000 Network Driver - version 7.3.21-k8-NAPI [ 4.591297] e1000: Copyright (c) 1999-2006 Intel Corporation. [ 4.591309] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k [ 4.591310] e1000e: Copyright(c) 1999 - 2013 Intel Corporation. [ 4.591404] xen: registering gsi 20 triggering 0 polarity 1 [ 4.591417] xen: --> pirq=20 -> irq=20 (gsi=20) [ 4.591541] e1000e 0000:00:19.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode [ 4.799346] e1000e 0000:00:19.0 eth0: registered PHC clock [ 4.799350] e1000e 0000:00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) ec:a8:6b:fa:7b:3c [ 4.799351] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection [ 4.799403] e1000e 0000:00:19.0 eth0: MAC: 10, PHY: 11, PBA No: FFFFFF-0FF [ 4.799418] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.0.5-k [ 4.799419] igb: Copyright (c) 2007-2013 Intel Corporation. [ 4.799431] igbvf: Intel(R) Gigabit Virtual Function Network Driver - version 2.0.2-k [ 4.799432] igbvf: Copyright (c) 2009 - 2012 Intel Corporation. [ 4.799441] ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver - version 3.15.1-k [ 4.799442] ixgbe: Copyright (c) 1999-2013 Intel Corporation. [ 4.799457] ixgbevf: Intel(R) 10 Gigabit PCI Express Virtual Function Network Driver - version 2.11.3-k [ 4.799458] ixgbevf: Copyright (c) 2009 - 2012 Intel Corporation. [ 4.799467] ixgb: Intel(R) PRO/10GbE Network Driver - version 1.0.135-k2-NAPI [ 4.799468] ixgb: Copyright (c) 1999-2008 Intel Corporation. [ 4.799501] ipw2100: Intel(R) PRO/Wireless 2100 Network Driver, git-1.2.2 [ 4.799502] ipw2100: Copyright(c) 2003-2006 Intel Corporation [ 4.799513] ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, 1.2.2kq [ 4.799514] ipw2200: Copyright(c) 2003-2006 Intel Corporation [ 4.799527] libipw: 802.11 data/management/control stack, git-1.1.13 [ 4.799528] libipw: Copyright (C) 2004-2005 Intel Corporation <jketreno@linux.intel.com> [ 4.799529] Intel(R) Wireless WiFi driver for Linux, in-tree: [ 4.799530] Copyright(c) 2003-2013 Intel Corporation [ 4.799644] xen: registering gsi 18 triggering 0 polarity 1 [ 4.799647] Already setup the GSI :18 [ 4.800479] iwlwifi 0000:02:00.0: loaded firmware version 18.168.6.1 op_mode iwldvm [ 4.800532] iwlwifi 0000:02:00.0: CONFIG_IWLWIFI_DEBUG disabled [ 4.800534] iwlwifi 0000:02:00.0: CONFIG_IWLWIFI_DEBUGFS disabled [ 4.800536] iwlwifi 0000:02:00.0: CONFIG_IWLWIFI_DEVICE_TRACING disabled [ 4.800539] iwlwifi 0000:02:00.0: Detected Intel(R) Centrino(R) Advanced-N 6235 AGN, REV=0xB0 [ 4.800794] iwlwifi 0000:02:00.0: L1 Disabled; Enabling L0S [ 4.818467] cfg80211: Ignoring regulatory request set by core since the driver uses its own custom regulatory domain [ 4.818566] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs' [ 4.818709] iwl4965: Intel(R) Wireless WiFi 4965 driver for Linux, in-tree: [ 4.818710] iwl4965: Copyright(c) 2003-2011 Intel Corporation [ 4.818727] iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, in-tree:s [ 4.818728] iwl3945: Copyright(c) 2003-2011 Intel Corporation [ 4.818737] xen_netfront: Initialising Xen virtual ethernet driver [ 4.818805] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 4.818806] ehci-pci: EHCI PCI platform driver [ 4.818905] xen: registering gsi 16 triggering 0 polarity 1 [ 4.818908] Already setup the GSI :16 [ 4.818939] ehci-pci 0000:00:1a.0: EHCI Host Controller [ 4.819035] ehci-pci 0000:00:1a.0: new USB bus registered, assigned bus number 1 [ 4.819058] ehci-pci 0000:00:1a.0: debug port 2 [ 4.822983] ehci-pci 0000:00:1a.0: cache line size of 64 is not supported [ 4.823030] ehci-pci 0000:00:1a.0: irq 16, io mem 0xf7d38000 [ 4.834795] ehci-pci 0000:00:1a.0: USB 2.0 started, EHCI 1.00 [ 4.834867] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [ 4.834870] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 4.834872] usb usb1: Product: EHCI Host Controller [ 4.834873] usb usb1: Manufacturer: Linux 3.13.0-rc3-20131211b+ ehci_hcd [ 4.834875] usb usb1: SerialNumber: 0000:00:1a.0 [ 4.835158] hub 1-0:1.0: USB hub found [ 4.835168] hub 1-0:1.0: 3 ports detected [ 4.835421] xen: registering gsi 23 triggering 0 polarity 1 [ 4.835426] Already setup the GSI :23 [ 4.835465] ehci-pci 0000:00:1d.0: EHCI Host Controller [ 4.835635] ehci-pci 0000:00:1d.0: new USB bus registered, assigned bus number 2 [ 4.835659] ehci-pci 0000:00:1d.0: debug port 2 [ 4.839615] ehci-pci 0000:00:1d.0: cache line size of 64 is not supported [ 4.839662] ehci-pci 0000:00:1d.0: irq 23, io mem 0xf7d37000 [ 4.850709] ehci-pci 0000:00:1d.0: USB 2.0 started, EHCI 1.00 [ 4.850811] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002 [ 4.850816] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 4.850820] usb usb2: Product: EHCI Host Controller [ 4.850824] usb usb2: Manufacturer: Linux 3.13.0-rc3-20131211b+ ehci_hcd [ 4.850828] usb usb2: SerialNumber: 0000:00:1d.0 [ 4.851134] hub 2-0:1.0: USB hub found [ 4.851150] hub 2-0:1.0: 3 ports detected [ 4.851453] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 4.851456] ohci-pci: OHCI PCI platform driver [ 4.851483] ohci-platform: OHCI generic platform driver [ 4.851503] uhci_hcd: USB Universal Host Controller Interface driver [ 4.851806] xen: registering gsi 16 triggering 0 polarity 1 [ 4.851812] Already setup the GSI :16 [ 4.851942] xhci_hcd 0000:00:14.0: xHCI Host Controller [ 4.852117] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 3 [ 4.852270] xhci_hcd 0000:00:14.0: cache line size of 64 is not supported [ 4.852524] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002 [ 4.852529] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 4.852533] usb usb3: Product: xHCI Host Controller [ 4.852537] usb usb3: Manufacturer: Linux 3.13.0-rc3-20131211b+ xhci_hcd [ 4.852540] usb usb3: SerialNumber: 0000:00:14.0 [ 4.852833] hub 3-0:1.0: USB hub found [ 4.852854] hub 3-0:1.0: 4 ports detected [ 4.853612] xhci_hcd 0000:00:14.0: xHCI Host Controller [ 4.853742] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 4 [ 4.853837] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003 [ 4.853842] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 4.853845] usb usb4: Product: xHCI Host Controller [ 4.853849] usb usb4: Manufacturer: Linux 3.13.0-rc3-20131211b+ xhci_hcd [ 4.853853] usb usb4: SerialNumber: 0000:00:14.0 [ 4.854135] hub 4-0:1.0: USB hub found [ 4.854157] hub 4-0:1.0: 4 ports detected [ 4.886974] usbcore: registered new interface driver usb-storage [ 4.887087] i8042: PNP: No PS/2 controller found. Probing ports directly. [ 4.906670] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 5.934234] ata1.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded [ 5.934239] ata1.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out [ 5.934242] ata1.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out [ 5.935137] i8042: No controller found [ 5.935486] hv_vmbus: registering driver hyperv_keyboard [ 5.935493] ata1.00: supports DRM functions and may not be fully accessible [ 5.935663] mousedev: PS/2 mouse device common for all mice [ 5.935863] rtc_cmos 00:04: RTC can wake from S4 [ 5.936179] rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0 [ 5.936294] rtc_cmos 00:04: alarms up to one month, y3k, 242 bytes nvram [ 5.936636] i2c /dev entries driver [ 5.937084] xen: registering gsi 18 triggering 0 polarity 1 [ 5.937094] Already setup the GSI :18 [ 5.937102] ACPI Warning: 0x000000000000f040-0x000000000000f05f SystemIO conflicts with Region \_SB_.PCI0.SBUS.SMBI 1 (20131115/utaddress-251) [ 5.937115] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [ 5.937342] pps_ldisc: PPS line discipline registered [ 5.938291] w83627ehf: Found NCT6776F chip at 0xa30 [ 5.938473] ata1.00: ATA-9: Crucial_CT120M500SSD3, MU03, max UDMA/133 [ 5.938475] ata1.00: 234441648 sectors, multi 16: LBA48 NCQ (depth 31/32), AA [ 5.939454] sp5100_tco: SP5100/SB800 TCO WatchDog Timer Driver v0.05 [ 5.939561] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.10 [ 5.939624] iTCO_wdt: Found a Panther Point TCO device (Version=2, TCOBASE=0x0460) [ 5.939747] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) [ 5.939761] iTCO_vendor_support: vendor-support=0 [ 5.939764] xen_wdt: Xen WatchDog Timer Driver v0.01 [ 5.939821] xen_wdt: cannot register miscdev on minor=130 (-16) [ 5.940566] wdt: probe of wdt failed with error -16 [ 5.940586] softdog: Software Watchdog Timer: 0.08 initialized. soft_noboot=0 soft_margin=60 sec soft_panic=0 (nowayout=0) [ 5.940647] device-mapper: uevent: version 1.0.3 [ 5.940696] device-mapper: ioctl: 4.27.0-ioctl (2013-10-30) initialised: dm-devel@redhat.com [ 5.940799] Intel P-state driver initializing. [ 5.940832] leds_ss4200: no LED devices found [ 5.940851] hidraw: raw HID events driver (C) Jiri Kosina [ 5.940934] usbcore: registered new interface driver usbhid [ 5.940935] usbhid: USB HID core driver [ 5.940938] hv_utils: Registering HyperV Utility Driver [ 5.940939] hv_vmbus: registering driver hv_util [ 5.940992] usbcore: registered new interface driver snd-usb-audio [ 5.941002] usbcore: registered new interface driver snd-ua101 [ 5.941011] usbcore: registered new interface driver snd-usb-usx2y [ 5.941020] usbcore: registered new interface driver snd-usb-us122l [ 5.941030] usbcore: registered new interface driver snd-usb-caiaq [ 5.941039] usbcore: registered new interface driver snd-usb-6fire [ 5.941048] usbcore: registered new interface driver snd-usb-hiface [ 5.941076] drop_monitor: Initializing network drop monitor service [ 5.941096] GACT probability on [ 5.941098] Mirror/redirect action on [ 5.941099] Simple TC action Loaded [ 5.941181] netem: version 1.3 [ 5.941183] u32 classifier [ 5.941184] Performance counters on [ 5.941185] input device check on [ 5.941186] Actions configured [ 5.941189] Netfilter messages via NETLINK v0.30. [ 5.941192] nfnl_acct: registering with nfnetlink. [ 5.941201] nf_conntrack version 0.5.0 (16384 buckets, 65536 max) [ 5.941274] ctnetlink v0.93: registering with nfnetlink. [ 5.941325] xt_time: kernel timezone is -0000 [ 5.941328] ip_set: protocol 6 [ 5.941334] IPVS: Registered protocols (TCP, UDP, SCTP, AH, ESP) [ 5.941352] IPVS: Connection hash table configured (size=4096, memory=64Kbytes) [ 5.941387] IPVS: Creating netns size=2048 id=0 [ 5.941395] IPVS: ipvs loaded. [ 5.941396] IPVS: [rr] scheduler registered. [ 5.941398] IPVS: [wrr] scheduler registered. [ 5.941399] IPVS: [lc] scheduler registered. [ 5.941400] IPVS: [wlc] scheduler registered. [ 5.941403] IPVS: [lblc] scheduler registered. [ 5.941405] IPVS: [lblcr] scheduler registered. [ 5.941406] IPVS: [dh] scheduler registered. [ 5.941407] IPVS: [sh] scheduler registered. [ 5.941408] IPVS: [sed] scheduler registered. [ 5.941409] IPVS: [nq] scheduler registered. [ 5.941479] ip_tables: (C) 2000-2006 Netfilter Core Team [ 5.941511] ipt_CLUSTERIP: ClusterIP Version 0.8 loaded successfully [ 5.941520] arp_tables: (C) 2002 David S. Miller [ 5.941529] TCP: cubic registered [ 5.941530] Initializing XFRM netlink socket [ 5.941534] NET: Registered protocol family 17 [ 5.941539] NET: Registered protocol family 15 [ 5.941557] Ebtables v2.0 registered [ 5.942238] ata1.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded [ 5.942241] ata1.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out [ 5.942243] ata1.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out [ 5.942512] ata1.00: supports DRM functions and may not be fully accessible [ 5.948733] ata1.00: configured for UDMA/133 [ 5.948845] scsi 0:0:0:0: Direct-Access ATA Crucial_CT120M50 MU03 PQ: 0 ANSI: 5 [ 5.948951] sd 0:0:0:0: [sda] 234441648 512-byte logical blocks: (120 GB/111 GiB) [ 5.948954] sd 0:0:0:0: [sda] 4096-byte physical blocks [ 5.948987] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 5.948999] sd 0:0:0:0: [sda] Write Protect is off [ 5.949001] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 5.949017] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 5.949565] sda: sda1 [ 5.949754] sd 0:0:0:0: [sda] Attached SCSI disk [ 5.974854] NET: Registered protocol family 33 [ 5.974862] Key type rxrpc registered [ 5.974866] Key type rxrpc_s registered [ 5.974881] 8021q: 802.1Q VLAN Support v1.8 [ 5.974898] lib80211: common routines for IEEE802.11 drivers [ 5.974903] lib80211_crypt: registered algorithm 'NULL' [ 5.974906] lib80211_crypt: registered algorithm 'WEP' [ 5.974910] lib80211_crypt: registered algorithm 'CCMP' [ 5.974913] lib80211_crypt: registered algorithm 'TKIP' [ 5.974931] Key type dns_resolver registered [ 5.975833] registered taskstats version 1 [ 5.976952] console [netcon0] enabled [ 5.976956] netconsole: network logging started [ 5.977102] rtc_cmos 00:04: setting system clock to 2013-12-11 18:45:15 UTC (1386787515) [ 5.977134] BIOS EDD facility v0.16 2004-Jun-25, 1 devices found [ 5.977300] ALSA device list: [ 5.977303] No soundcards found. [ 5.978750] Freeing unused kernel memory: 1148K (ffffffff81f21000 - ffffffff82040000) [ 5.978755] Write protecting the kernel read-only data: 14336k [ 5.983817] Freeing unused kernel memory: 1048K (ffff8800018fa000 - ffff880001a00000) [ 5.983994] Freeing unused kernel memory: 376K (ffff880001da2000 - ffff880001e00000) [ 6.017549] udevd[193]: starting version 175 [ 6.146730] usb 1-1: new high-speed USB device number 2 using ehci-pci [ 6.279084] usb 1-1: New USB device found, idVendor=8087, idProduct=0024 [ 6.279094] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 6.279587] hub 1-1:1.0: USB hub found [ 6.279726] hub 1-1:1.0: 6 ports detected [ 6.319191] microcode: CPU0 sig=0x306a9, pf=0x10, revision=0x17 [ 6.319238] microcode: CPU0 update to revision 0x19 failed [ 6.320942] microcode: CPU1 sig=0x306a9, pf=0x10, revision=0x17 [ 6.320976] microcode: CPU1 update to revision 0x19 failed [ 6.322440] microcode: CPU2 sig=0x306a9, pf=0x10, revision=0x17 [ 6.322470] microcode: CPU2 update to revision 0x19 failed [ 6.324069] microcode: CPU3 sig=0x306a9, pf=0x10, revision=0x17 [ 6.324100] microcode: CPU3 update to revision 0x19 failed [ 6.347692] random: lvm urandom read with 60 bits of entropy available [ 6.383370] bio: create slab <bio-2> at 2 [ 6.390728] usb 2-1: new high-speed USB device number 2 using ehci-pci [ 6.506026] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null) [ 6.523081] usb 2-1: New USB device found, idVendor=8087, idProduct=0024 [ 6.523085] usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 6.523351] hub 2-1:1.0: USB hub found [ 6.523451] hub 2-1:1.0: 8 ports detected [ 6.638729] usb 3-3: new full-speed USB device number 2 using xhci_hcd [ 6.655338] usb 3-3: New USB device found, idVendor=0d8c, idProduct=000e [ 6.655341] usb 3-3: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [ 6.655343] usb 3-3: Product: Generic USB Audio Device [ 6.730881] usb 1-1.1: new full-speed USB device number 3 using ehci-pci [ 6.815349] udevd[479]: starting version 175 [ 6.827654] usb 1-1.1: New USB device found, idVendor=8087, idProduct=07da [ 6.827666] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 6.899735] random: nonblocking pool is initialized [ 7.819809] EXT4-fs (dm-0): re-mounted. Opts: (null) [ 7.919273] EXT4-fs (dm-0): re-mounted. Opts: discard,errors=remount-ro [ 8.863934] Adding 1949692k swap on /dev/mapper/creabox-creabox_swap. Priority:-1 extents:1 across:1949692k SS [ 11.540793] e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx [ 11.540799] e1000e 0000:00:19.0 eth0: 10/100 speed: disabling TSO [ 20.131091] iwlwifi 0000:02:00.0: L1 Disabled; Enabling L0S [ 20.138074] iwlwifi 0000:02:00.0: Radio type=0x2-0x1-0x0 [ 20.412347] iwlwifi 0000:02:00.0: L1 Disabled; Enabling L0S [ 20.419122] iwlwifi 0000:02:00.0: Radio type=0x2-0x1-0x0 [ 20.499225] device wlan0 entered promiscuous mode [ 20.502148] xen_bridge: port 1(wlan0) entered forwarding state [ 20.502156] xen_bridge: port 1(wlan0) entered forwarding state [ 20.502235] cfg80211: Pending regulatory request, waiting for it to be processed... [ 21.282880] device vif1.0 entered promiscuous mode [ 21.380304] device vif1.0-emu entered promiscuous mode [ 21.382287] xen_bridge: port 3(vif1.0-emu) entered forwarding state [ 21.382292] xen_bridge: port 3(vif1.0-emu) entered forwarding state [ 34.093695] xen-blkback:ring-ref 8, event-channel 25, protocol 2 (x86_32-abi) persistent grants [ 34.108097] xen-blkback:ring-ref 9, event-channel 26, protocol 2 (x86_32-abi) persistent grants [ 34.254371] xen_bridge: port 2(vif1.0) entered forwarding state [ 34.254405] xen_bridge: port 2(vif1.0) entered forwarding state [ 126.454516] cfg80211: Pending regulatory request, waiting for it to be processed... > Luis ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work. 2013-12-11 16:53 ` Sander Eikelenboom @ 2013-12-11 17:14 ` Luis R. Rodriguez 2013-12-11 17:28 ` Sander Eikelenboom 0 siblings, 1 reply; 38+ messages in thread From: Luis R. Rodriguez @ 2013-12-11 17:14 UTC (permalink / raw) To: Sander Eikelenboom Cc: Berg, Johannes, Grumbach, Emmanuel, linux-kernel@vger.kernel.org, ilw@linux.intel.com, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, John W. Linville On Wed, Dec 11, 2013 at 5:53 PM, Sander Eikelenboom <linux@eikelenboom.it> wrote: > > Wednesday, December 11, 2013, 4:38:13 PM, you wrote: > >> On Wed, Dec 11, 2013 at 4:17 PM, Sander Eikelenboom >> <linux@eikelenboom.it> wrote: >>> Since i haven't got a response to this yet and after having the troubled machine back: >>> The problem is still present in linux 3.13-rc3 > >> Keep in mind regulatory hints for Intel or Atheros cards do nothing >> other than help compliance further given that the cards already have >> their own regulatory data, the user input / hint is only going to >> reduce the card's channels further. > > So in essence what you are saying is that the firmware/eeprom already dictates the limited channels available based on .. errr .. yeah based on what ... Whatever the device was programmed with but in practice my understanding is Intel only sells hardware for a few regions so they have only a few custom world regulatory domains, so that is used upon initialization. Having the capability to actually work properly on a different set of regions with optimal power and performance without violating regulatory is a challenge and this is why cards are either region specific or built / optimized for a few regions or a general world roaming card. Channels is just one thing to consider, there are tons of other things to consider and this will be very card and hardware specific. > And setting the regulatory domain yourself only limits this list of limited channels available only further ? Yeap, that's the case for Intel Atheros, and I think nowadays new broadcom upstream drivers too. Users should not have to be involved on setting the regulatory domain, everything should just work automatically. > I now spotted this from the dmesg: > [ 4.818467] cfg80211: Ignoring regulatory request set by core since the driver uses its own custom regulatory domain Yeap, that's by design, if a card sets a flag that its has a custom world regulatory domain the first hint from CRDA / internel regdb that updates the world regulatory domain will bet set on cfg80211 but for the wiphy data structure for the drivers that have the custom flag set we'll skip using the regulatory domain for that card as it has its own custom regulatory domain. > Joy o joy who ever came up with that great idea .. Understand the architecture before making conclusions. > Would be nice it that error came up again when you would try to set the domain, instead of silently ignoring it. That is not an error message, its a head up and that would only apply for the first update of the world regulatory domain. The regulatory domain settings that a user would do next would be applied but like I said you'd be restricting the device further. > So now the only thing left is to try to find out if some one has hacked these bloody cards, what a mess. Feel free to hack the living hell out of things, go wild. > Do other cards like broadcom or whatever have the same issue ? This is a non-issue in so far as hardware is concerned, this is a regulatory thing, if you're unhappy you can lobby for ability to use the spectrum as you wish all over the world. That won't go well, but what may work well is if you can sign off on your responsibility for causing issues. This is important -- consider weather radar channels which are used on 5 GHz and are used to help with airplanes, you can't just take any hardware and go crazy anywhere. There are reasons for this. Upstream ships compliant solutions, what you do in your basement is up to you. >> That said the fact that you are >> not seeing a regulatory domain being set is an issue provided you have >> CRDA installed or use CONFIG_CFG80211_INTERNAL_REGDB. Keep in mind >> that the latest version of wireless-regdb had a signature issue >> reported by users and not sure if that is cleared yet, so that would >> also prevent the wireless-regdb being read even if CRDA was present. >> To rule that out try putting the db.txt into net/wireless/db.txt and >> compile with CONFIG_CFG80211_INTERNAL_REGDB for now. > > I did have CRDA installed (debian). > And also compiled the db.txt in. Can you verify that CRDA gets called? You should see something like this: [ 71.133856] cfg80211: Calling CRDA to update world regulatory domain [ 71.139098] cfg80211: World regulatory domain updated: [ 71.139102] cfg80211: DFS Master region: unset [ 71.139104] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [ 71.139106] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm) [ 71.139108] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm) [ 71.139110] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm) [ 71.139112] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz), (N/A, 2000 mBm) [ 71.139114] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm) [ 71.139115] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm) >> Then send the dmesg output, no need for all that fluffy intel debug >> log as its not useful in this case. > > Compiled with db.txt in: > > ~# iw reg set US > ~# iw reg get > country 00: > (2402 - 2472 @ 40), (6, 20) > (2457 - 2482 @ 40), (6, 20), PASSIVE-SCAN, NO-IBSS > (2474 - 2494 @ 20), (6, 20), NO-OFDM, PASSIVE-SCAN, NO-IBSS > (5170 - 5250 @ 160), (6, 20), PASSIVE-SCAN, NO-IBSS > (5250 - 5330 @ 160), (6, 20), DFS, PASSIVE-SCAN, NO-IBSS > (5490 - 5730 @ 160), (6, 20), DFS, PASSIVE-SCAN, NO-IBSS This can be from the static world regulatory domain in the kernel, it doesn't mean it came from CRDA. > [ 3.862108] cfg80211: Calling CRDA to update world regulatory domain <-- snip --> > [ 4.818467] cfg80211: Ignoring regulatory request set by core since the driver uses its own custom regulatory domain <-- snip --> > [ 20.502235] cfg80211: Pending regulatory request, waiting for it to be processed... <-- snip --> > [ 126.454516] cfg80211: Pending regulatory request, waiting for it to be processed... It doesn't seem like you are getting your original requests getting processed, so I don't think CRDA is passing it. Can you verify running from CRDA code: ./regdbdump /usr/lib/crda/regulatory.bin Luis ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work. 2013-12-11 17:14 ` Luis R. Rodriguez @ 2013-12-11 17:28 ` Sander Eikelenboom 2013-12-11 17:53 ` Luis R. Rodriguez 0 siblings, 1 reply; 38+ messages in thread From: Sander Eikelenboom @ 2013-12-11 17:28 UTC (permalink / raw) To: Luis R. Rodriguez Cc: Berg, Johannes, Grumbach, Emmanuel, linux-kernel@vger.kernel.org, ilw@linux.intel.com, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, John W. Linville Wednesday, December 11, 2013, 6:14:16 PM, you wrote: > On Wed, Dec 11, 2013 at 5:53 PM, Sander Eikelenboom > <linux@eikelenboom.it> wrote: >> >> Wednesday, December 11, 2013, 4:38:13 PM, you wrote: >> >>> On Wed, Dec 11, 2013 at 4:17 PM, Sander Eikelenboom >>> <linux@eikelenboom.it> wrote: >>>> Since i haven't got a response to this yet and after having the troubled machine back: >>>> The problem is still present in linux 3.13-rc3 >> >>> Keep in mind regulatory hints for Intel or Atheros cards do nothing >>> other than help compliance further given that the cards already have >>> their own regulatory data, the user input / hint is only going to >>> reduce the card's channels further. >> >> So in essence what you are saying is that the firmware/eeprom already dictates the limited channels available based on .. errr .. yeah based on what ... > Whatever the device was programmed with but in practice my > understanding is Intel only sells hardware for a few regions so they > have only a few custom world regulatory domains, so that is used upon > initialization. Having the capability to actually work properly on a > different set of regions with optimal power and performance without > violating regulatory is a challenge and this is why cards are either > region specific or built / optimized for a few regions or a general > world roaming card. Channels is just one thing to consider, there are > tons of other things to consider and this will be very card and > hardware specific. >> And setting the regulatory domain yourself only limits this list of limited channels available only further ? > Yeap, that's the case for Intel Atheros, and I think nowadays new > broadcom upstream drivers too. Users should not have to be involved on > setting the regulatory domain, everything should just work > automatically. Erhmm yes that works, under the assumption that the device is not leaving the country it was programmed for at the factory. (Or you like to be limited in your abilities, channel 12 and 13 are legal here) That there is a restriction on boot or on first use, i can understand. Crippling a device for it's life time though. >> I now spotted this from the dmesg: >> [ 4.818467] cfg80211: Ignoring regulatory request set by core since the driver uses its own custom regulatory domain > Yeap, that's by design, if a card sets a flag that its has a custom > world regulatory domain the first hint from CRDA / internel regdb that > updates the world regulatory domain will bet set on cfg80211 but for > the wiphy data structure for the drivers that have the custom flag set > we'll skip using the regulatory domain for that card as it has its own > custom regulatory domain. >> Joy o joy who ever came up with that great idea .. > Understand the architecture before making conclusions. >> Would be nice it that error came up again when you would try to set the domain, instead of silently ignoring it. > That is not an error message, its a head up and that would only apply > for the first update of the world regulatory domain. The regulatory > domain settings that a user would do next would be applied but like I > said you'd be restricting the device further. >> So now the only thing left is to try to find out if some one has hacked these bloody cards, what a mess. > Feel free to hack the living hell out of things, go wild. >> Do other cards like broadcom or whatever have the same issue ? > This is a non-issue in so far as hardware is concerned, this is a > regulatory thing, if you're unhappy you can lobby for ability to use > the spectrum as you wish all over the world. That won't go well, but > what may work well is if you can sign off on your responsibility for > causing issues. This is important -- consider weather radar channels > which are used on 5 GHz and are used to help with airplanes, you can't > just take any hardware and go crazy anywhere. There are reasons for > this. Upstream ships compliant solutions, what you do in your basement > is up to you. >>> That said the fact that you are >>> not seeing a regulatory domain being set is an issue provided you have >>> CRDA installed or use CONFIG_CFG80211_INTERNAL_REGDB. Keep in mind >>> that the latest version of wireless-regdb had a signature issue >>> reported by users and not sure if that is cleared yet, so that would >>> also prevent the wireless-regdb being read even if CRDA was present. >>> To rule that out try putting the db.txt into net/wireless/db.txt and >>> compile with CONFIG_CFG80211_INTERNAL_REGDB for now. >> >> I did have CRDA installed (debian). >> And also compiled the db.txt in. > Can you verify that CRDA gets called? You should see something like this: > [ 71.133856] cfg80211: Calling CRDA to update world regulatory domain > [ 71.139098] cfg80211: World regulatory domain updated: > [ 71.139102] cfg80211: DFS Master region: unset > [ 71.139104] cfg80211: (start_freq - end_freq @ bandwidth), > (max_antenna_gain, max_eirp) > [ 71.139106] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), > (N/A, 2000 mBm) > [ 71.139108] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), > (N/A, 2000 mBm) > [ 71.139110] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), > (N/A, 2000 mBm) > [ 71.139112] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz), > (N/A, 2000 mBm) > [ 71.139114] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), > (N/A, 2000 mBm) > [ 71.139115] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 > KHz), (N/A, 0 mBm) >>> Then send the dmesg output, no need for all that fluffy intel debug >>> log as its not useful in this case. >> >> Compiled with db.txt in: >> >> ~# iw reg set US >> ~# iw reg get >> country 00: >> (2402 - 2472 @ 40), (6, 20) >> (2457 - 2482 @ 40), (6, 20), PASSIVE-SCAN, NO-IBSS >> (2474 - 2494 @ 20), (6, 20), NO-OFDM, PASSIVE-SCAN, NO-IBSS >> (5170 - 5250 @ 160), (6, 20), PASSIVE-SCAN, NO-IBSS >> (5250 - 5330 @ 160), (6, 20), DFS, PASSIVE-SCAN, NO-IBSS >> (5490 - 5730 @ 160), (6, 20), DFS, PASSIVE-SCAN, NO-IBSS > This can be from the static world regulatory domain in the kernel, it > doesn't mean it came from CRDA. >> [ 3.862108] cfg80211: Calling CRDA to update world regulatory domain > <-- snip --> >> [ 4.818467] cfg80211: Ignoring regulatory request set by core since the driver uses its own custom regulatory domain > <-- snip --> >> [ 20.502235] cfg80211: Pending regulatory request, waiting for it to be processed... > <-- snip --> >> [ 126.454516] cfg80211: Pending regulatory request, waiting for it to be processed... > It doesn't seem like you are getting your original requests getting > processed, so I don't think CRDA is passing it. Can you verify running > from CRDA code: They don't get processed unless i remove the return from the code as i indicated. If i remove that return it processes the request. > ./regdbdump /usr/lib/crda/regulatory.bin Although it's in a different location on Debian, /lib/crda/regulatory.bin the dump seems fine. > Luis ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work. 2013-12-11 17:28 ` Sander Eikelenboom @ 2013-12-11 17:53 ` Luis R. Rodriguez 2013-12-11 18:02 ` Luis R. Rodriguez 2013-12-11 18:11 ` Sander Eikelenboom 0 siblings, 2 replies; 38+ messages in thread From: Luis R. Rodriguez @ 2013-12-11 17:53 UTC (permalink / raw) To: Sander Eikelenboom Cc: Berg, Johannes, Grumbach, Emmanuel, linux-kernel@vger.kernel.org, ilw@linux.intel.com, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, John W. Linville On Wed, Dec 11, 2013 at 6:28 PM, Sander Eikelenboom <linux@eikelenboom.it> wrote: > Wednesday, December 11, 2013, 6:14:16 PM, you wrote: >> Yeap, that's the case for Intel Atheros, and I think nowadays new >> broadcom upstream drivers too. Users should not have to be involved on >> setting the regulatory domain, everything should just work >> automatically. > > Erhmm yes that works, under the assumption that the device is not leaving the country it was programmed for at the factory. Moving out of a region that you purchased a device is called to "world roam". Believe it or not some devices are designed with the intent you do not take it out of a country. The Playstation comes to mind as an example but I believe some Apple tablets are also in the same situation. Some devices like mobile phones obviously need to support world roaming and they do, what they do then is build architecture to support a base set and then rely on your APs around to see the country IE to determine region. Some other devices rely on cellular base station information, but that is allowed only in a few countries right now and in the US at least this requires some sort of special review from FCC on the design. We support all this in the Linux kernel today, its up to system integrators to do things and certify things properly. > (Or you like to be limited in your abilities, channel 12 and 13 are legal here) > That there is a restriction on boot or on first use, i can understand. Crippling a device for it's life time though. The best way to address all this is by automatic region awareness and doing the right thing on devices, this however requires good architecture / calibration data / etc and all that needs to be verified by the system integrators, and finally they need to be certified. If you want to hack your firmware and software go at it, just be aware there are reasons for things. >> It doesn't seem like you are getting your original requests getting >> processed, so I don't think CRDA is passing it. Can you verify running >> from CRDA code: > > They don't get processed unless i remove the return from the code as i indicated. > If i remove that return it processes the request. > >> ./regdbdump /usr/lib/crda/regulatory.bin > > Although it's in a different location on Debian, /lib/crda/regulatory.bin > the dump seems fine. OK thanks. Can you send a patch of what exact change you made, it was unclear from the paste you made. diff -u file.c.orig file.c Luis ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work. 2013-12-11 17:53 ` Luis R. Rodriguez @ 2013-12-11 18:02 ` Luis R. Rodriguez 2013-12-11 18:11 ` Sander Eikelenboom 1 sibling, 0 replies; 38+ messages in thread From: Luis R. Rodriguez @ 2013-12-11 18:02 UTC (permalink / raw) To: Sander Eikelenboom Cc: Berg, Johannes, Grumbach, Emmanuel, linux-kernel@vger.kernel.org, ilw@linux.intel.com, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, John W. Linville Also can you try with wireless-testing ? Luis ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work. 2013-12-11 17:53 ` Luis R. Rodriguez 2013-12-11 18:02 ` Luis R. Rodriguez @ 2013-12-11 18:11 ` Sander Eikelenboom 2013-12-11 18:38 ` Luis R. Rodriguez 1 sibling, 1 reply; 38+ messages in thread From: Sander Eikelenboom @ 2013-12-11 18:11 UTC (permalink / raw) To: Luis R. Rodriguez Cc: Berg, Johannes, Grumbach, Emmanuel, linux-kernel@vger.kernel.org, ilw@linux.intel.com, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, John W. Linville Wednesday, December 11, 2013, 6:53:07 PM, you wrote: > On Wed, Dec 11, 2013 at 6:28 PM, Sander Eikelenboom > <linux@eikelenboom.it> wrote: >> Wednesday, December 11, 2013, 6:14:16 PM, you wrote: >>> Yeap, that's the case for Intel Atheros, and I think nowadays new >>> broadcom upstream drivers too. Users should not have to be involved on >>> setting the regulatory domain, everything should just work >>> automatically. >> >> Erhmm yes that works, under the assumption that the device is not leaving the country it was programmed for at the factory. > Moving out of a region that you purchased a device is called to "world > roam". Believe it or not some devices are designed with the intent you > do not take it out of a country. The Playstation comes to mind as an > example but I believe some Apple tablets are also in the same > situation. Some devices like mobile phones obviously need to support > world roaming and they do, what they do then is build architecture to > support a base set and then rely on your APs around to see the country > IE to determine region. Some other devices rely on cellular base > station information, but that is allowed only in a few countries right > now and in the US at least this requires some sort of special review > from FCC on the design. We support all this in the Linux kernel today, > its up to system integrators to do things and certify things properly. >> (Or you like to be limited in your abilities, channel 12 and 13 are legal here) >> That there is a restriction on boot or on first use, i can understand. Crippling a device for it's life time though. > The best way to address all this is by automatic region awareness and > doing the right thing on devices, this however requires good > architecture / calibration data / etc and all that needs to be > verified by the system integrators, and finally they need to be > certified. If you want to hack your firmware and software go at it, > just be aware there are reasons for things. Well the general problem seems to be "we don't trust the user" so we FORCE him to the lowest common denominator (without a way to overrule that) so he is forced to operate *well* within the law. >>> It doesn't seem like you are getting your original requests getting >>> processed, so I don't think CRDA is passing it. Can you verify running >>> from CRDA code: >> >> They don't get processed unless i remove the return from the code as i indicated. >> If i remove that return it processes the request. >> >>> ./regdbdump /usr/lib/crda/regulatory.bin >> >> Although it's in a different location on Debian, /lib/crda/regulatory.bin >> the dump seems fine. > OK thanks. Can you send a patch of what exact change you made, it was > unclear from the paste you made. > diff -u file.c.orig file.c Well i just did a pull from wireless-next, to try Avinash Patil's patch. net/wireless/reg.c had already changed much so i couldn't apply his patch without. With his patch it sets the regulatory domain, although as now expected i still can not use channels 12 and 13 yet, probably due to those firmware restrictions. His patch is copy pasted below. > Luis ---------- Forwarded message ---------- From: "Avinash Patil" <patila@marvell.com> Date: Dec 6, 2013 8:31 PM Subject: [RFC] cfg80211: set regulatory request processed for initiator core To: <johannes@sipsolutions.net>, <linux-wireless@vger.kernel.org> Cc: During cfg80211 init, cfg80211 initializes regulatory to set to world domain. Here we dont set last request processed flag. This results into further request set to pending indefinitely. This patch fixes this by setting last request to processed. Signed-off-by: Avinash Patil <patila@marvell.com> --- net/wireless/reg.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/net/wireless/reg.c b/net/wireless/reg.c index ec54e1a..70a8f0a 100644 --- a/net/wireless/reg.c +++ b/net/wireless/reg.c @@ -1670,6 +1670,8 @@ static void reg_process_hint(struct regulatory_request *reg_request) switch (reg_request->initiator) { case NL80211_REGDOM_SET_BY_CORE: reg_process_hint_core(reg_request); + nl80211_send_reg_change_event(reg_request); + reg_set_request_processed(); return; case NL80211_REGDOM_SET_BY_USER: treatment = reg_process_hint_user(reg_request); -- 1.7.3.4 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply related [flat|nested] 38+ messages in thread
* Re: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work. 2013-12-11 18:11 ` Sander Eikelenboom @ 2013-12-11 18:38 ` Luis R. Rodriguez 2013-12-11 19:06 ` Sander Eikelenboom 2013-12-16 11:22 ` Sander Eikelenboom 0 siblings, 2 replies; 38+ messages in thread From: Luis R. Rodriguez @ 2013-12-11 18:38 UTC (permalink / raw) To: Sander Eikelenboom Cc: Berg, Johannes, Grumbach, Emmanuel, linux-kernel@vger.kernel.org, ilw@linux.intel.com, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, John W. Linville On Wed, Dec 11, 2013 at 7:11 PM, Sander Eikelenboom <linux@eikelenboom.it> wrote: > > Wednesday, December 11, 2013, 6:53:07 PM, you wrote: > >> The best way to address all this is by automatic region awareness and >> doing the right thing on devices, this however requires good >> architecture / calibration data / etc and all that needs to be >> verified by the system integrators, and finally they need to be >> certified. If you want to hack your firmware and software go at it, >> just be aware there are reasons for things. > > Well the general problem seems to be "we don't trust the user" so we FORCE him to the lowest > common denominator (without a way to overrule that) so he is forced to operate *well* within the law. Its simply stupid to have the user be involved, period, the fact that a user would be involved should only be for testing or helping compliance for a busted device, development, research and obviously hacking. Linux allows all these but by default a device with firmware and a custom regdomain that will barf if you try to use a channel that is not allowed is a restriction in firmware. Feel free to reverse engineer that if you don't like it but it just won't be supported or go upstream. Now, the common denominator is generally optimized for best performance as well so you shouldn't have to do anything, and for APs -- this is typically carefully crafted for a region, also highly optimized. >>>> It doesn't seem like you are getting your original requests getting >>>> processed, so I don't think CRDA is passing it. Can you verify running >>>> from CRDA code: >>> >>> They don't get processed unless i remove the return from the code as i indicated. >>> If i remove that return it processes the request. >>> >>>> ./regdbdump /usr/lib/crda/regulatory.bin >>> >>> Although it's in a different location on Debian, /lib/crda/regulatory.bin >>> the dump seems fine. > >> OK thanks. Can you send a patch of what exact change you made, it was >> unclear from the paste you made. > >> diff -u file.c.orig file.c > > Well i just did a pull from wireless-next, to try Avinash Patil's patch. > net/wireless/reg.c had already changed much so i couldn't apply his patch without. > > With his patch it sets the regulatory domain, although as now expected i still can not use channels 12 and 13 yet, > probably due to those firmware restrictions. Its unclear what results you got, and yeah if the device is restricted then its just the fw telling the driver its channels and you can't use them. That's it. You won't be able to override information then unless you hack the firmware. Luis ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work. 2013-12-11 18:38 ` Luis R. Rodriguez @ 2013-12-11 19:06 ` Sander Eikelenboom 2013-12-18 18:54 ` Luis R. Rodriguez 2013-12-16 11:22 ` Sander Eikelenboom 1 sibling, 1 reply; 38+ messages in thread From: Sander Eikelenboom @ 2013-12-11 19:06 UTC (permalink / raw) To: Luis R. Rodriguez Cc: Berg, Johannes, Grumbach, Emmanuel, linux-kernel@vger.kernel.org, ilw@linux.intel.com, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, John W. Linville Wednesday, December 11, 2013, 7:38:50 PM, you wrote: > On Wed, Dec 11, 2013 at 7:11 PM, Sander Eikelenboom > <linux@eikelenboom.it> wrote: >> >> Wednesday, December 11, 2013, 6:53:07 PM, you wrote: >> >>> The best way to address all this is by automatic region awareness and >>> doing the right thing on devices, this however requires good >>> architecture / calibration data / etc and all that needs to be >>> verified by the system integrators, and finally they need to be >>> certified. If you want to hack your firmware and software go at it, >>> just be aware there are reasons for things. >> >> Well the general problem seems to be "we don't trust the user" so we FORCE him to the lowest >> common denominator (without a way to overrule that) so he is forced to operate *well* within the law. > Its simply stupid to have the user be involved, period, the fact that > a user would be involved should only be for testing or helping > compliance for a busted device, development, research and obviously > hacking. Linux allows all these but by default a device with firmware > and a custom regdomain that will barf if you try to use a channel that > is not allowed is a restriction in firmware. Feel free to reverse > engineer that if you don't like it but it just won't be supported or > go upstream. Now, the common denominator is generally optimized for > best performance as well so you shouldn't have to do anything, and for > APs -- this is typically carefully crafted for a region, also highly > optimized. Well how about a car maker shipping al his cars capped to say 10 miles an hour, because somewhere in the world that's the lowest. So to prevent you from breaking the law we will cap your 500HP engine, owh in your country you have a higher speedlimit, ah wel bad luck for you then. We need to enforce this so no one is going to brake any law any where. It's just plain stupid in my opinion (but not something linux can do much about, but it's about enforcing this stuff in firmware in general and thinking too much for the user (fine if you are capable to do so, but in this case clearly not, since there is no automatic way to detect in which country the device is, except by relying on user input). Why just don't set the safe and restricted value on boot and let the user overrule that if he wishes. (that means the user has to invoke a action, so he also should be aware of the consequences). >>>>> It doesn't seem like you are getting your original requests getting >>>>> processed, so I don't think CRDA is passing it. Can you verify running >>>>> from CRDA code: >>>> >>>> They don't get processed unless i remove the return from the code as i indicated. >>>> If i remove that return it processes the request. >>>> >>>>> ./regdbdump /usr/lib/crda/regulatory.bin >>>> >>>> Although it's in a different location on Debian, /lib/crda/regulatory.bin >>>> the dump seems fine. >> >>> OK thanks. Can you send a patch of what exact change you made, it was >>> unclear from the paste you made. >> >>> diff -u file.c.orig file.c >> >> Well i just did a pull from wireless-next, to try Avinash Patil's patch. >> net/wireless/reg.c had already changed much so i couldn't apply his patch without. >> >> With his patch it sets the regulatory domain, although as now expected i still can not use channels 12 and 13 yet, >> probably due to those firmware restrictions. > Its unclear what results you got, and yeah if the device is restricted > then its just the fw telling the driver its channels and you can't use > them. That's it. You won't be able to override information then unless > you hack the firmware. Without the patch: - "iw reg get" gives country 00 - now do a "iw reg set US", no error so it should be fine - now do a "iw reg get" .. gives country 00 again, so it has not been set to the country requested. With the patch: - "iw reg get" gives country 00 - now do a "iw reg set US", no error so it should be fine - now do a "iw reg get" .. gives country US, so it has been set to the country requested. > Luis ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work. 2013-12-11 19:06 ` Sander Eikelenboom @ 2013-12-18 18:54 ` Luis R. Rodriguez 0 siblings, 0 replies; 38+ messages in thread From: Luis R. Rodriguez @ 2013-12-18 18:54 UTC (permalink / raw) To: Sander Eikelenboom Cc: Berg, Johannes, Grumbach, Emmanuel, linux-kernel@vger.kernel.org, ilw@linux.intel.com, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, John W. Linville On Wed, Dec 11, 2013 at 08:06:51PM +0100, Sander Eikelenboom wrote: > > Wednesday, December 11, 2013, 7:38:50 PM, you wrote: > > > On Wed, Dec 11, 2013 at 7:11 PM, Sander Eikelenboom > > <linux@eikelenboom.it> wrote: > >> > >> Wednesday, December 11, 2013, 6:53:07 PM, you wrote: > >> > >>> The best way to address all this is by automatic region awareness and > >>> doing the right thing on devices, this however requires good > >>> architecture / calibration data / etc and all that needs to be > >>> verified by the system integrators, and finally they need to be > >>> certified. If you want to hack your firmware and software go at it, > >>> just be aware there are reasons for things. > >> > >> Well the general problem seems to be "we don't trust the user" so we FORCE him to the lowest > >> common denominator (without a way to overrule that) so he is forced to operate *well* within the law. > > > Its simply stupid to have the user be involved, period, the fact that > > a user would be involved should only be for testing or helping > > compliance for a busted device, development, research and obviously > > hacking. Linux allows all these but by default a device with firmware > > and a custom regdomain that will barf if you try to use a channel that > > is not allowed is a restriction in firmware. Feel free to reverse > > engineer that if you don't like it but it just won't be supported or > > go upstream. Now, the common denominator is generally optimized for > > best performance as well so you shouldn't have to do anything, and for > > APs -- this is typically carefully crafted for a region, also highly > > optimized. > > Well how about a car maker shipping al his cars capped to say 10 miles > an hour, because somewhere in the world that's the lowest. So to > prevent you from breaking the law we will cap your 500HP engine, owh > in your country you have a higher speedlimit, ah wel bad luck for you > then. We need to enforce this so no one is going to brake any law any > where. Don't mix apples and oranges as in this case it does not help. Some 802.11 devices are capable of doing things dynamically and the dynamics of that can exist in firmware or the driver. We have to create APIs to support both, and we have no control over devices that have restrictions in firmware unless the firmware is open as with ath9k_htc or if the firmware is reversed engineered. In the end my own advice to 802.11 vendors has always been that the restictions should be kept in the driver as otherwise they cannot grow / extend to support new regulatory rules / changes or new countries, the code is also complex and simply a true waste in firmware. What vendors do is up to them though, Linux just needs to support all these different types of choices well. > It's just plain stupid in my opinion (but not something linux can do > much about, but it's about enforcing this stuff in firmware in general > and thinking too much for the user (fine if you are capable to do so, > but in this case clearly not, since there is no automatic way to > detect in which country the device is, except by relying on user > input). If you are arguing against regulatory in firmware -- I agree, that's plainly stupid, but we can't do anything about it other than reverse engineer the solutions or proove that we can remain regulatory sane even if we have implemented the solution in the driver, which I can clearly stand behind that statement today. What you say about user knowing better or having to be involved is debatable and I think its frankly stupid to require any user input for location. The future architecture for regulatory should simply be fully automatic with a huge bunch of heuristics to figure out the exact ISO3166-alpha2, today we have that either programmed in, rely on it from the country IE, or we get it from the cellular network (LTE, etc). User input is another source but in the US and JP its now allowed. Cellular input for trusting regulatory is new and in the US its expected you go to some extra lenghts with the FCC to get that device complaint. Linux allows for all these, and we can grow to support more. Keep in mind that in Linux we also allow users to say fsck it, and insist that they know what is best but that then will depend on what the firmware allows too. Linux allows for it all, what vendors do is out of our control unless we have influence. Fortunately we've had quite a bit of influence though and its all been for the better for users. Your main issue is where regulatory is in firmware and I also agree that's silly. We can't do anything over that unless we had firmware source code or the firmware was reversed engineered. We can also convince folks that code is simply a waste in firmware and that we have better controls and features in kernel, which we do. > Why just don't set the safe and restricted value on boot and > let the user overrule that if he wishes. (that means the user has to > invoke a action, so he also should be aware of the consequences). Some countries explicitly don't allow user input for regulatory. JP And US are two of those countries. Drivers can allow support for this and give developers / testers the flexibility to test things in controlled ways, see CONFIG_ATH_REG_DYNAMIC_USER_REG_HINTS and also see CONFIG_ATH_REG_DYNAMIC_USER_CERT_TESTING. This is purely driver specific though and its up to each device driver to use APIs that give this flexibility in ways that are suitable and agreeable with their strategy. We can't change laws, but we can at least provide proper architecture to address all possibilities. We support it all. Vendors have to decide what to do and that is out of our direct control. > >>>>> It doesn't seem like you are getting your original requests getting > >>>>> processed, so I don't think CRDA is passing it. Can you verify running > >>>>> from CRDA code: > >>>> > >>>> They don't get processed unless i remove the return from the code as i indicated. > >>>> If i remove that return it processes the request. > >>>> > >>>>> ./regdbdump /usr/lib/crda/regulatory.bin > >>>> > >>>> Although it's in a different location on Debian, /lib/crda/regulatory.bin > >>>> the dump seems fine. > >> > >>> OK thanks. Can you send a patch of what exact change you made, it was > >>> unclear from the paste you made. > >> > >>> diff -u file.c.orig file.c > >> > >> Well i just did a pull from wireless-next, to try Avinash Patil's patch. > >> net/wireless/reg.c had already changed much so i couldn't apply his patch without. > >> > >> With his patch it sets the regulatory domain, although as now expected i still can not use channels 12 and 13 yet, > >> probably due to those firmware restrictions. > > > Its unclear what results you got, and yeah if the device is restricted > > then its just the fw telling the driver its channels and you can't use > > them. That's it. You won't be able to override information then unless > > you hack the firmware. > > Without the patch: > > - "iw reg get" gives country 00 > - now do a "iw reg set US", no error so it should be fine > - now do a "iw reg get" .. gives country 00 again, so it has not been set to the country requested. > > With the patch: > > - "iw reg get" gives country 00 > - now do a "iw reg set US", no error so it should be fine > - now do a "iw reg get" .. gives country US, so it has been set to the country requested. I'd like to get to the bottom of this. Lets focus on this now. Can you provide the kernel you used? I'd like to reproduce, I can't right now. Luis ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work. 2013-12-11 18:38 ` Luis R. Rodriguez 2013-12-11 19:06 ` Sander Eikelenboom @ 2013-12-16 11:22 ` Sander Eikelenboom 2013-12-16 11:37 ` Arend van Spriel 2013-12-18 18:29 ` Luis R. Rodriguez 1 sibling, 2 replies; 38+ messages in thread From: Sander Eikelenboom @ 2013-12-16 11:22 UTC (permalink / raw) To: Luis R. Rodriguez Cc: Berg, Johannes, Grumbach, Emmanuel, linux-kernel@vger.kernel.org, ilw@linux.intel.com, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, John W. Linville Wednesday, December 11, 2013, 7:38:50 PM, you wrote: > On Wed, Dec 11, 2013 at 7:11 PM, Sander Eikelenboom > <linux@eikelenboom.it> wrote: >> >> Wednesday, December 11, 2013, 6:53:07 PM, you wrote: >> >>> The best way to address all this is by automatic region awareness and >>> doing the right thing on devices, this however requires good >>> architecture / calibration data / etc and all that needs to be >>> verified by the system integrators, and finally they need to be >>> certified. If you want to hack your firmware and software go at it, >>> just be aware there are reasons for things. >> >> Well the general problem seems to be "we don't trust the user" so we FORCE him to the lowest >> common denominator (without a way to overrule that) so he is forced to operate *well* within the law. > Its simply stupid to have the user be involved, period, the fact that > a user would be involved should only be for testing or helping > compliance for a busted device, development, research and obviously > hacking. Linux allows all these but by default a device with firmware > and a custom regdomain that will barf if you try to use a channel that > is not allowed is a restriction in firmware. Feel free to reverse > engineer that if you don't like it but it just won't be supported or > go upstream. Now, the common denominator is generally optimized for > best performance as well so you shouldn't have to do anything, and for > APs -- this is typically carefully crafted for a region, also highly > optimized. >>>>> It doesn't seem like you are getting your original requests getting >>>>> processed, so I don't think CRDA is passing it. Can you verify running >>>>> from CRDA code: >>>> >>>> They don't get processed unless i remove the return from the code as i indicated. >>>> If i remove that return it processes the request. >>>> >>>>> ./regdbdump /usr/lib/crda/regulatory.bin >>>> >>>> Although it's in a different location on Debian, /lib/crda/regulatory.bin >>>> the dump seems fine. >> >>> OK thanks. Can you send a patch of what exact change you made, it was >>> unclear from the paste you made. >> >>> diff -u file.c.orig file.c >> >> Well i just did a pull from wireless-next, to try Avinash Patil's patch. >> net/wireless/reg.c had already changed much so i couldn't apply his patch without. >> >> With his patch it sets the regulatory domain, although as now expected i still can not use channels 12 and 13 yet, >> probably due to those firmware restrictions. > Its unclear what results you got, and yeah if the device is restricted > then its just the fw telling the driver its channels and you can't use > them. That's it. You won't be able to override information then unless > you hack the firmware Ping ? Is there anymore information you need to *fix* the problem ? > Luis ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work. 2013-12-16 11:22 ` Sander Eikelenboom @ 2013-12-16 11:37 ` Arend van Spriel 2013-12-16 12:56 ` Sander Eikelenboom 2013-12-18 18:29 ` Luis R. Rodriguez 1 sibling, 1 reply; 38+ messages in thread From: Arend van Spriel @ 2013-12-16 11:37 UTC (permalink / raw) To: Sander Eikelenboom, Luis R. Rodriguez Cc: Berg, Johannes, Grumbach, Emmanuel, linux-kernel@vger.kernel.org, ilw@linux.intel.com, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, John W. Linville On 12/16/2013 12:22 PM, Sander Eikelenboom wrote: > > Wednesday, December 11, 2013, 7:38:50 PM, you wrote: > >> On Wed, Dec 11, 2013 at 7:11 PM, Sander Eikelenboom >> <linux@eikelenboom.it> wrote: >>> >>> Wednesday, December 11, 2013, 6:53:07 PM, you wrote: >>> >>>> The best way to address all this is by automatic region awareness and >>>> doing the right thing on devices, this however requires good >>>> architecture / calibration data / etc and all that needs to be >>>> verified by the system integrators, and finally they need to be >>>> certified. If you want to hack your firmware and software go at it, >>>> just be aware there are reasons for things. >>> >>> Well the general problem seems to be "we don't trust the user" so we FORCE him to the lowest >>> common denominator (without a way to overrule that) so he is forced to operate *well* within the law. > >> Its simply stupid to have the user be involved, period, the fact that >> a user would be involved should only be for testing or helping >> compliance for a busted device, development, research and obviously >> hacking. Linux allows all these but by default a device with firmware >> and a custom regdomain that will barf if you try to use a channel that >> is not allowed is a restriction in firmware. Feel free to reverse >> engineer that if you don't like it but it just won't be supported or >> go upstream. Now, the common denominator is generally optimized for >> best performance as well so you shouldn't have to do anything, and for >> APs -- this is typically carefully crafted for a region, also highly >> optimized. > >>>>>> It doesn't seem like you are getting your original requests getting >>>>>> processed, so I don't think CRDA is passing it. Can you verify running >>>>>> from CRDA code: >>>>> >>>>> They don't get processed unless i remove the return from the code as i indicated. >>>>> If i remove that return it processes the request. >>>>> >>>>>> ./regdbdump /usr/lib/crda/regulatory.bin >>>>> >>>>> Although it's in a different location on Debian, /lib/crda/regulatory.bin >>>>> the dump seems fine. >>> >>>> OK thanks. Can you send a patch of what exact change you made, it was >>>> unclear from the paste you made. >>> >>>> diff -u file.c.orig file.c >>> >>> Well i just did a pull from wireless-next, to try Avinash Patil's patch. >>> net/wireless/reg.c had already changed much so i couldn't apply his patch without. >>> >>> With his patch it sets the regulatory domain, although as now expected i still can not use channels 12 and 13 yet, >>> probably due to those firmware restrictions. > >> Its unclear what results you got, and yeah if the device is restricted >> then its just the fw telling the driver its channels and you can't use >> them. That's it. You won't be able to override information then unless >> you hack the firmware > > Ping ? > > Is there anymore information you need to *fix* the problem ? Maybe you did not get the essence of the response from Luis: There is *no* problem to be fixed. Gr. AvS ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work. 2013-12-16 11:37 ` Arend van Spriel @ 2013-12-16 12:56 ` Sander Eikelenboom 2013-12-17 2:17 ` Julian Calaby 2013-12-18 19:27 ` Luis R. Rodriguez 0 siblings, 2 replies; 38+ messages in thread From: Sander Eikelenboom @ 2013-12-16 12:56 UTC (permalink / raw) To: Arend van Spriel, Luis R. Rodriguez, Linus Torvalds Cc: Berg, Johannes, Grumbach, Emmanuel, linux-kernel@vger.kernel.org, ilw@linux.intel.com, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, John W. Linville, Avinash Patil Monday, December 16, 2013, 12:37:47 PM, you wrote: > On 12/16/2013 12:22 PM, Sander Eikelenboom wrote: >> >> Wednesday, December 11, 2013, 7:38:50 PM, you wrote: >> >>> On Wed, Dec 11, 2013 at 7:11 PM, Sander Eikelenboom >>> <linux@eikelenboom.it> wrote: >>>> >>>> Wednesday, December 11, 2013, 6:53:07 PM, you wrote: >>>> >>>>> The best way to address all this is by automatic region awareness and >>>>> doing the right thing on devices, this however requires good >>>>> architecture / calibration data / etc and all that needs to be >>>>> verified by the system integrators, and finally they need to be >>>>> certified. If you want to hack your firmware and software go at it, >>>>> just be aware there are reasons for things. >>>> >>>> Well the general problem seems to be "we don't trust the user" so we FORCE him to the lowest >>>> common denominator (without a way to overrule that) so he is forced to operate *well* within the law. >> >>> Its simply stupid to have the user be involved, period, the fact that >>> a user would be involved should only be for testing or helping >>> compliance for a busted device, development, research and obviously >>> hacking. Linux allows all these but by default a device with firmware >>> and a custom regdomain that will barf if you try to use a channel that >>> is not allowed is a restriction in firmware. Feel free to reverse >>> engineer that if you don't like it but it just won't be supported or >>> go upstream. Now, the common denominator is generally optimized for >>> best performance as well so you shouldn't have to do anything, and for >>> APs -- this is typically carefully crafted for a region, also highly >>> optimized. >> >>>>>>> It doesn't seem like you are getting your original requests getting >>>>>>> processed, so I don't think CRDA is passing it. Can you verify running >>>>>>> from CRDA code: >>>>>> >>>>>> They don't get processed unless i remove the return from the code as i indicated. >>>>>> If i remove that return it processes the request. >>>>>> >>>>>>> ./regdbdump /usr/lib/crda/regulatory.bin >>>>>> >>>>>> Although it's in a different location on Debian, /lib/crda/regulatory.bin >>>>>> the dump seems fine. >>>> >>>>> OK thanks. Can you send a patch of what exact change you made, it was >>>>> unclear from the paste you made. >>>> >>>>> diff -u file.c.orig file.c >>>> >>>> Well i just did a pull from wireless-next, to try Avinash Patil's patch. >>>> net/wireless/reg.c had already changed much so i couldn't apply his patch without. >>>> >>>> With his patch it sets the regulatory domain, although as now expected i still can not use channels 12 and 13 yet, >>>> probably due to those firmware restrictions. >> >>> Its unclear what results you got, and yeah if the device is restricted >>> then its just the fw telling the driver its channels and you can't use >>> them. That's it. You won't be able to override information then unless >>> you hack the firmware >> >> Ping ? >> >> Is there anymore information you need to *fix* the problem ? > Maybe you did not get the essence of the response from Luis: There is > *no* problem to be fixed. *sigh* .. Let's start from scratch then ... a) Isn't the point of the whole regulatory domain system that i can select (and restrict) the channels/frequencies my devices transmits on, so i can abide the law ? b) If so, does it set a regulatory domain from firmware ? c) If so, should it let me *restrict* the available channels even more by setting the regulatory domain to the region in which de device is currently being used ? d) If so, why am i not able to do so with my intel driver for a long time (for over a month now). # iw reg get country 00: (2402 - 2472 @ 40), (6, 20) (2457 - 2482 @ 40), (6, 20), PASSIVE-SCAN (2474 - 2494 @ 20), (6, 20), NO-OFDM, PASSIVE-SCAN (5170 - 5250 @ 160), (6, 20), PASSIVE-SCAN (5250 - 5330 @ 160), (6, 20), DFS, PASSIVE-SCAN (5490 - 5730 @ 160), (6, 20), DFS, PASSIVE-SCAN # iw reg set US # iw reg get country 00: (2402 - 2472 @ 40), (6, 20) (2457 - 2482 @ 40), (6, 20), PASSIVE-SCAN (2474 - 2494 @ 20), (6, 20), NO-OFDM, PASSIVE-SCAN (5170 - 5250 @ 160), (6, 20), PASSIVE-SCAN (5250 - 5330 @ 160), (6, 20), DFS, PASSIVE-SCAN (5490 - 5730 @ 160), (6, 20), DFS, PASSIVE-SCAN Dmesg only spits out: [ 383.849977] cfg80211: Pending regulatory request, waiting for it to be processed... e) So why doesn't this whole regulatory mumbojumbo and the Linux implementation in particular let me abide the law ?!? Wasn't that it's *sole* point of existence ? f) Why doesn't seem anyone to be seriously looking at it (for over a month now, while everyone from wireless/80211 to intel driver maintainers were CC'ed) ? g) Saying it has got to do with reg db's not being found or all kinds of other arguments while the report clearly stated the way it can be circumvented by 2 simple patches that don't seem to involve any changes to how it finds the reg db (apart from that i tested that a few times on request and indicated it didn't matter) in current 3.13 code (and 3.12 and perhaps even earlier) (case 1) or with current wireless-next pulled (which has quite some changes to reg.c but none fixes this) onto 3.13 (case 2) Neither of these patches might be correct codewise, but at least it let's me set the regulatory domain, and the current state the code is in is neither correct. h) Added Linus to the CC, you never know if that automagically kicks things in gear ... (hopefully not in reverse :-p) Case 1 - patch that makes it possible to set the regulatory domain without silently ignoring it - applies to 3.13-rc4 diff --git a/net/wireless/reg.c b/net/wireless/reg.c index 7da67fd..e8ab82e 100644 --- a/net/wireless/reg.c +++ b/net/wireless/reg.c @@ -1579,7 +1579,7 @@ static void reg_process_pending_hints(void) /* When last_request->processed becomes true this will be rescheduled */ if (lr && !lr->processed) { REG_DBG_PRINT("Pending regulatory request, waiting for it to be processed...\n"); - return; + /* return; */ } spin_lock(®_requests_lock); Case 2 - RFC patch by Avinash Patil that makes it possible to set the regulatory domain without silently ignoring it - applies to 3.13-rc4 + wireless-next pulled onto it ---------- Forwarded message ---------- From: "Avinash Patil" <patila@marvell.com> Date: Dec 6, 2013 8:31 PM Subject: [RFC] cfg80211: set regulatory request processed for initiator core To: <johannes@sipsolutions.net>, <linux-wireless@vger.kernel.org> Cc: During cfg80211 init, cfg80211 initializes regulatory to set to world domain. Here we dont set last request processed flag. This results into further request set to pending indefinitely. This patch fixes this by setting last request to processed. Signed-off-by: Avinash Patil <patila@marvell.com> --- net/wireless/reg.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/net/wireless/reg.c b/net/wireless/reg.c index ec54e1a..70a8f0a 100644 --- a/net/wireless/reg.c +++ b/net/wireless/reg.c @@ -1670,6 +1670,8 @@ static void reg_process_hint(struct regulatory_request *reg_request) switch (reg_request->initiator) { case NL80211_REGDOM_SET_BY_CORE: reg_process_hint_core(reg_request); + nl80211_send_reg_change_event(reg_request); + reg_set_request_processed(); return; case NL80211_REGDOM_SET_BY_USER: treatment = reg_process_hint_user(reg_request); -- 1.7.3.4 > Gr. AvS ^ permalink raw reply related [flat|nested] 38+ messages in thread
* Re: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work. 2013-12-16 12:56 ` Sander Eikelenboom @ 2013-12-17 2:17 ` Julian Calaby 2013-12-17 9:45 ` Sander Eikelenboom 2013-12-18 19:27 ` Luis R. Rodriguez 1 sibling, 1 reply; 38+ messages in thread From: Julian Calaby @ 2013-12-17 2:17 UTC (permalink / raw) To: Sander Eikelenboom Cc: Arend van Spriel, Luis R. Rodriguez, Linus Torvalds, Berg, Johannes, Grumbach, Emmanuel, linux-kernel@vger.kernel.org, ilw@linux.intel.com, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, John W. Linville, Avinash Patil Hi Sander, On Mon, Dec 16, 2013 at 11:56 PM, Sander Eikelenboom <linux@eikelenboom.it> wrote: > > Monday, December 16, 2013, 12:37:47 PM, you wrote: > >> On 12/16/2013 12:22 PM, Sander Eikelenboom wrote: >>> >>> Wednesday, December 11, 2013, 7:38:50 PM, you wrote: >>> >>>> On Wed, Dec 11, 2013 at 7:11 PM, Sander Eikelenboom >>>> <linux@eikelenboom.it> wrote: >>>>> >>>>> Wednesday, December 11, 2013, 6:53:07 PM, you wrote: >>>>> >>>>>> The best way to address all this is by automatic region awareness and >>>>>> doing the right thing on devices, this however requires good >>>>>> architecture / calibration data / etc and all that needs to be >>>>>> verified by the system integrators, and finally they need to be >>>>>> certified. If you want to hack your firmware and software go at it, >>>>>> just be aware there are reasons for things. >>>>> >>>>> Well the general problem seems to be "we don't trust the user" so we FORCE him to the lowest >>>>> common denominator (without a way to overrule that) so he is forced to operate *well* within the law. >>> >>>> Its simply stupid to have the user be involved, period, the fact that >>>> a user would be involved should only be for testing or helping >>>> compliance for a busted device, development, research and obviously >>>> hacking. Linux allows all these but by default a device with firmware >>>> and a custom regdomain that will barf if you try to use a channel that >>>> is not allowed is a restriction in firmware. Feel free to reverse >>>> engineer that if you don't like it but it just won't be supported or >>>> go upstream. Now, the common denominator is generally optimized for >>>> best performance as well so you shouldn't have to do anything, and for >>>> APs -- this is typically carefully crafted for a region, also highly >>>> optimized. >>> >>>>>>>> It doesn't seem like you are getting your original requests getting >>>>>>>> processed, so I don't think CRDA is passing it. Can you verify running >>>>>>>> from CRDA code: >>>>>>> >>>>>>> They don't get processed unless i remove the return from the code as i indicated. >>>>>>> If i remove that return it processes the request. >>>>>>> >>>>>>>> ./regdbdump /usr/lib/crda/regulatory.bin >>>>>>> >>>>>>> Although it's in a different location on Debian, /lib/crda/regulatory.bin >>>>>>> the dump seems fine. >>>>> >>>>>> OK thanks. Can you send a patch of what exact change you made, it was >>>>>> unclear from the paste you made. >>>>> >>>>>> diff -u file.c.orig file.c >>>>> >>>>> Well i just did a pull from wireless-next, to try Avinash Patil's patch. >>>>> net/wireless/reg.c had already changed much so i couldn't apply his patch without. >>>>> >>>>> With his patch it sets the regulatory domain, although as now expected i still can not use channels 12 and 13 yet, >>>>> probably due to those firmware restrictions. >>> >>>> Its unclear what results you got, and yeah if the device is restricted >>>> then its just the fw telling the driver its channels and you can't use >>>> them. That's it. You won't be able to override information then unless >>>> you hack the firmware >>> >>> Ping ? >>> >>> Is there anymore information you need to *fix* the problem ? > >> Maybe you did not get the essence of the response from Luis: There is >> *no* problem to be fixed. > > *sigh* .. > > Let's start from scratch then ... > > > a) Isn't the point of the whole regulatory domain system that i can select (and restrict) the channels/frequencies my devices transmits on, so i can abide the law ? > b) If so, does it set a regulatory domain from firmware ? > c) If so, should it let me *restrict* the available channels even more by setting the regulatory domain to the region in which de device is currently being used ? > d) If so, why am i not able to do so with my intel driver for a long time (for over a month now). > # iw reg get > country 00: > (2402 - 2472 @ 40), (6, 20) > (2457 - 2482 @ 40), (6, 20), PASSIVE-SCAN > (2474 - 2494 @ 20), (6, 20), NO-OFDM, PASSIVE-SCAN > (5170 - 5250 @ 160), (6, 20), PASSIVE-SCAN > (5250 - 5330 @ 160), (6, 20), DFS, PASSIVE-SCAN > (5490 - 5730 @ 160), (6, 20), DFS, PASSIVE-SCAN > # iw reg set US > # iw reg get > country 00: > (2402 - 2472 @ 40), (6, 20) > (2457 - 2482 @ 40), (6, 20), PASSIVE-SCAN > (2474 - 2494 @ 20), (6, 20), NO-OFDM, PASSIVE-SCAN > (5170 - 5250 @ 160), (6, 20), PASSIVE-SCAN > (5250 - 5330 @ 160), (6, 20), DFS, PASSIVE-SCAN > (5490 - 5730 @ 160), (6, 20), DFS, PASSIVE-SCAN > > Dmesg only spits out: > [ 383.849977] cfg80211: Pending regulatory request, waiting for it to be processed... > As has been explained previously, this indicates that, somehow, CRDA is not answering the kernel's requests as it should. Looking at the dmesg you posted before, we have: [ 3.862108] cfg80211: Calling CRDA to update world regulatory domain which never gets a reply. Are you using your distro's official CRDA package or have you compiled your own? It might not be installed properly as it looks like it's not responding to the kernel's call to update the world regulatory domain. There's more to installing CRDA than just sticking the executable and database in the right places. On my system here, I have: [ 16.981114] cfg80211: Calling CRDA to update world regulatory domain ... [ 17.300582] cfg80211: World regulatory domain updated: [ 17.300592] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [ 17.300594] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) [ 17.300597] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) [ 17.300598] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) [ 17.300600] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) [ 17.300602] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Your dmesg doesn't have the response listed, therefore CRDA is not responding to the kernel's requests. The kernel will not make additional requests until the previous one is answered. > e) So why doesn't this whole regulatory mumbojumbo and the Linux implementation in particular let me abide the law ?!? Wasn't that it's *sole* point of existence ? It _is_ doing this. The world regulatory domain is the intersection of all the regulatory domains we know of. This is the _most_ restricted version which _ensures_ that you're obeying the law _everywhere_. > f) Why doesn't seem anyone to be seriously looking at it (for over a month now, while everyone from wireless/80211 to intel driver maintainers were CC'ed) ? Because there is no bug in the kernel, the bug is in your system's setup. > g) Saying it has got to do with reg db's not being found or all kinds of other arguments while > the report clearly stated the way it can be circumvented by 2 simple patches that don't seem to involve any changes to > how it finds the reg db (apart from that i tested that a few times on request and indicated it didn't matter) > in current 3.13 code (and 3.12 and perhaps even earlier) (case 1) > or > with current wireless-next pulled (which has quite some changes to reg.c but none fixes this) onto 3.13 (case 2) > Neither of these patches might be correct codewise, but at least it let's me set the regulatory domain, and the current state the code is in is neither correct. These patches _break_ the functionality of the kernel, not fix it. They allow the kernel to issue requests before the previous one is answered. This is a bug. There are good reasons why this is not allowed. Thanks, -- Julian Calaby Email: julian.calaby@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ .Plan: http://sites.google.com/site/juliancalaby/ ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work. 2013-12-17 2:17 ` Julian Calaby @ 2013-12-17 9:45 ` Sander Eikelenboom 2013-12-17 20:33 ` Sander Eikelenboom 0 siblings, 1 reply; 38+ messages in thread From: Sander Eikelenboom @ 2013-12-17 9:45 UTC (permalink / raw) To: Julian Calaby Cc: Arend van Spriel, Luis R. Rodriguez, Linus Torvalds, Berg, Johannes, Grumbach, Emmanuel, linux-kernel@vger.kernel.org, ilw@linux.intel.com, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, John W. Linville, Avinash Patil Tuesday, December 17, 2013, 3:17:50 AM, you wrote: > Hi Sander, > On Mon, Dec 16, 2013 at 11:56 PM, Sander Eikelenboom > <linux@eikelenboom.it> wrote: >> >> Monday, December 16, 2013, 12:37:47 PM, you wrote: >> >>> On 12/16/2013 12:22 PM, Sander Eikelenboom wrote: >>>> >>>> Wednesday, December 11, 2013, 7:38:50 PM, you wrote: >>>> >>>>> On Wed, Dec 11, 2013 at 7:11 PM, Sander Eikelenboom >>>>> <linux@eikelenboom.it> wrote: >>>>>> >>>>>> Wednesday, December 11, 2013, 6:53:07 PM, you wrote: >>>>>> >>>>>>> The best way to address all this is by automatic region awareness and >>>>>>> doing the right thing on devices, this however requires good >>>>>>> architecture / calibration data / etc and all that needs to be >>>>>>> verified by the system integrators, and finally they need to be >>>>>>> certified. If you want to hack your firmware and software go at it, >>>>>>> just be aware there are reasons for things. >>>>>> >>>>>> Well the general problem seems to be "we don't trust the user" so we FORCE him to the lowest >>>>>> common denominator (without a way to overrule that) so he is forced to operate *well* within the law. >>>> >>>>> Its simply stupid to have the user be involved, period, the fact that >>>>> a user would be involved should only be for testing or helping >>>>> compliance for a busted device, development, research and obviously >>>>> hacking. Linux allows all these but by default a device with firmware >>>>> and a custom regdomain that will barf if you try to use a channel that >>>>> is not allowed is a restriction in firmware. Feel free to reverse >>>>> engineer that if you don't like it but it just won't be supported or >>>>> go upstream. Now, the common denominator is generally optimized for >>>>> best performance as well so you shouldn't have to do anything, and for >>>>> APs -- this is typically carefully crafted for a region, also highly >>>>> optimized. >>>> >>>>>>>>> It doesn't seem like you are getting your original requests getting >>>>>>>>> processed, so I don't think CRDA is passing it. Can you verify running >>>>>>>>> from CRDA code: >>>>>>>> >>>>>>>> They don't get processed unless i remove the return from the code as i indicated. >>>>>>>> If i remove that return it processes the request. >>>>>>>> >>>>>>>>> ./regdbdump /usr/lib/crda/regulatory.bin >>>>>>>> >>>>>>>> Although it's in a different location on Debian, /lib/crda/regulatory.bin >>>>>>>> the dump seems fine. >>>>>> >>>>>>> OK thanks. Can you send a patch of what exact change you made, it was >>>>>>> unclear from the paste you made. >>>>>> >>>>>>> diff -u file.c.orig file.c >>>>>> >>>>>> Well i just did a pull from wireless-next, to try Avinash Patil's patch. >>>>>> net/wireless/reg.c had already changed much so i couldn't apply his patch without. >>>>>> >>>>>> With his patch it sets the regulatory domain, although as now expected i still can not use channels 12 and 13 yet, >>>>>> probably due to those firmware restrictions. >>>> >>>>> Its unclear what results you got, and yeah if the device is restricted >>>>> then its just the fw telling the driver its channels and you can't use >>>>> them. That's it. You won't be able to override information then unless >>>>> you hack the firmware >>>> >>>> Ping ? >>>> >>>> Is there anymore information you need to *fix* the problem ? >> >>> Maybe you did not get the essence of the response from Luis: There is >>> *no* problem to be fixed. >> >> *sigh* .. >> >> Let's start from scratch then ... >> >> >> a) Isn't the point of the whole regulatory domain system that i can select (and restrict) the channels/frequencies my devices transmits on, so i can abide the law ? >> b) If so, does it set a regulatory domain from firmware ? >> c) If so, should it let me *restrict* the available channels even more by setting the regulatory domain to the region in which de device is currently being used ? >> d) If so, why am i not able to do so with my intel driver for a long time (for over a month now). >> # iw reg get >> country 00: >> (2402 - 2472 @ 40), (6, 20) >> (2457 - 2482 @ 40), (6, 20), PASSIVE-SCAN >> (2474 - 2494 @ 20), (6, 20), NO-OFDM, PASSIVE-SCAN >> (5170 - 5250 @ 160), (6, 20), PASSIVE-SCAN >> (5250 - 5330 @ 160), (6, 20), DFS, PASSIVE-SCAN >> (5490 - 5730 @ 160), (6, 20), DFS, PASSIVE-SCAN >> # iw reg set US >> # iw reg get >> country 00: >> (2402 - 2472 @ 40), (6, 20) >> (2457 - 2482 @ 40), (6, 20), PASSIVE-SCAN >> (2474 - 2494 @ 20), (6, 20), NO-OFDM, PASSIVE-SCAN >> (5170 - 5250 @ 160), (6, 20), PASSIVE-SCAN >> (5250 - 5330 @ 160), (6, 20), DFS, PASSIVE-SCAN >> (5490 - 5730 @ 160), (6, 20), DFS, PASSIVE-SCAN >> >> Dmesg only spits out: >> [ 383.849977] cfg80211: Pending regulatory request, waiting for it to be processed... >> > As has been explained previously, this indicates that, somehow, CRDA > is not answering the kernel's requests as it should. Looking at the > dmesg you posted before, we have: > [ 3.862108] cfg80211: Calling CRDA to update world regulatory domain > which never gets a reply. > Are you using your distro's official CRDA package or have you compiled > your own? It might not be installed properly as it looks like it's not > responding to the kernel's call to update the world regulatory domain. > There's more to installing CRDA than just sticking the executable and > database in the right places. It's the official Debian package. But i have tried to compile the db.txt into the kernel as is mentioned and use the internalregdb kernel config option. Could it be that since i compile all modules in the kernel and use --initrd .. that the CRDA is just not available at *that* earlier moment in boot when that module gets activated ? If so, wouldn't it be feasible to have a) timeout with error message b) clearing the request so a subsequent request can be made ? The way the patches that where posted then circumvent the problem is by just plain ignoring the blocked request. I could see if compiling them as loadable modules helps, another thing would be shoveling the whole CRDA stuff into initrd. > On my system here, I have: > [ 16.981114] cfg80211: Calling CRDA to update world regulatory domain > ... > [ 17.300582] cfg80211: World regulatory domain updated: > [ 17.300592] cfg80211: (start_freq - end_freq @ bandwidth), > (max_antenna_gain, max_eirp) > [ 17.300594] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), > (300 mBi, 2000 mBm) > [ 17.300597] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), > (300 mBi, 2000 mBm) > [ 17.300598] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), > (300 mBi, 2000 mBm) > [ 17.300600] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), > (300 mBi, 2000 mBm) > [ 17.300602] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), > (300 mBi, 2000 mBm) > Your dmesg doesn't have the response listed, therefore CRDA is not > responding to the kernel's requests. The kernel will not make > additional requests until the previous one is answered. >> e) So why doesn't this whole regulatory mumbojumbo and the Linux implementation in particular let me abide the law ?!? Wasn't that it's *sole* point of existence ? > It _is_ doing this. > The world regulatory domain is the intersection of all the regulatory > domains we know of. This is the _most_ restricted version which > _ensures_ that you're obeying the law _everywhere_. >> f) Why doesn't seem anyone to be seriously looking at it (for over a month now, while everyone from wireless/80211 to intel driver maintainers were CC'ed) ? > Because there is no bug in the kernel, the bug is in your system's setup. I will leave this one in the clear for the moment ... (nope i will not .. see below ;-) ) >> g) Saying it has got to do with reg db's not being found or all kinds of other arguments while >> the report clearly stated the way it can be circumvented by 2 simple patches that don't seem to involve any changes to >> how it finds the reg db (apart from that i tested that a few times on request and indicated it didn't matter) >> in current 3.13 code (and 3.12 and perhaps even earlier) (case 1) >> or >> with current wireless-next pulled (which has quite some changes to reg.c but none fixes this) onto 3.13 (case 2) >> Neither of these patches might be correct codewise, but at least it let's me set the regulatory domain, and the current state the code is in is neither correct. > These patches _break_ the functionality of the kernel, not fix it. > They allow the kernel to issue requests before the previous one is > answered. This is a bug. There are good reasons why this is not > allowed. Yes because for some reason it's allowed for requests to block for ever ... which could be considered a bug. So yes it's the wrong fix ... but it at least identifies a problem .. infinite blocking requests. I will report back when i have tested converting the wireless stuff to loadable modules / seeing if i can put the CRDA stuff in initrd. > Thanks, ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work. 2013-12-17 9:45 ` Sander Eikelenboom @ 2013-12-17 20:33 ` Sander Eikelenboom 2013-12-17 21:27 ` Ben Hutchings 0 siblings, 1 reply; 38+ messages in thread From: Sander Eikelenboom @ 2013-12-17 20:33 UTC (permalink / raw) To: Julian Calaby Cc: Arend van Spriel, Luis R. Rodriguez, Linus Torvalds, Berg, Johannes, Grumbach, Emmanuel, linux-kernel@vger.kernel.org, ilw@linux.intel.com, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, John W. Linville, Avinash Patil Hello Sander, Tuesday, December 17, 2013, 10:45:48 AM, you wrote: > Tuesday, December 17, 2013, 3:17:50 AM, you wrote: >> Hi Sander, >> On Mon, Dec 16, 2013 at 11:56 PM, Sander Eikelenboom >> <linux@eikelenboom.it> wrote: >>> >>> Monday, December 16, 2013, 12:37:47 PM, you wrote: >>> >>>> On 12/16/2013 12:22 PM, Sander Eikelenboom wrote: >>>>> >>>>> Wednesday, December 11, 2013, 7:38:50 PM, you wrote: >>>>> >>>>>> On Wed, Dec 11, 2013 at 7:11 PM, Sander Eikelenboom >>>>>> <linux@eikelenboom.it> wrote: >>>>>>> >>>>>>> Wednesday, December 11, 2013, 6:53:07 PM, you wrote: >>>>>>> >>>>>>>> The best way to address all this is by automatic region awareness and >>>>>>>> doing the right thing on devices, this however requires good >>>>>>>> architecture / calibration data / etc and all that needs to be >>>>>>>> verified by the system integrators, and finally they need to be >>>>>>>> certified. If you want to hack your firmware and software go at it, >>>>>>>> just be aware there are reasons for things. >>>>>>> >>>>>>> Well the general problem seems to be "we don't trust the user" so we FORCE him to the lowest >>>>>>> common denominator (without a way to overrule that) so he is forced to operate *well* within the law. >>>>> >>>>>> Its simply stupid to have the user be involved, period, the fact that >>>>>> a user would be involved should only be for testing or helping >>>>>> compliance for a busted device, development, research and obviously >>>>>> hacking. Linux allows all these but by default a device with firmware >>>>>> and a custom regdomain that will barf if you try to use a channel that >>>>>> is not allowed is a restriction in firmware. Feel free to reverse >>>>>> engineer that if you don't like it but it just won't be supported or >>>>>> go upstream. Now, the common denominator is generally optimized for >>>>>> best performance as well so you shouldn't have to do anything, and for >>>>>> APs -- this is typically carefully crafted for a region, also highly >>>>>> optimized. >>>>> >>>>>>>>>> It doesn't seem like you are getting your original requests getting >>>>>>>>>> processed, so I don't think CRDA is passing it. Can you verify running >>>>>>>>>> from CRDA code: >>>>>>>>> >>>>>>>>> They don't get processed unless i remove the return from the code as i indicated. >>>>>>>>> If i remove that return it processes the request. >>>>>>>>> >>>>>>>>>> ./regdbdump /usr/lib/crda/regulatory.bin >>>>>>>>> >>>>>>>>> Although it's in a different location on Debian, /lib/crda/regulatory.bin >>>>>>>>> the dump seems fine. >>>>>>> >>>>>>>> OK thanks. Can you send a patch of what exact change you made, it was >>>>>>>> unclear from the paste you made. >>>>>>> >>>>>>>> diff -u file.c.orig file.c >>>>>>> >>>>>>> Well i just did a pull from wireless-next, to try Avinash Patil's patch. >>>>>>> net/wireless/reg.c had already changed much so i couldn't apply his patch without. >>>>>>> >>>>>>> With his patch it sets the regulatory domain, although as now expected i still can not use channels 12 and 13 yet, >>>>>>> probably due to those firmware restrictions. >>>>> >>>>>> Its unclear what results you got, and yeah if the device is restricted >>>>>> then its just the fw telling the driver its channels and you can't use >>>>>> them. That's it. You won't be able to override information then unless >>>>>> you hack the firmware >>>>> >>>>> Ping ? >>>>> >>>>> Is there anymore information you need to *fix* the problem ? >>> >>>> Maybe you did not get the essence of the response from Luis: There is >>>> *no* problem to be fixed. >>> >>> *sigh* .. >>> >>> Let's start from scratch then ... >>> >>> >>> a) Isn't the point of the whole regulatory domain system that i can select (and restrict) the channels/frequencies my devices transmits on, so i can abide the law ? >>> b) If so, does it set a regulatory domain from firmware ? >>> c) If so, should it let me *restrict* the available channels even more by setting the regulatory domain to the region in which de device is currently being used ? >>> d) If so, why am i not able to do so with my intel driver for a long time (for over a month now). >>> # iw reg get >>> country 00: >>> (2402 - 2472 @ 40), (6, 20) >>> (2457 - 2482 @ 40), (6, 20), PASSIVE-SCAN >>> (2474 - 2494 @ 20), (6, 20), NO-OFDM, PASSIVE-SCAN >>> (5170 - 5250 @ 160), (6, 20), PASSIVE-SCAN >>> (5250 - 5330 @ 160), (6, 20), DFS, PASSIVE-SCAN >>> (5490 - 5730 @ 160), (6, 20), DFS, PASSIVE-SCAN >>> # iw reg set US >>> # iw reg get >>> country 00: >>> (2402 - 2472 @ 40), (6, 20) >>> (2457 - 2482 @ 40), (6, 20), PASSIVE-SCAN >>> (2474 - 2494 @ 20), (6, 20), NO-OFDM, PASSIVE-SCAN >>> (5170 - 5250 @ 160), (6, 20), PASSIVE-SCAN >>> (5250 - 5330 @ 160), (6, 20), DFS, PASSIVE-SCAN >>> (5490 - 5730 @ 160), (6, 20), DFS, PASSIVE-SCAN >>> >>> Dmesg only spits out: >>> [ 383.849977] cfg80211: Pending regulatory request, waiting for it to be processed... >>> >> As has been explained previously, this indicates that, somehow, CRDA >> is not answering the kernel's requests as it should. Looking at the >> dmesg you posted before, we have: >> [ 3.862108] cfg80211: Calling CRDA to update world regulatory domain >> which never gets a reply. >> Are you using your distro's official CRDA package or have you compiled >> your own? It might not be installed properly as it looks like it's not >> responding to the kernel's call to update the world regulatory domain. >> There's more to installing CRDA than just sticking the executable and >> database in the right places. > It's the official Debian package. > But i have tried to compile the db.txt into the kernel as is mentioned and use the internalregdb kernel config option. > Could it be that since i compile all modules in the kernel and use --initrd .. that the CRDA is just not > available at *that* earlier moment in boot when that module gets activated ? > If so, wouldn't it be feasible to have > a) timeout with error message > b) clearing the request so a subsequent request can be made ? > The way the patches that where posted then circumvent the problem is by just plain ignoring the blocked request. > I could see if compiling them as loadable modules helps, another thing would be shoveling the whole CRDA stuff > into initrd. >> On my system here, I have: >> [ 16.981114] cfg80211: Calling CRDA to update world regulatory domain >> ... >> [ 17.300582] cfg80211: World regulatory domain updated: >> [ 17.300592] cfg80211: (start_freq - end_freq @ bandwidth), >> (max_antenna_gain, max_eirp) >> [ 17.300594] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), >> (300 mBi, 2000 mBm) >> [ 17.300597] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), >> (300 mBi, 2000 mBm) >> [ 17.300598] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), >> (300 mBi, 2000 mBm) >> [ 17.300600] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), >> (300 mBi, 2000 mBm) >> [ 17.300602] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), >> (300 mBi, 2000 mBm) >> Your dmesg doesn't have the response listed, therefore CRDA is not >> responding to the kernel's requests. The kernel will not make >> additional requests until the previous one is answered. >>> e) So why doesn't this whole regulatory mumbojumbo and the Linux implementation in particular let me abide the law ?!? Wasn't that it's *sole* point of existence ? >> It _is_ doing this. >> The world regulatory domain is the intersection of all the regulatory >> domains we know of. This is the _most_ restricted version which >> _ensures_ that you're obeying the law _everywhere_. >>> f) Why doesn't seem anyone to be seriously looking at it (for over a month now, while everyone from wireless/80211 to intel driver maintainers were CC'ed) ? >> Because there is no bug in the kernel, the bug is in your system's setup. > I will leave this one in the clear for the moment ... (nope i will not .. see below ;-) ) >>> g) Saying it has got to do with reg db's not being found or all kinds of other arguments while >>> the report clearly stated the way it can be circumvented by 2 simple patches that don't seem to involve any changes to >>> how it finds the reg db (apart from that i tested that a few times on request and indicated it didn't matter) >>> in current 3.13 code (and 3.12 and perhaps even earlier) (case 1) >>> or >>> with current wireless-next pulled (which has quite some changes to reg.c but none fixes this) onto 3.13 (case 2) >>> Neither of these patches might be correct codewise, but at least it let's me set the regulatory domain, and the current state the code is in is neither correct. >> These patches _break_ the functionality of the kernel, not fix it. >> They allow the kernel to issue requests before the previous one is >> answered. This is a bug. There are good reasons why this is not >> allowed. > Yes because for some reason it's allowed for requests to block for ever ... which could be considered a bug. > So yes it's the wrong fix ... but it at least identifies a problem .. infinite blocking requests. > I will report back when i have tested converting the wireless stuff to loadable modules / seeing if i can put the CRDA stuff in initrd. With all the wireless stuff switched to loadable modules it *does* work. So the problem is that: The current code blocks all future regulatory domain setting attempts forever (till the next reboot) when it can't find the CRDA. This can and does happen when the modules are compiled in and the CRDA is not in initrd. So from the question department: A) Why doesn't the code timeout the processing of a regulatory domain hint and remove the pending request when it aborts ? B) Why isn't the CRDA treated as firmware and placed in /lib/firmware, which has a much greater chance of automagically appearing in initrd ? C) Why as a bare minimum, doesn't it have a sane readable warning about not being able to read *which* exact file, without having to second guess to *why* the regulatory hint processing is taking *forever* ? >> Thanks, -- Best regards, Sander mailto:linux@eikelenboom.it ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work. 2013-12-17 20:33 ` Sander Eikelenboom @ 2013-12-17 21:27 ` Ben Hutchings 2013-12-17 21:49 ` Sander Eikelenboom 0 siblings, 1 reply; 38+ messages in thread From: Ben Hutchings @ 2013-12-17 21:27 UTC (permalink / raw) To: Sander Eikelenboom Cc: Julian Calaby, Arend van Spriel, Luis R. Rodriguez, Linus Torvalds, Berg, Johannes, Grumbach, Emmanuel, linux-kernel@vger.kernel.org, ilw@linux.intel.com, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, John W. Linville, Avinash Patil On Tue, Dec 17, 2013 at 09:33:19PM +0100, Sander Eikelenboom wrote: [...] > > It's the official Debian package. [...] > > I will report back when i have tested converting the wireless stuff to loadable modules / seeing if i can put the CRDA stuff in initrd. > > With all the wireless stuff switched to loadable modules it *does* work. > > So the problem is that: > The current code blocks all future regulatory domain setting attempts forever (till the next reboot) > when it can't find the CRDA. This can and does happen when the modules are compiled in and the CRDA is not in initrd. > > So from the question department: > > A) Why doesn't the code timeout the processing of a regulatory domain hint and remove the pending request when it aborts ? > B) Why isn't the CRDA treated as firmware and placed in /lib/firmware, which has a much greater chance of automagically appearing in initrd ? [...] It doesn't make any logical sense to put a userland program in /lib/firmware, and it wouldn't have any effect on the initramfs builders I'm familiar with (which look at module metadata to work out which files to include from /lib/firmware). Debian official kernels use modular drivers, and neither initramfs-tools nor dracut includes wireless drivers in the initramfs. If you build a custom kernel with built-in drivers then you most likely don't need an initramfs at all. As maintainer of crda in Debian, I could add an initramfs hook that would include it in an initramfs. But I don't understand why it would be worth doing so. Why is it so useful to have wireless drivers built-in *and* an initramfs? If you think I should do this then open a bug (reportbug crda). Ben. -- Ben Hutchings Life would be so much easier if we could look at the source code. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work. 2013-12-17 21:27 ` Ben Hutchings @ 2013-12-17 21:49 ` Sander Eikelenboom 2013-12-17 22:06 ` Linus Torvalds ` (2 more replies) 0 siblings, 3 replies; 38+ messages in thread From: Sander Eikelenboom @ 2013-12-17 21:49 UTC (permalink / raw) To: Ben Hutchings Cc: Julian Calaby, Arend van Spriel, Luis R. Rodriguez, Linus Torvalds, Berg, Johannes, Grumbach, Emmanuel, linux-kernel@vger.kernel.org, ilw@linux.intel.com, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, John W. Linville, Avinash Patil Tuesday, December 17, 2013, 10:27:09 PM, you wrote: > On Tue, Dec 17, 2013 at 09:33:19PM +0100, Sander Eikelenboom wrote: > [...] >> > It's the official Debian package. > [...] >> > I will report back when i have tested converting the wireless stuff to loadable modules / seeing if i can put the CRDA stuff in initrd. >> >> With all the wireless stuff switched to loadable modules it *does* work. >> >> So the problem is that: >> The current code blocks all future regulatory domain setting attempts forever (till the next reboot) >> when it can't find the CRDA. This can and does happen when the modules are compiled in and the CRDA is not in initrd. >> >> So from the question department: >> >> A) Why doesn't the code timeout the processing of a regulatory domain hint and remove the pending request when it aborts ? >> B) Why isn't the CRDA treated as firmware and placed in /lib/firmware, which has a much greater chance of automagically appearing in initrd ? > [...] > It doesn't make any logical sense to put a userland program in > /lib/firmware, and it wouldn't have any effect on the initramfs > builders I'm familiar with (which look at module metadata to work > out which files to include from /lib/firmware). Ah yes of course stupid, it's not just a blob of the regdb but a userland program. > Debian official kernels use modular drivers, and neither > initramfs-tools nor dracut includes wireless drivers in the initramfs. > If you build a custom kernel with built-in drivers then you most > likely don't need an initramfs at all. > As maintainer of crda in Debian, I could add an initramfs hook that > would include it in an initramfs. But I don't understand why it would > be worth doing so. Why is it so useful to have wireless drivers > built-in *and* an initramfs? If you think I should do this then open > a bug (reportbug crda). Indeed, I looked for a crda hook for initramfs-tools but didn't find it, so skipped that idea for the moment. So if i combine the two .. it's essentially just a very bad idea to compile the wireless stuff in. It needs a access to a userland program at module load time, or it will block forever. > Ben. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work. 2013-12-17 21:49 ` Sander Eikelenboom @ 2013-12-17 22:06 ` Linus Torvalds 2013-12-18 9:16 ` Arend van Spriel 2013-12-17 23:35 ` Julian Calaby 2013-12-18 7:50 ` Pontus Fuchs 2 siblings, 1 reply; 38+ messages in thread From: Linus Torvalds @ 2013-12-17 22:06 UTC (permalink / raw) To: Sander Eikelenboom Cc: Ben Hutchings, Julian Calaby, Arend van Spriel, Luis R. Rodriguez, Berg, Johannes, Grumbach, Emmanuel, linux-kernel@vger.kernel.org, ilw@linux.intel.com, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, John W. Linville, Avinash Patil On Tue, Dec 17, 2013 at 1:49 PM, Sander Eikelenboom <linux@eikelenboom.it> wrote: > > So if i combine the two .. it's essentially just a very bad idea to compile the wireless stuff in. > It needs a access to a userland program at module load time, or it will block forever. No, it's a very stupid module if it does that. It should require the crda hook not at module load time, but at first ifconfig time. We've had bugs like this before. Doing user-mode callbacks at module loading time is a disaster exactly because it doesn't work well with built-in modules. The fact that those things apparently also don't time out or notice when they fail seems to then just exacerbate the bad decision. We have literally had this *exact* same issue with firmware loading. Network drivers shouldn't try to load firmware at module load time. Same deal. What's the broken path? Is this driver-specific, or is it generic to the 802.11 code? Linus ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work. 2013-12-17 22:06 ` Linus Torvalds @ 2013-12-18 9:16 ` Arend van Spriel 2013-12-18 9:18 ` Grumbach, Emmanuel ` (2 more replies) 0 siblings, 3 replies; 38+ messages in thread From: Arend van Spriel @ 2013-12-18 9:16 UTC (permalink / raw) To: Linus Torvalds, Sander Eikelenboom Cc: Ben Hutchings, Julian Calaby, Luis R. Rodriguez, Berg, Johannes, Grumbach, Emmanuel, linux-kernel@vger.kernel.org, ilw@linux.intel.com, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, John W. Linville, Avinash Patil On 12/17/2013 11:06 PM, Linus Torvalds wrote: > We have literally had this *exact* same issue with firmware loading. > Network drivers shouldn't try to load firmware at module load time. > Same deal. It is kind of a chicken and egg problem for (wireless) networking drivers. To get IFF_UP from the network layer you have to register a netdevice. For wireless drivers this means you have to register a wiphy device with cfg80211 which flags capabilities and optionally are custom regulatory domain. That information depends on the device and firmware used. And there we have a full circle. Regards, Arend ^ permalink raw reply [flat|nested] 38+ messages in thread
* RE: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work. 2013-12-18 9:16 ` Arend van Spriel @ 2013-12-18 9:18 ` Grumbach, Emmanuel 2013-12-18 9:25 ` Sander Eikelenboom 2013-12-18 9:26 ` Johannes Berg 2 siblings, 0 replies; 38+ messages in thread From: Grumbach, Emmanuel @ 2013-12-18 9:18 UTC (permalink / raw) To: Arend van Spriel, Linus Torvalds, Sander Eikelenboom Cc: Ben Hutchings, Julian Calaby, Luis R. Rodriguez, Berg, Johannes, linux-kernel@vger.kernel.org, ilw@linux.intel.com, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, John W. Linville, Avinash Patil [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1086 bytes --] > > On 12/17/2013 11:06 PM, Linus Torvalds wrote: > > We have literally had this *exact* same issue with firmware loading. > > Network drivers shouldn't try to load firmware at module load time. > > Same deal. > > It is kind of a chicken and egg problem for (wireless) networking drivers. To > get IFF_UP from the network layer you have to register a netdevice. For > wireless drivers this means you have to register a wiphy device with cfg80211 > which flags capabilities and optionally are custom regulatory domain. That > information depends on the device and firmware used. And there we have a > full circle. > To solve this - iwlwifi uses request_firmware_nowait. Its doc reads: "Asynchronous variant of request_firmware for user contexts: - sleep for as small periods as possible since it may increase kernel boot time of built-in device drivers requesting firmware in their ->probe methods, if gfp is GFP_KERNEL." ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥ ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work. 2013-12-18 9:16 ` Arend van Spriel 2013-12-18 9:18 ` Grumbach, Emmanuel @ 2013-12-18 9:25 ` Sander Eikelenboom 2013-12-18 9:26 ` Johannes Berg 2 siblings, 0 replies; 38+ messages in thread From: Sander Eikelenboom @ 2013-12-18 9:25 UTC (permalink / raw) To: Arend van Spriel Cc: Linus Torvalds, Ben Hutchings, Julian Calaby, Luis R. Rodriguez, Berg, Johannes, Grumbach, Emmanuel, linux-kernel@vger.kernel.org, ilw@linux.intel.com, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, John W. Linville, Avinash Patil Wednesday, December 18, 2013, 10:16:38 AM, you wrote: > On 12/17/2013 11:06 PM, Linus Torvalds wrote: >> We have literally had this *exact* same issue with firmware loading. >> Network drivers shouldn't try to load firmware at module load time. >> Same deal. > It is kind of a chicken and egg problem for (wireless) networking > drivers. To get IFF_UP from the network layer you have to register a > netdevice. For wireless drivers this means you have to register a wiphy > device with cfg80211 which flags capabilities and optionally are custom > regulatory domain. That information depends on the device and firmware > used. And there we have a full circle. Very well, but: If it can't access the CRDA and it is setting the world domain, why on earth is it blocking any subsequent requests to setting the regulatory domain from userspace when the CRDA *is* accessible ? I mean, i could see the need to do something *temporary* at boot when accessing the CRDA fails and to take the most safe default for the time being .. The BUG is that it is NOT temporary, but blocking until next reboot because the first request wasn't completely processed. My hostapd will try to set the domain when it starts and at that point the CRDA is accessible, so it would set it from the temporary domain to the one specified, as long as it isn't blocking. > Regards, > Arend ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work. 2013-12-18 9:16 ` Arend van Spriel 2013-12-18 9:18 ` Grumbach, Emmanuel 2013-12-18 9:25 ` Sander Eikelenboom @ 2013-12-18 9:26 ` Johannes Berg 2013-12-18 10:48 ` Sander Eikelenboom 2 siblings, 1 reply; 38+ messages in thread From: Johannes Berg @ 2013-12-18 9:26 UTC (permalink / raw) To: Arend van Spriel Cc: Linus Torvalds, Sander Eikelenboom, Ben Hutchings, Julian Calaby, Luis R. Rodriguez, Grumbach, Emmanuel, linux-kernel@vger.kernel.org, ilw@linux.intel.com, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, John W. Linville, Avinash Patil Hi all, We really should be asking Luis to look at this who hasn't yet chimed in, presumably because he's between jobs (and travelling IIRC) On Wed, 2013-12-18 at 10:16 +0100, Arend van Spriel wrote: > On 12/17/2013 11:06 PM, Linus Torvalds wrote: > > We have literally had this *exact* same issue with firmware loading. > > Network drivers shouldn't try to load firmware at module load time. > > Same deal. > > It is kind of a chicken and egg problem for (wireless) networking > drivers. To get IFF_UP from the network layer you have to register a > netdevice. For wireless drivers this means you have to register a wiphy > device with cfg80211 which flags capabilities and optionally are custom > regulatory domain. That information depends on the device and firmware > used. And there we have a full circle. This is all really beside the point. For this CRDA information, the kernel never actually *waits* for it, so in the case that there's no reply, it uses the built-in world domain. So it's not like request_firmware(), which will block boot forever, but it's also not like request_firmware_nowait() which will eventually time out and come back with an error if userspace isn't handling it (though now that firmware loading is built in ...) The issue is that it uses the built-in data *forever*, and what Sander said was "or it will block forever" but just meant that it never was able to do any further updates. It *doesn't* actually block the boot process or such. Everything Linus said is true but seems to have been written in understanding "blocks" as "blocking the boot process", rather than "blocking further updates". Regardless of this, even blocking further updates is a really bad idea. There are a few ways to handle this, but I'll let Luis poke at that. johannes ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work. 2013-12-18 9:26 ` Johannes Berg @ 2013-12-18 10:48 ` Sander Eikelenboom 2013-12-18 19:43 ` Luis R. Rodriguez 0 siblings, 1 reply; 38+ messages in thread From: Sander Eikelenboom @ 2013-12-18 10:48 UTC (permalink / raw) To: Johannes Berg Cc: Arend van Spriel, Linus Torvalds, Ben Hutchings, Julian Calaby, Luis R. Rodriguez, Grumbach, Emmanuel, linux-kernel@vger.kernel.org, ilw@linux.intel.com, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, John W. Linville, Avinash Patil Wednesday, December 18, 2013, 10:26:25 AM, you wrote: > Hi all, > We really should be asking Luis to look at this who hasn't yet chimed > in, presumably because he's between jobs (and travelling IIRC) > On Wed, 2013-12-18 at 10:16 +0100, Arend van Spriel wrote: >> On 12/17/2013 11:06 PM, Linus Torvalds wrote: >> > We have literally had this *exact* same issue with firmware loading. >> > Network drivers shouldn't try to load firmware at module load time. >> > Same deal. >> >> It is kind of a chicken and egg problem for (wireless) networking >> drivers. To get IFF_UP from the network layer you have to register a >> netdevice. For wireless drivers this means you have to register a wiphy >> device with cfg80211 which flags capabilities and optionally are custom >> regulatory domain. That information depends on the device and firmware >> used. And there we have a full circle. > This is all really beside the point. > For this CRDA information, the kernel never actually *waits* for it, so > in the case that there's no reply, it uses the built-in world domain. So > it's not like request_firmware(), which will block boot forever, but > it's also not like request_firmware_nowait() which will eventually time > out and come back with an error if userspace isn't handling it (though > now that firmware loading is built in ...) > The issue is that it uses the built-in data *forever*, and what Sander > said was "or it will block forever" but just meant that it never was > able to do any further updates. > It *doesn't* actually block the boot process or such. Everything Linus > said is true but seems to have been written in understanding "blocks" as > "blocking the boot process", rather than "blocking further updates". > Regardless of this, even blocking further updates is a really bad idea. > There are a few ways to handle this, but I'll let Luis poke at that. Your description is correct, sorry if I was not clear. -- Sander > johannes ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work. 2013-12-18 10:48 ` Sander Eikelenboom @ 2013-12-18 19:43 ` Luis R. Rodriguez 2013-12-18 19:45 ` Sander Eikelenboom 0 siblings, 1 reply; 38+ messages in thread From: Luis R. Rodriguez @ 2013-12-18 19:43 UTC (permalink / raw) To: Sander Eikelenboom Cc: Johannes Berg, Arend van Spriel, Linus Torvalds, Ben Hutchings, Julian Calaby, Grumbach, Emmanuel, linux-kernel@vger.kernel.org, ilw@linux.intel.com, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, John W. Linville, Avinash Patil On Wed, Dec 18, 2013 at 11:48:45AM +0100, Sander Eikelenboom wrote: > > Wednesday, December 18, 2013, 10:26:25 AM, you wrote: > > > Hi all, > > > We really should be asking Luis to look at this who hasn't yet chimed > > in, presumably because he's between jobs (and travelling IIRC) > > > On Wed, 2013-12-18 at 10:16 +0100, Arend van Spriel wrote: > >> On 12/17/2013 11:06 PM, Linus Torvalds wrote: > >> > We have literally had this *exact* same issue with firmware loading. > >> > Network drivers shouldn't try to load firmware at module load time. > >> > Same deal. > >> > >> It is kind of a chicken and egg problem for (wireless) networking > >> drivers. To get IFF_UP from the network layer you have to register a > >> netdevice. For wireless drivers this means you have to register a wiphy > >> device with cfg80211 which flags capabilities and optionally are custom > >> regulatory domain. That information depends on the device and firmware > >> used. And there we have a full circle. > > > This is all really beside the point. > > > For this CRDA information, the kernel never actually *waits* for it, so > > in the case that there's no reply, it uses the built-in world domain. So > > it's not like request_firmware(), which will block boot forever, but > > it's also not like request_firmware_nowait() which will eventually time > > out and come back with an error if userspace isn't handling it (though > > now that firmware loading is built in ...) > > > The issue is that it uses the built-in data *forever*, and what Sander > > said was "or it will block forever" but just meant that it never was > > able to do any further updates. > > > It *doesn't* actually block the boot process or such. Everything Linus > > said is true but seems to have been written in understanding "blocks" as > > "blocking the boot process", rather than "blocking further updates". > > > Regardless of this, even blocking further updates is a really bad idea. > > There are a few ways to handle this, but I'll let Luis poke at that. > > Your description is correct, sorry if I was not clear. We have a timeout handler for this, I'll check to see what's going on by trying to reproduce on my end. Are you using wireless-testing ? Luis ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work. 2013-12-18 19:43 ` Luis R. Rodriguez @ 2013-12-18 19:45 ` Sander Eikelenboom 2013-12-19 4:57 ` Luis R. Rodriguez 0 siblings, 1 reply; 38+ messages in thread From: Sander Eikelenboom @ 2013-12-18 19:45 UTC (permalink / raw) To: Luis R. Rodriguez Cc: Johannes Berg, Arend van Spriel, Linus Torvalds, Ben Hutchings, Julian Calaby, Grumbach, Emmanuel, linux-kernel@vger.kernel.org, ilw@linux.intel.com, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, John W. Linville, Avinash Patil Wednesday, December 18, 2013, 8:43:28 PM, you wrote: > On Wed, Dec 18, 2013 at 11:48:45AM +0100, Sander Eikelenboom wrote: >> >> Wednesday, December 18, 2013, 10:26:25 AM, you wrote: >> >> > Hi all, >> >> > We really should be asking Luis to look at this who hasn't yet chimed >> > in, presumably because he's between jobs (and travelling IIRC) >> >> > On Wed, 2013-12-18 at 10:16 +0100, Arend van Spriel wrote: >> >> On 12/17/2013 11:06 PM, Linus Torvalds wrote: >> >> > We have literally had this *exact* same issue with firmware loading. >> >> > Network drivers shouldn't try to load firmware at module load time. >> >> > Same deal. >> >> >> >> It is kind of a chicken and egg problem for (wireless) networking >> >> drivers. To get IFF_UP from the network layer you have to register a >> >> netdevice. For wireless drivers this means you have to register a wiphy >> >> device with cfg80211 which flags capabilities and optionally are custom >> >> regulatory domain. That information depends on the device and firmware >> >> used. And there we have a full circle. >> >> > This is all really beside the point. >> >> > For this CRDA information, the kernel never actually *waits* for it, so >> > in the case that there's no reply, it uses the built-in world domain. So >> > it's not like request_firmware(), which will block boot forever, but >> > it's also not like request_firmware_nowait() which will eventually time >> > out and come back with an error if userspace isn't handling it (though >> > now that firmware loading is built in ...) >> >> > The issue is that it uses the built-in data *forever*, and what Sander >> > said was "or it will block forever" but just meant that it never was >> > able to do any further updates. >> >> > It *doesn't* actually block the boot process or such. Everything Linus >> > said is true but seems to have been written in understanding "blocks" as >> > "blocking the boot process", rather than "blocking further updates". >> >> > Regardless of this, even blocking further updates is a really bad idea. >> > There are a few ways to handle this, but I'll let Luis poke at that. >> >> Your description is correct, sorry if I was not clear. > We have a timeout handler for this, I'll check to see what's going on > by trying to reproduce on my end. Are you using wireless-testing ? Originally 3.13-rc4, after that i tried with 3.13-rc4 with wireless-next pulled on top of it (since there were major changes to reg.c) but the problem occurs with both. > Luis ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work. 2013-12-18 19:45 ` Sander Eikelenboom @ 2013-12-19 4:57 ` Luis R. Rodriguez 0 siblings, 0 replies; 38+ messages in thread From: Luis R. Rodriguez @ 2013-12-19 4:57 UTC (permalink / raw) To: Sander Eikelenboom Cc: Johannes Berg, Arend van Spriel, Linus Torvalds, Ben Hutchings, Julian Calaby, Grumbach, Emmanuel, linux-kernel@vger.kernel.org, ilw@linux.intel.com, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, John W. Linville, Avinash Patil On Wed, Dec 18, 2013 at 08:45:46PM +0100, Sander Eikelenboom wrote: > > Wednesday, December 18, 2013, 8:43:28 PM, you wrote: > > > On Wed, Dec 18, 2013 at 11:48:45AM +0100, Sander Eikelenboom wrote: > >> > >> Wednesday, December 18, 2013, 10:26:25 AM, you wrote: > >> > >> > Hi all, > >> > >> > We really should be asking Luis to look at this who hasn't yet chimed > >> > in, presumably because he's between jobs (and travelling IIRC) > >> > >> > On Wed, 2013-12-18 at 10:16 +0100, Arend van Spriel wrote: > >> >> On 12/17/2013 11:06 PM, Linus Torvalds wrote: > >> >> > We have literally had this *exact* same issue with firmware loading. > >> >> > Network drivers shouldn't try to load firmware at module load time. > >> >> > Same deal. > >> >> > >> >> It is kind of a chicken and egg problem for (wireless) networking > >> >> drivers. To get IFF_UP from the network layer you have to register a > >> >> netdevice. For wireless drivers this means you have to register a wiphy > >> >> device with cfg80211 which flags capabilities and optionally are custom > >> >> regulatory domain. That information depends on the device and firmware > >> >> used. And there we have a full circle. > >> > >> > This is all really beside the point. > >> > >> > For this CRDA information, the kernel never actually *waits* for it, so > >> > in the case that there's no reply, it uses the built-in world domain. So > >> > it's not like request_firmware(), which will block boot forever, but > >> > it's also not like request_firmware_nowait() which will eventually time > >> > out and come back with an error if userspace isn't handling it (though > >> > now that firmware loading is built in ...) > >> > >> > The issue is that it uses the built-in data *forever*, and what Sander > >> > said was "or it will block forever" but just meant that it never was > >> > able to do any further updates. > >> > >> > It *doesn't* actually block the boot process or such. Everything Linus > >> > said is true but seems to have been written in understanding "blocks" as > >> > "blocking the boot process", rather than "blocking further updates". > >> > >> > Regardless of this, even blocking further updates is a really bad idea. > >> > There are a few ways to handle this, but I'll let Luis poke at that. > >> > >> Your description is correct, sorry if I was not clear. > > > We have a timeout handler for this, I'll check to see what's going on > > by trying to reproduce on my end. Are you using wireless-testing ? > > Originally 3.13-rc4, after that i tried with 3.13-rc4 with wireless-next pulled on top of it > (since there were major changes to reg.c) but the problem occurs with both. OK I can reproduce and am working on the cleanest solution. Thanks for your report, I'll Cc ya when I have something reasonable baked up, hopefully rather soon! Luis ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work. 2013-12-17 21:49 ` Sander Eikelenboom 2013-12-17 22:06 ` Linus Torvalds @ 2013-12-17 23:35 ` Julian Calaby 2013-12-18 7:50 ` Pontus Fuchs 2 siblings, 0 replies; 38+ messages in thread From: Julian Calaby @ 2013-12-17 23:35 UTC (permalink / raw) To: Sander Eikelenboom Cc: Ben Hutchings, Arend van Spriel, Luis R. Rodriguez, Linus Torvalds, Berg, Johannes, Grumbach, Emmanuel, linux-kernel@vger.kernel.org, ilw@linux.intel.com, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, John W. Linville, Avinash Patil Hi All, On Wed, Dec 18, 2013 at 8:49 AM, Sander Eikelenboom <linux@eikelenboom.it> wrote: > > Tuesday, December 17, 2013, 10:27:09 PM, you wrote: > >> On Tue, Dec 17, 2013 at 09:33:19PM +0100, Sander Eikelenboom wrote: >> Debian official kernels use modular drivers, and neither >> initramfs-tools nor dracut includes wireless drivers in the initramfs. >> If you build a custom kernel with built-in drivers then you most >> likely don't need an initramfs at all. > >> As maintainer of crda in Debian, I could add an initramfs hook that >> would include it in an initramfs. But I don't understand why it would >> be worth doing so. Why is it so useful to have wireless drivers >> built-in *and* an initramfs? If you think I should do this then open >> a bug (reportbug crda). > > Indeed, I looked for a crda hook for initramfs-tools but didn't find it, so skipped that idea > for the moment. > > So if i combine the two .. it's essentially just a very bad idea to compile the wireless stuff in. > It needs a access to a userland program at module load time, or it will block forever. >From looking at the code and files in the Debian package, the CRDA "calls" are actually events which are then handled by udev. So what happens to events passed to udev which aren't handled by any of it's (current) rules? Thanks, -- Julian Calaby Email: julian.calaby@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ .Plan: http://sites.google.com/site/juliancalaby/ ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work. 2013-12-17 21:49 ` Sander Eikelenboom 2013-12-17 22:06 ` Linus Torvalds 2013-12-17 23:35 ` Julian Calaby @ 2013-12-18 7:50 ` Pontus Fuchs 2013-12-18 8:58 ` Arend van Spriel 2 siblings, 1 reply; 38+ messages in thread From: Pontus Fuchs @ 2013-12-18 7:50 UTC (permalink / raw) To: Sander Eikelenboom, Ben Hutchings Cc: Julian Calaby, Arend van Spriel, Luis R. Rodriguez, Linus Torvalds, Berg, Johannes, Grumbach, Emmanuel, linux-kernel@vger.kernel.org, ilw@linux.intel.com, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, John W. Linville, Avinash Patil On 2013-12-17 22:49, Sander Eikelenboom wrote: > > Indeed, I looked for a crda hook for initramfs-tools but didn't find it, so skipped that idea > for the moment. > > So if i combine the two .. it's essentially just a very bad idea to compile the wireless stuff in. > It needs a access to a userland program at module load time, or it will block forever. The canonical trick to have cfg80211 built in is to execute crda manually in your boot scripts. This will satisfy the initial request and resolve the block. Cheers, Pontus ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work. 2013-12-18 7:50 ` Pontus Fuchs @ 2013-12-18 8:58 ` Arend van Spriel 0 siblings, 0 replies; 38+ messages in thread From: Arend van Spriel @ 2013-12-18 8:58 UTC (permalink / raw) To: Pontus Fuchs, Sander Eikelenboom, Ben Hutchings Cc: Julian Calaby, Luis R. Rodriguez, Linus Torvalds, Berg, Johannes, Grumbach, Emmanuel, linux-kernel@vger.kernel.org, ilw@linux.intel.com, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, John W. Linville, Avinash Patil On 12/18/2013 08:50 AM, Pontus Fuchs wrote: > On 2013-12-17 22:49, Sander Eikelenboom wrote: >> >> Indeed, I looked for a crda hook for initramfs-tools but didn't find >> it, so skipped that idea >> for the moment. >> >> So if i combine the two .. it's essentially just a very bad idea to >> compile the wireless stuff in. >> It needs a access to a userland program at module load time, or it >> will block forever. > > The canonical trick to have cfg80211 built in is to execute crda > manually in your boot scripts. This will satisfy the initial request and > resolve the block. There is a Kconfig option to have the regulatory data built-in the kernel as well. Obviously that makes a regulatory update more difficult. net/wireless/Kconfig: config CFG80211_INTERNAL_REGDB bool "use statically compiled regulatory rules database" if EXPERT Regards, AvS ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work. 2013-12-16 12:56 ` Sander Eikelenboom 2013-12-17 2:17 ` Julian Calaby @ 2013-12-18 19:27 ` Luis R. Rodriguez 1 sibling, 0 replies; 38+ messages in thread From: Luis R. Rodriguez @ 2013-12-18 19:27 UTC (permalink / raw) To: Sander Eikelenboom Cc: Arend van Spriel, Linus Torvalds, Berg, Johannes, Grumbach, Emmanuel, linux-kernel@vger.kernel.org, ilw@linux.intel.com, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, John W. Linville, Avinash Patil On Mon, Dec 16, 2013 at 01:56:44PM +0100, Sander Eikelenboom wrote: > > Let's start from scratch then ... > > > a) Isn't the point of the whole regulatory domain system that i can > select (and restrict) the channels/frequencies my devices transmits > on, so i can abide the law ? The point is to support all forms of vendor desired architecture. Letting userspace help regulatory with its own picked ISO3166-alpha2 is one feature and we support allowing userspace to distinguish the input source if its from userspace -- today we support a source from userspace to come from the user or a cellular base station. What is done for each of these will depend on the vendor and their own preference, and the specific device's own architecture By default Linux will trust the user, but if the driver wants, it will only use the user input to enhance regulatory, never to allow more. The matrix of possibilities varies depending on the architecture of the driver and firmware. So its best then to describe the issue specifically keeping in mind what device driver and firmware you are using, rather than assuming general things for the different scenerios. > b) If so, does it set a regulatory domain from firmware ? It depends on the device. In your case the driver reads channels that are allowed from EEPROM, then uses that information to set the channel data structures before wiphy registration to cfg80211. cfg80211 then will use this as the 'base set' of channels that are allowed, no further input can enable new channels unless regulatory_hint() is used by the driver. In your case you cannot do anything other than 'restrict' the device further and I don't think you want to do that -- given that the vendor already assumed testing / compliance with what it hand and they are OK with that! > c) If so, should it let me *restrict* the available channels even more > by setting the regulatory domain to the region in which de device is > currently being used ? Yeap. > d) If so, why am i not able to do so with my intel driver for a long time > (for over a month now). > # iw reg get > country 00: > (2402 - 2472 @ 40), (6, 20) > (2457 - 2482 @ 40), (6, 20), PASSIVE-SCAN > (2474 - 2494 @ 20), (6, 20), NO-OFDM, PASSIVE-SCAN > (5170 - 5250 @ 160), (6, 20), PASSIVE-SCAN > (5250 - 5330 @ 160), (6, 20), DFS, PASSIVE-SCAN > (5490 - 5730 @ 160), (6, 20), DFS, PASSIVE-SCAN > # iw reg set US > # iw reg get > country 00: > (2402 - 2472 @ 40), (6, 20) > (2457 - 2482 @ 40), (6, 20), PASSIVE-SCAN > (2474 - 2494 @ 20), (6, 20), NO-OFDM, PASSIVE-SCAN > (5170 - 5250 @ 160), (6, 20), PASSIVE-SCAN > (5250 - 5330 @ 160), (6, 20), DFS, PASSIVE-SCAN > (5490 - 5730 @ 160), (6, 20), DFS, PASSIVE-SCAN You originally seemed to believe that using this will let you use channels that the EEPROM and firmware does not allow, this is not the case. The expectation that this will help you *restrict* the device is correct thoug and the fact that its not going through is an issue and I'm happy to review that case and fix it, as that should work. My initial review from your kernel log though was that CRDA was not installed or if it was installed it was not sending the information to the kernel, which could have been an issue with the signature of the reguatory database -- the kernel log you showed so far reflects no updates being sent by CRDA. You have two options to help troubleshoot this, which I had indicated before. One is to use CONFIG_CFG80211_INTERNAL_REGDB and throw the regulatory database file into the kernel upon build on net/wireless/db.txt. The other is to troubleshoot the regulatory domain not getting to the kernel via udev and CRDA. > Dmesg only spits out: > [ 383.849977] cfg80211: Pending regulatory request, waiting for it to be processed... This indicates to us that there is an original regulatory request that was issued and has not been processed by userspace. There is a timeout for this, 3.14 seconds, and if 3.14 seconds go by without this being processed we clear it and new regulatory requests should be allowed after that. > e) So why doesn't this whole regulatory mumbojumbo and the Linux > implementation in particular let me abide the law ?!? Wasn't that it's > *sole* point of existence ? You are abiding by the law. The issue you are describing seems to be an issue likely fixed in older kernels, the timeout on pending requests was fixed long ago so I'd like to get more information on the kernel version you are using to see if I can see what's going on. > f) Why doesn't seem anyone to be seriously looking at it (for over a > month now, while everyone from wireless/80211 to intel driver > maintainers were CC'ed) ? No one except myself is looking into this, and I have been busy as I quit my job and have been traveling and juggling other things. You were also confusing things, despite my clarifications on things, and the issue you repoted is not something I was able to reproduce. > g) Saying it has got to do with reg db's not being found or all kinds > of other arguments while the report clearly stated the way it can be > circumvented by 2 simple patches that don't seem to involve any > changes to how it finds the reg db (apart from that i tested that a > few times on request and indicated it didn't matter) in current 3.13 > code (and 3.12 and perhaps even earlier) (case 1) or > with current wireless-next pulled (which has quite some changes to > reg.c but none fixes this) onto 3.13 (case 2) Neither of these > patches might be correct codewise, but at least it let's me set the > regulatory domain, and the current state the code is in is neither > correct. You are just jumbling things around for your own purpose. Stop that. The issue is either a timeout is not being cleared and/or CRDA is not getting the request to the kernel. Let's focus on that. > h) Added Linus to the CC, you never know if that automagically kicks > things in gear ... (hopefully not in reverse :-p) That won't help cure anything. > Case 1 - patch that makes it possible to set the regulatory domain > without silently ignoring it - applies to 3.13-rc4 > > diff --git a/net/wireless/reg.c b/net/wireless/reg.c > > index 7da67fd..e8ab82e 100644 > --- a/net/wireless/reg.c > +++ b/net/wireless/reg.c > @@ -1579,7 +1579,7 @@ static void reg_process_pending_hints(void) > /* When last_request->processed becomes true this will be rescheduled */ > if (lr && !lr->processed) { > REG_DBG_PRINT("Pending regulatory request, waiting for it to be processed...\n"); > - return; > + /* return; */ > } > > spin_lock(®_requests_lock); > Again that patch is not correct and breaks things given that we have a timeout that will clear that. The real issue is your original request was not processed and we want it processed. Otherwise after 3.14 seconds from the original request you should be able to issue new requests. > Case 2 - RFC patch by Avinash Patil that makes it possible to set the > regulatory domain without silently ignoring it - applies to 3.13-rc4 + > wireless-next pulled onto it That patch was incorrect as I noted earlier. What we need to do is get down to the exact case you have to reproduce and fix. The issue you reported should already be addressed as I noted and if its not I wonder if your kernel is old or its a corner case we had not looked into before. Luis ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work. 2013-12-16 11:22 ` Sander Eikelenboom 2013-12-16 11:37 ` Arend van Spriel @ 2013-12-18 18:29 ` Luis R. Rodriguez 2013-12-18 18:54 ` Sander Eikelenboom 1 sibling, 1 reply; 38+ messages in thread From: Luis R. Rodriguez @ 2013-12-18 18:29 UTC (permalink / raw) To: Sander Eikelenboom Cc: Berg, Johannes, Grumbach, Emmanuel, linux-kernel@vger.kernel.org, ilw@linux.intel.com, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, John W. Linville On Mon, Dec 16, 2013 at 12:22:00PM +0100, Sander Eikelenboom wrote: > > Wednesday, December 11, 2013, 7:38:50 PM, you wrote: > > > On Wed, Dec 11, 2013 at 7:11 PM, Sander Eikelenboom > > <linux@eikelenboom.it> wrote: > >> > >> Wednesday, December 11, 2013, 6:53:07 PM, you wrote: > >> > >>> The best way to address all this is by automatic region awareness and > >>> doing the right thing on devices, this however requires good > >>> architecture / calibration data / etc and all that needs to be > >>> verified by the system integrators, and finally they need to be > >>> certified. If you want to hack your firmware and software go at it, > >>> just be aware there are reasons for things. > >> > >> Well the general problem seems to be "we don't trust the user" so we FORCE him to the lowest > >> common denominator (without a way to overrule that) so he is forced to operate *well* within the law. > > > Its simply stupid to have the user be involved, period, the fact that > > a user would be involved should only be for testing or helping > > compliance for a busted device, development, research and obviously > > hacking. Linux allows all these but by default a device with firmware > > and a custom regdomain that will barf if you try to use a channel that > > is not allowed is a restriction in firmware. Feel free to reverse > > engineer that if you don't like it but it just won't be supported or > > go upstream. Now, the common denominator is generally optimized for > > best performance as well so you shouldn't have to do anything, and for > > APs -- this is typically carefully crafted for a region, also highly > > optimized. > > >>>>> It doesn't seem like you are getting your original requests getting > >>>>> processed, so I don't think CRDA is passing it. Can you verify running > >>>>> from CRDA code: > >>>> > >>>> They don't get processed unless i remove the return from the code as i indicated. > >>>> If i remove that return it processes the request. > >>>> > >>>>> ./regdbdump /usr/lib/crda/regulatory.bin > >>>> > >>>> Although it's in a different location on Debian, /lib/crda/regulatory.bin > >>>> the dump seems fine. > >> > >>> OK thanks. Can you send a patch of what exact change you made, it was > >>> unclear from the paste you made. > >> > >>> diff -u file.c.orig file.c > >> > >> Well i just did a pull from wireless-next, to try Avinash Patil's patch. > >> net/wireless/reg.c had already changed much so i couldn't apply his patch without. > >> > >> With his patch it sets the regulatory domain, although as now expected i still can not use channels 12 and 13 yet, > >> probably due to those firmware restrictions. > > > Its unclear what results you got, and yeah if the device is restricted > > then its just the fw telling the driver its channels and you can't use > > them. That's it. You won't be able to override information then unless > > you hack the firmware > > Ping ? > > Is there anymore information you need to *fix* the problem ? I was away on Travel back home, and will soon be traveling to visit family so e-mail replies will be delayed, I'll jump on this thread now but in short: You are confusing the main issue you reported (cannot override regulatory) as a software issue rather than a firmware issue with intel firmware, you are also making claims and making people believe things work in different ways (I'll clarify things there, proper regulatory support without CRDA works, CRDA is just a helper, we also do have a timeout on requests). Lastly there is one issue that may be a software issue but I cannot reproduce which I am interested in getting down to the bottom to. I'll dive into the different things now. Luis ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work. 2013-12-18 18:29 ` Luis R. Rodriguez @ 2013-12-18 18:54 ` Sander Eikelenboom 2013-12-18 19:42 ` Luis R. Rodriguez 0 siblings, 1 reply; 38+ messages in thread From: Sander Eikelenboom @ 2013-12-18 18:54 UTC (permalink / raw) To: Luis R. Rodriguez Cc: Berg, Johannes, Grumbach, Emmanuel, linux-kernel@vger.kernel.org, ilw@linux.intel.com, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, John W. Linville Wednesday, December 18, 2013, 7:29:10 PM, you wrote: > On Mon, Dec 16, 2013 at 12:22:00PM +0100, Sander Eikelenboom wrote: >> >> Wednesday, December 11, 2013, 7:38:50 PM, you wrote: >> >> > On Wed, Dec 11, 2013 at 7:11 PM, Sander Eikelenboom >> > <linux@eikelenboom.it> wrote: >> >> >> >> Wednesday, December 11, 2013, 6:53:07 PM, you wrote: >> >> >> >>> The best way to address all this is by automatic region awareness and >> >>> doing the right thing on devices, this however requires good >> >>> architecture / calibration data / etc and all that needs to be >> >>> verified by the system integrators, and finally they need to be >> >>> certified. If you want to hack your firmware and software go at it, >> >>> just be aware there are reasons for things. >> >> >> >> Well the general problem seems to be "we don't trust the user" so we FORCE him to the lowest >> >> common denominator (without a way to overrule that) so he is forced to operate *well* within the law. >> >> > Its simply stupid to have the user be involved, period, the fact that >> > a user would be involved should only be for testing or helping >> > compliance for a busted device, development, research and obviously >> > hacking. Linux allows all these but by default a device with firmware >> > and a custom regdomain that will barf if you try to use a channel that >> > is not allowed is a restriction in firmware. Feel free to reverse >> > engineer that if you don't like it but it just won't be supported or >> > go upstream. Now, the common denominator is generally optimized for >> > best performance as well so you shouldn't have to do anything, and for >> > APs -- this is typically carefully crafted for a region, also highly >> > optimized. >> >> >>>>> It doesn't seem like you are getting your original requests getting >> >>>>> processed, so I don't think CRDA is passing it. Can you verify running >> >>>>> from CRDA code: >> >>>> >> >>>> They don't get processed unless i remove the return from the code as i indicated. >> >>>> If i remove that return it processes the request. >> >>>> >> >>>>> ./regdbdump /usr/lib/crda/regulatory.bin >> >>>> >> >>>> Although it's in a different location on Debian, /lib/crda/regulatory.bin >> >>>> the dump seems fine. >> >> >> >>> OK thanks. Can you send a patch of what exact change you made, it was >> >>> unclear from the paste you made. >> >> >> >>> diff -u file.c.orig file.c >> >> >> >> Well i just did a pull from wireless-next, to try Avinash Patil's patch. >> >> net/wireless/reg.c had already changed much so i couldn't apply his patch without. >> >> >> >> With his patch it sets the regulatory domain, although as now expected i still can not use channels 12 and 13 yet, >> >> probably due to those firmware restrictions. >> >> > Its unclear what results you got, and yeah if the device is restricted >> > then its just the fw telling the driver its channels and you can't use >> > them. That's it. You won't be able to override information then unless >> > you hack the firmware >> >> Ping ? >> >> Is there anymore information you need to *fix* the problem ? > I was away on Travel back home, and will soon be traveling to > visit family so e-mail replies will be delayed, I'll jump on this > thread now but in short: > You are confusing the main issue you reported (cannot override regulatory) > as a software issue rather than a firmware issue with intel firmware, you are > also making claims and making people believe things work in different ways > (I'll clarify things there, proper regulatory support without CRDA works, CRDA > is just a helper, we also do have a timeout on requests). Lastly there is one > issue that may be a software issue but I cannot reproduce which I am > interested in getting down to the bottom to. To hopefully save you some time ... I would suggest reading the thread from bottom to top ;-) A summary .. it's now limited to: Problem: Not being able to set the regulator domain with userspace tools after boot although CRDA works. Condition: This only occurs when i build the modules in, when i use loadable modules all is fine. What seems to happen: - This seems to be due to the fact that when the modules are built-in the modules are initialized *before* the root-filesystem is mounted. - Since the root-filesystem isn't mounted, the CRDA is also not accessible. - The world regulatory domain is now set and the boot continues, but somehow the request keeps pending doesn't seem to be cleared. - *All* subsequent requests to change the regulatory domain, also when the CRDA has become accessible, also keep pending because that first request (at boot) was never fullfilled (or cleared) And IMHO that's a bug. > I'll dive into the different things now. > Luis ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work. 2013-12-18 18:54 ` Sander Eikelenboom @ 2013-12-18 19:42 ` Luis R. Rodriguez 0 siblings, 0 replies; 38+ messages in thread From: Luis R. Rodriguez @ 2013-12-18 19:42 UTC (permalink / raw) To: Sander Eikelenboom Cc: Berg, Johannes, Grumbach, Emmanuel, linux-kernel@vger.kernel.org, ilw@linux.intel.com, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, John W. Linville On Wed, Dec 18, 2013 at 07:54:46PM +0100, Sander Eikelenboom wrote: > > Wednesday, December 18, 2013, 7:29:10 PM, you wrote: > > > On Mon, Dec 16, 2013 at 12:22:00PM +0100, Sander Eikelenboom wrote: > >> > >> Wednesday, December 11, 2013, 7:38:50 PM, you wrote: > >> > >> > On Wed, Dec 11, 2013 at 7:11 PM, Sander Eikelenboom > >> > <linux@eikelenboom.it> wrote: > >> >> > >> >> Wednesday, December 11, 2013, 6:53:07 PM, you wrote: > >> >> > >> >>> The best way to address all this is by automatic region awareness and > >> >>> doing the right thing on devices, this however requires good > >> >>> architecture / calibration data / etc and all that needs to be > >> >>> verified by the system integrators, and finally they need to be > >> >>> certified. If you want to hack your firmware and software go at it, > >> >>> just be aware there are reasons for things. > >> >> > >> >> Well the general problem seems to be "we don't trust the user" so we FORCE him to the lowest > >> >> common denominator (without a way to overrule that) so he is forced to operate *well* within the law. > >> > >> > Its simply stupid to have the user be involved, period, the fact that > >> > a user would be involved should only be for testing or helping > >> > compliance for a busted device, development, research and obviously > >> > hacking. Linux allows all these but by default a device with firmware > >> > and a custom regdomain that will barf if you try to use a channel that > >> > is not allowed is a restriction in firmware. Feel free to reverse > >> > engineer that if you don't like it but it just won't be supported or > >> > go upstream. Now, the common denominator is generally optimized for > >> > best performance as well so you shouldn't have to do anything, and for > >> > APs -- this is typically carefully crafted for a region, also highly > >> > optimized. > >> > >> >>>>> It doesn't seem like you are getting your original requests getting > >> >>>>> processed, so I don't think CRDA is passing it. Can you verify running > >> >>>>> from CRDA code: > >> >>>> > >> >>>> They don't get processed unless i remove the return from the code as i indicated. > >> >>>> If i remove that return it processes the request. > >> >>>> > >> >>>>> ./regdbdump /usr/lib/crda/regulatory.bin > >> >>>> > >> >>>> Although it's in a different location on Debian, /lib/crda/regulatory.bin > >> >>>> the dump seems fine. > >> >> > >> >>> OK thanks. Can you send a patch of what exact change you made, it was > >> >>> unclear from the paste you made. > >> >> > >> >>> diff -u file.c.orig file.c > >> >> > >> >> Well i just did a pull from wireless-next, to try Avinash Patil's patch. > >> >> net/wireless/reg.c had already changed much so i couldn't apply his patch without. > >> >> > >> >> With his patch it sets the regulatory domain, although as now expected i still can not use channels 12 and 13 yet, > >> >> probably due to those firmware restrictions. > >> > >> > Its unclear what results you got, and yeah if the device is restricted > >> > then its just the fw telling the driver its channels and you can't use > >> > them. That's it. You won't be able to override information then unless > >> > you hack the firmware > >> > >> Ping ? > >> > >> Is there anymore information you need to *fix* the problem ? > > > I was away on Travel back home, and will soon be traveling to > > visit family so e-mail replies will be delayed, I'll jump on this > > thread now but in short: > > > You are confusing the main issue you reported (cannot override regulatory) > > as a software issue rather than a firmware issue with intel firmware, you are > > also making claims and making people believe things work in different ways > > (I'll clarify things there, proper regulatory support without CRDA works, CRDA > > is just a helper, we also do have a timeout on requests). Lastly there is one > > issue that may be a software issue but I cannot reproduce which I am > > interested in getting down to the bottom to. > > To hopefully save you some time ... > > I would suggest reading the thread from bottom to top ;-) > > A summary .. it's now limited to: > > Problem: Not being able to set the regulator domain with userspace tools after boot although CRDA works. > Condition: This only occurs when i build the modules in, when i use loadable modules all is fine. > What seems to happen: > - This seems to be due to the fact that when the modules are built-in the modules are initialized *before* the root-filesystem is mounted. > - Since the root-filesystem isn't mounted, the CRDA is also not accessible. > - The world regulatory domain is now set and the boot continues, but somehow the request keeps pending doesn't seem to be cleared. > - *All* subsequent requests to change the regulatory domain, also when the CRDA has become accessible, also keep pending because that first request (at boot) was never fullfilled (or cleared) > > And IMHO that's a bug. Thanks for the summary ! Luis ^ permalink raw reply [flat|nested] 38+ messages in thread
[parent not found: <CAJwzM1nwFa7z5gwh42aj39M2dxVXnuecDrhQkVyL+DDFAXwwbg@mail.gmail.com>]
* Re: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work. [not found] ` <CAJwzM1nwFa7z5gwh42aj39M2dxVXnuecDrhQkVyL+DDFAXwwbg@mail.gmail.com> @ 2013-12-11 17:00 ` Sander Eikelenboom 2013-12-11 17:17 ` Luis R. Rodriguez 0 siblings, 1 reply; 38+ messages in thread From: Sander Eikelenboom @ 2013-12-11 17:00 UTC (permalink / raw) To: Avinash Patil Cc: Luis R. Rodriguez, John W. Linville, linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org, ilw@linux.intel.com, netdev@vger.kernel.org, Grumbach, Emmanuel, Berg, Johannes Wednesday, December 11, 2013, 5:34:27 PM, you wrote: > Hi Luis, > I have seen that hint during regulatory init still has request processed set to false. This results into further request set to pending. I have sent a patch for the same last week. Please have a look- I think issue faced by me is similar to what Sander is same. > Thanks, > Avinash. Hi Avinash, Could you send me the patch (or a link to it), i can't find it on the linux-wireless list. -- Sander > On Dec 11, 2013 9:14 PM, "Luis R. Rodriguez" <mcgrof@do-not-panic.com> wrote: > On Wed, Dec 11, 2013 at 4:17 PM, Sander Eikelenboom > <linux@eikelenboom.it> wrote: >> Since i haven't got a response to this yet and after having the troubled machine back: >> The problem is still present in linux 3.13-rc3 > > Keep in mind regulatory hints for Intel or Atheros cards do nothing > other than help compliance further given that the cards already have > their own regulatory data, the user input / hint is only going to > reduce the card's channels further. That said the fact that you are > not seeing a regulatory domain being set is an issue provided you have > CRDA installed or use CONFIG_CFG80211_INTERNAL_REGDB. Keep in mind > that the latest version of wireless-regdb had a signature issue > reported by users and not sure if that is cleared yet, so that would > also prevent the wireless-regdb being read even if CRDA was present. > To rule that out try putting the db.txt into net/wireless/db.txt and > compile with CONFIG_CFG80211_INTERNAL_REGDB for now. > > Then send the dmesg output, no need for all that fluffy intel debug > log as its not useful in this case. > > Luis > -- > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work. 2013-12-11 17:00 ` Sander Eikelenboom @ 2013-12-11 17:17 ` Luis R. Rodriguez 0 siblings, 0 replies; 38+ messages in thread From: Luis R. Rodriguez @ 2013-12-11 17:17 UTC (permalink / raw) To: Sander Eikelenboom Cc: Avinash Patil, John W. Linville, linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org, ilw@linux.intel.com, netdev@vger.kernel.org, Grumbach, Emmanuel, Berg, Johannes On Wed, Dec 11, 2013 at 6:00 PM, Sander Eikelenboom <linux@eikelenboom.it> wrote: > Could you send me the patch (or a link to it), i can't find it on the linux-wireless list. I looked for such a patch and didn't find it either, perhaps both of your issues are the same as with CRDA and the wireless-regdb not having a proper signature set. You can verify if this is the case by just downloading the git repo for wireless-regdb and CRDA and on both just do: make sudo make install After doing this on wireless-regdb just get the $USER.key.pub.pem and stash that into the crda/pubkeys/ before compiling. That will let CRDA trust your own key. Luis ^ permalink raw reply [flat|nested] 38+ messages in thread
end of thread, other threads:[~2013-12-19 4:57 UTC | newest]
Thread overview: 38+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1507831110.20131018194349@eikelenboom.it>
2013-10-23 12:28 ` [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work Sander Eikelenboom
2013-12-11 15:17 ` Sander Eikelenboom
2013-12-11 15:38 ` Luis R. Rodriguez
2013-12-11 16:53 ` Sander Eikelenboom
2013-12-11 17:14 ` Luis R. Rodriguez
2013-12-11 17:28 ` Sander Eikelenboom
2013-12-11 17:53 ` Luis R. Rodriguez
2013-12-11 18:02 ` Luis R. Rodriguez
2013-12-11 18:11 ` Sander Eikelenboom
2013-12-11 18:38 ` Luis R. Rodriguez
2013-12-11 19:06 ` Sander Eikelenboom
2013-12-18 18:54 ` Luis R. Rodriguez
2013-12-16 11:22 ` Sander Eikelenboom
2013-12-16 11:37 ` Arend van Spriel
2013-12-16 12:56 ` Sander Eikelenboom
2013-12-17 2:17 ` Julian Calaby
2013-12-17 9:45 ` Sander Eikelenboom
2013-12-17 20:33 ` Sander Eikelenboom
2013-12-17 21:27 ` Ben Hutchings
2013-12-17 21:49 ` Sander Eikelenboom
2013-12-17 22:06 ` Linus Torvalds
2013-12-18 9:16 ` Arend van Spriel
2013-12-18 9:18 ` Grumbach, Emmanuel
2013-12-18 9:25 ` Sander Eikelenboom
2013-12-18 9:26 ` Johannes Berg
2013-12-18 10:48 ` Sander Eikelenboom
2013-12-18 19:43 ` Luis R. Rodriguez
2013-12-18 19:45 ` Sander Eikelenboom
2013-12-19 4:57 ` Luis R. Rodriguez
2013-12-17 23:35 ` Julian Calaby
2013-12-18 7:50 ` Pontus Fuchs
2013-12-18 8:58 ` Arend van Spriel
2013-12-18 19:27 ` Luis R. Rodriguez
2013-12-18 18:29 ` Luis R. Rodriguez
2013-12-18 18:54 ` Sander Eikelenboom
2013-12-18 19:42 ` Luis R. Rodriguez
[not found] ` <CAJwzM1nwFa7z5gwh42aj39M2dxVXnuecDrhQkVyL+DDFAXwwbg@mail.gmail.com>
2013-12-11 17:00 ` Sander Eikelenboom
2013-12-11 17:17 ` Luis R. Rodriguez
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).