* [PATCH 3.10 0/3] Enable 7000 device family on 3.10
From: Emmanuel Grumbach @ 2013-07-15 11:19 UTC (permalink / raw)
To: linux-wireless; +Cc: Emmanuel Grumbach
This small patch series enables 7260 and 3160 devices on 3.10
kernel. Three patches are already in linux.git (3.11-rc1).
One patch is 3.10 specific and disables configuration that is not
supported in 3.10.
Emmanuel Grumbach (1):
iwlwifi: mvm: support BSS only
Johannes Berg (2):
iwlwifi: mvm: adjust firmware D3 configuration API
iwlwifi: bump required firmware API version for 3160/7260
drivers/net/wireless/iwlwifi/mvm/fw-api-d3.h | 4 +++-
drivers/net/wireless/iwlwifi/mvm/mac-ctxt.c | 4 ++--
drivers/net/wireless/iwlwifi/mvm/mac80211.c | 24 +-----------------------
drivers/net/wireless/iwlwifi/pcie/7000.c | 12 ++++++------
4 files changed, 12 insertions(+), 32 deletions(-)
--
1.7.10.4
^ permalink raw reply
* [PATCH 5/5] bcma: fix handling of big addrl
From: Hauke Mehrtens @ 2013-07-15 11:15 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, zajec5, Hauke Mehrtens
In-Reply-To: <1373886908-4460-1-git-send-email-hauke@hauke-m.de>
The return value of bcma_erom_get_addr_desc() is a unsigned value and it
could wrap around in the two complement writing. This happens for one
core in the BCM4708 SoC.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
drivers/bcma/scan.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/bcma/scan.c b/drivers/bcma/scan.c
index f2f1415..cd6b20f 100644
--- a/drivers/bcma/scan.c
+++ b/drivers/bcma/scan.c
@@ -213,7 +213,7 @@ static s32 bcma_erom_get_mst_port(struct bcma_bus *bus, u32 __iomem **eromptr)
return ent;
}
-static s32 bcma_erom_get_addr_desc(struct bcma_bus *bus, u32 __iomem **eromptr,
+static u32 bcma_erom_get_addr_desc(struct bcma_bus *bus, u32 __iomem **eromptr,
u32 type, u8 port)
{
u32 addrl, addrh, sizel, sizeh = 0;
@@ -225,7 +225,7 @@ static s32 bcma_erom_get_addr_desc(struct bcma_bus *bus, u32 __iomem **eromptr,
((ent & SCAN_ADDR_TYPE) != type) ||
(((ent & SCAN_ADDR_PORT) >> SCAN_ADDR_PORT_SHIFT) != port)) {
bcma_erom_push_ent(eromptr);
- return -EINVAL;
+ return (u32)-EINVAL;
}
addrl = ent & SCAN_ADDR_ADDR;
@@ -273,7 +273,7 @@ static int bcma_get_next_core(struct bcma_bus *bus, u32 __iomem **eromptr,
struct bcma_device_id *match, int core_num,
struct bcma_device *core)
{
- s32 tmp;
+ u32 tmp;
u8 i, j;
s32 cia, cib;
u8 ports[2], wrappers[2];
@@ -351,11 +351,11 @@ static int bcma_get_next_core(struct bcma_bus *bus, u32 __iomem **eromptr,
* the main register space for the core
*/
tmp = bcma_erom_get_addr_desc(bus, eromptr, SCAN_ADDR_TYPE_SLAVE, 0);
- if (tmp <= 0) {
+ if (tmp == 0 || IS_ERR_VALUE(tmp)) {
/* Try again to see if it is a bridge */
tmp = bcma_erom_get_addr_desc(bus, eromptr,
SCAN_ADDR_TYPE_BRIDGE, 0);
- if (tmp <= 0) {
+ if (tmp == 0 || IS_ERR_VALUE(tmp)) {
return -EILSEQ;
} else {
bcma_info(bus, "Bridge found\n");
@@ -369,7 +369,7 @@ static int bcma_get_next_core(struct bcma_bus *bus, u32 __iomem **eromptr,
for (j = 0; ; j++) {
tmp = bcma_erom_get_addr_desc(bus, eromptr,
SCAN_ADDR_TYPE_SLAVE, i);
- if (tmp < 0) {
+ if (IS_ERR_VALUE(tmp)) {
/* no more entries for port _i_ */
/* pr_debug("erom: slave port %d "
* "has %d descriptors\n", i, j); */
@@ -386,7 +386,7 @@ static int bcma_get_next_core(struct bcma_bus *bus, u32 __iomem **eromptr,
for (j = 0; ; j++) {
tmp = bcma_erom_get_addr_desc(bus, eromptr,
SCAN_ADDR_TYPE_MWRAP, i);
- if (tmp < 0) {
+ if (IS_ERR_VALUE(tmp)) {
/* no more entries for port _i_ */
/* pr_debug("erom: master wrapper %d "
* "has %d descriptors\n", i, j); */
@@ -404,7 +404,7 @@ static int bcma_get_next_core(struct bcma_bus *bus, u32 __iomem **eromptr,
for (j = 0; ; j++) {
tmp = bcma_erom_get_addr_desc(bus, eromptr,
SCAN_ADDR_TYPE_SWRAP, i + hack);
- if (tmp < 0) {
+ if (IS_ERR_VALUE(tmp)) {
/* no more entries for port _i_ */
/* pr_debug("erom: master wrapper %d "
* has %d descriptors\n", i, j); */
--
1.7.10.4
^ permalink raw reply related
* [PATCH 4/5] bcma: return correct error code when bus scan failed
From: Hauke Mehrtens @ 2013-07-15 11:15 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, zajec5, Hauke Mehrtens
In-Reply-To: <1373886908-4460-1-git-send-email-hauke@hauke-m.de>
It is better to return the actual error code than just -1.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
drivers/bcma/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
index 0067422..90ee350 100644
--- a/drivers/bcma/main.c
+++ b/drivers/bcma/main.c
@@ -237,7 +237,7 @@ int bcma_bus_register(struct bcma_bus *bus)
err = bcma_bus_scan(bus);
if (err) {
bcma_err(bus, "Failed to scan: %d\n", err);
- return -1;
+ return err;
}
/* Early init CC core */
--
1.7.10.4
^ permalink raw reply related
* [PATCH 3/5] bcma: add constants for new ARM based SoCs
From: Hauke Mehrtens @ 2013-07-15 11:15 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, zajec5, Hauke Mehrtens
In-Reply-To: <1373886908-4460-1-git-send-email-hauke@hauke-m.de>
These are the chipIDs of some ARM based SoCs from the BCM47xx line.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
include/linux/bcma/bcma.h | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/include/linux/bcma/bcma.h b/include/linux/bcma/bcma.h
index 8fee028..4d043c3 100644
--- a/include/linux/bcma/bcma.h
+++ b/include/linux/bcma/bcma.h
@@ -189,6 +189,11 @@ struct bcma_host_ops {
#define BCMA_PKG_ID_BCM5357 11
#define BCMA_CHIP_ID_BCM53572 53572
#define BCMA_PKG_ID_BCM47188 9
+#define BCMA_CHIP_ID_BCM4707 53010
+#define BCMA_PKG_ID_BCM4707 1
+#define BCMA_PKG_ID_BCM4708 2
+#define BCMA_PKG_ID_BCM4709 0
+#define BCMA_CHIP_ID_BCM53018 53018
/* Board types (on PCI usually equals to the subsystem dev id) */
/* BCM4313 */
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/5] bcma: make it possible to select SoC support without mips
From: Hauke Mehrtens @ 2013-07-15 11:15 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, zajec5, Hauke Mehrtens
In-Reply-To: <1373886908-4460-1-git-send-email-hauke@hauke-m.de>
To make it possible to use the SoC host interface with ARM SoCs do not
depend on the MIPS driver any more.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
drivers/bcma/Kconfig | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/bcma/Kconfig b/drivers/bcma/Kconfig
index 380a200..7c081b3 100644
--- a/drivers/bcma/Kconfig
+++ b/drivers/bcma/Kconfig
@@ -35,8 +35,14 @@ config BCMA_DRIVER_PCI_HOSTMODE
PCI core hostmode operation (external PCI bus).
config BCMA_HOST_SOC
- bool
- depends on BCMA_DRIVER_MIPS
+ bool "Support for BCMA in a SoC"
+ depends on BCMA
+ help
+ Host interface for a Broadcom AIX bus directly mapped into
+ the memory. This only works with the Broadcom SoCs from the
+ BCM47XX line.
+
+ If unsure, say N
config BCMA_DRIVER_MIPS
bool "BCMA Broadcom MIPS core driver"
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/5] bcma: add some more core names
From: Hauke Mehrtens @ 2013-07-15 11:15 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, zajec5, Hauke Mehrtens
In-Reply-To: <1373886908-4460-1-git-send-email-hauke@hauke-m.de>
These cores were found on a BCM4708 (chipid 53010), this is a ARM SoC
with two Cortex A9 cores.
bcma: bus0: Found chip with id 0xCF12, rev 0x00 and package 0x02
bcma: bus0: Core 0 found: ChipCommon (manuf 0x4BF, id 0x800, rev 0x2A, class 0x0)
bcma: bus0: Core 1 found: DMA (manuf 0x4BF, id 0x502, rev 0x01, class 0x0)
bcma: bus0: Core 2 found: GBit MAC (manuf 0x4BF, id 0x82D, rev 0x04, class 0x0)
bcma: bus0: Core 3 found: GBit MAC (manuf 0x4BF, id 0x82D, rev 0x04, class 0x0)
bcma: bus0: Core 4 found: GBit MAC (manuf 0x4BF, id 0x82D, rev 0x04, class 0x0)
bcma: bus0: Core 5 found: GBit MAC (manuf 0x4BF, id 0x82D, rev 0x04, class 0x0)
bcma: bus0: Core 6 found: PCIe Gen 2 (manuf 0x4BF, id 0x501, rev 0x01, class 0x0)
bcma: bus0: Core 7 found: PCIe Gen 2 (manuf 0x4BF, id 0x501, rev 0x01, class 0x0)
bcma: bus0: Core 8 found: ARM Cortex A9 core (ihost) (manuf 0x4BF, id 0x510, rev 0x01, class 0x0)
bcma: bus0: Core 9 found: USB 2.0 (manuf 0x4BF, id 0x504, rev 0x01, class 0x0)
bcma: bus0: Core 10 found: USB 3.0 (manuf 0x4BF, id 0x505, rev 0x01, class 0x0)
bcma: bus0: Core 11 found: SDIO3 (manuf 0x4BF, id 0x503, rev 0x01, class 0x0)
bcma: bus0: Core 12 found: ARM Cortex A9 JTAG (manuf 0x4BF, id 0x506, rev 0x01, class 0x0)
bcma: bus0: Core 13 found: Denali DDR2/DDR3 memory controller (manuf 0x4BF, id 0x507, rev 0x01, class 0x0)
bcma: bus0: Core 14 found: ROM (manuf 0x4BF, id 0x508, rev 0x01, class 0x0)
bcma: bus0: Core 15 found: NAND flash controller (manuf 0x4BF, id 0x509, rev 0x01, class 0x0)
bcma: bus0: Core 16 found: SPI flash controller (manuf 0x4BF, id 0x50A, rev 0x01, class 0x0)
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
drivers/bcma/scan.c | 12 ++++++++++++
include/linux/bcma/bcma.h | 12 ++++++++++++
2 files changed, 24 insertions(+)
diff --git a/drivers/bcma/scan.c b/drivers/bcma/scan.c
index 8bffa5c..f2f1415 100644
--- a/drivers/bcma/scan.c
+++ b/drivers/bcma/scan.c
@@ -32,6 +32,18 @@ static const struct bcma_device_id_name bcma_bcm_device_names[] = {
{ BCMA_CORE_4706_CHIPCOMMON, "BCM4706 ChipCommon" },
{ BCMA_CORE_4706_SOC_RAM, "BCM4706 SOC RAM" },
{ BCMA_CORE_4706_MAC_GBIT, "BCM4706 GBit MAC" },
+ { BCMA_CORE_PCIEG2, "PCIe Gen 2" },
+ { BCMA_CORE_DMA, "DMA" },
+ { BCMA_CORE_SDIO3, "SDIO3" },
+ { BCMA_CORE_USB20, "USB 2.0" },
+ { BCMA_CORE_USB30, "USB 3.0" },
+ { BCMA_CORE_A9JTAG, "ARM Cortex A9 JTAG" },
+ { BCMA_CORE_DDR23, "Denali DDR2/DDR3 memory controller" },
+ { BCMA_CORE_ROM, "ROM" },
+ { BCMA_CORE_NAND, "NAND flash controller" },
+ { BCMA_CORE_QSPI, "SPI flash controller" },
+ { BCMA_CORE_CHIPCOMMON_B, "Chipcommon B" },
+ { BCMA_CORE_ARMCA9, "ARM Cortex A9 core (ihost)" },
{ BCMA_CORE_AMEMC, "AMEMC (DDR)" },
{ BCMA_CORE_ALTA, "ALTA (I2S)" },
{ BCMA_CORE_INVALID, "Invalid" },
diff --git a/include/linux/bcma/bcma.h b/include/linux/bcma/bcma.h
index 622fc50..8fee028 100644
--- a/include/linux/bcma/bcma.h
+++ b/include/linux/bcma/bcma.h
@@ -72,7 +72,19 @@ struct bcma_host_ops {
/* Core-ID values. */
#define BCMA_CORE_OOB_ROUTER 0x367 /* Out of band */
#define BCMA_CORE_4706_CHIPCOMMON 0x500
+#define BCMA_CORE_PCIEG2 0x501
+#define BCMA_CORE_DMA 0x502
+#define BCMA_CORE_SDIO3 0x503
+#define BCMA_CORE_USB20 0x504
+#define BCMA_CORE_USB30 0x505
+#define BCMA_CORE_A9JTAG 0x506
+#define BCMA_CORE_DDR23 0x507
+#define BCMA_CORE_ROM 0x508
+#define BCMA_CORE_NAND 0x509
+#define BCMA_CORE_QSPI 0x50A
+#define BCMA_CORE_CHIPCOMMON_B 0x50B
#define BCMA_CORE_4706_SOC_RAM 0x50E
+#define BCMA_CORE_ARMCA9 0x510
#define BCMA_CORE_4706_MAC_GBIT 0x52D
#define BCMA_CORE_AMEMC 0x52E /* DDR1/2 memory controller core */
#define BCMA_CORE_ALTA 0x534 /* I2S core */
--
1.7.10.4
^ permalink raw reply related
* [PATCH 0/5] bcma: first patches to add support for BCM4708
From: Hauke Mehrtens @ 2013-07-15 11:15 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, zajec5, Hauke Mehrtens
These patches are just fixing minor problems seen while adding support
for BCM4708 SoC and they add some constants for this SoC.
Hauke Mehrtens (5):
bcma: add some more core names
bcma: make it possible to select SoC support without mips
bcma: add constants for new ARM based SoCs
bcma: return correct error code when bus scan failed
bcma: fix handling of big addrl
drivers/bcma/Kconfig | 10 ++++++++--
drivers/bcma/main.c | 2 +-
drivers/bcma/scan.c | 28 ++++++++++++++++++++--------
include/linux/bcma/bcma.h | 17 +++++++++++++++++
4 files changed, 46 insertions(+), 11 deletions(-)
--
1.7.10.4
^ permalink raw reply
* RE: [PATCH 3.9 0/4] Enable 7000 device family on 3.9
From: Grumbach, Emmanuel @ 2013-07-15 9:56 UTC (permalink / raw)
To: stable@vger.kernel.org; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1373881749-2923-1-git-send-email-emmanuel.grumbach@intel.com>
> From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
>
> This small patch series enables 7260 and 3160 devices on 3.9 kernel. Three
> patches are already in linux.git (3.11-rc1).
> One patch is 3.9 specific and disables configuration that is not supported in
> 3.9.
>
Will resend without the Change-ID
^ permalink raw reply
* Re: kernel panic on 3.10.0-rc7
From: Felix Fietkau @ 2013-07-15 9:48 UTC (permalink / raw)
To: Krzysztof Mazur; +Cc: Sedat Dilek, peizhao.research, linux-wireless
In-Reply-To: <20130715093544.GA15055@shrek.podlesie.net>
On 2013-07-15 11:35 AM, Krzysztof Mazur wrote:
> On Mon, Jul 15, 2013 at 11:27:30AM +0200, Krzysztof Mazur wrote:
>> On Mon, Jul 15, 2013 at 11:06:27AM +0200, Felix Fietkau wrote:
>> > Please post the actual message output. Saying "it looks like something
>> > wrong with the rate control mechanism" doesn't give me anything useful
>> > to work with.
>> >
>>
>> Sorry, I added you to Cc after I removed the original Oops.
>>
>
> On my system the NULL pointer dereference occurs at 0x806389b0,
> and the minstrel_get_rate() looks like:
>
> 80638990 <minstrel_get_rate>:
> 80638990: 83 ec 1c sub $0x1c,%esp
> 80638993: 89 7c 24 14 mov %edi,0x14(%esp)
> 80638997: 8b 7c 24 20 mov 0x20(%esp),%edi
> 8063899b: 89 5c 24 0c mov %ebx,0xc(%esp)
> 8063899f: 89 cb mov %ecx,%ebx
> 806389a1: 89 6c 24 18 mov %ebp,0x18(%esp)
> 806389a5: 89 c5 mov %eax,%ebp
> 806389a7: 89 d0 mov %edx,%eax
> 806389a9: 89 74 24 10 mov %esi,0x10(%esp)
> 806389ad: 8b 77 0c mov 0xc(%edi),%esi
> * 806389b0: 0f b6 49 38 movzbl 0x38(%ecx),%ecx *
> 806389b4: 8d 56 20 lea 0x20(%esi),%edx
> 806389b7: 89 54 24 04 mov %edx,0x4(%esp)
> 806389bb: 89 da mov %ebx,%edx
> 806389bd: 88 4c 24 0b mov %cl,0xb(%esp)
> 806389c1: 89 f9 mov %edi,%ecx
> 806389c3: e8 38 2f fe ff call 8061b900 <rate_control_send_low>
My x86 assembly is a a bit rusty (I usually work with ARM and MIPS), so
I'm having trouble figuring out the exact line of code here. Please use
gdb to track it down.
- Felix
^ permalink raw reply
* Re: kernel panic on 3.10.0-rc7
From: Krzysztof Mazur @ 2013-07-15 9:35 UTC (permalink / raw)
To: Felix Fietkau; +Cc: Sedat Dilek, peizhao.research, linux-wireless
In-Reply-To: <20130715092730.GA12765@shrek.podlesie.net>
On Mon, Jul 15, 2013 at 11:27:30AM +0200, Krzysztof Mazur wrote:
> On Mon, Jul 15, 2013 at 11:06:27AM +0200, Felix Fietkau wrote:
> > Please post the actual message output. Saying "it looks like something
> > wrong with the rate control mechanism" doesn't give me anything useful
> > to work with.
> >
>
> Sorry, I added you to Cc after I removed the original Oops.
>
On my system the NULL pointer dereference occurs at 0x806389b0,
and the minstrel_get_rate() looks like:
80638990 <minstrel_get_rate>:
80638990: 83 ec 1c sub $0x1c,%esp
80638993: 89 7c 24 14 mov %edi,0x14(%esp)
80638997: 8b 7c 24 20 mov 0x20(%esp),%edi
8063899b: 89 5c 24 0c mov %ebx,0xc(%esp)
8063899f: 89 cb mov %ecx,%ebx
806389a1: 89 6c 24 18 mov %ebp,0x18(%esp)
806389a5: 89 c5 mov %eax,%ebp
806389a7: 89 d0 mov %edx,%eax
806389a9: 89 74 24 10 mov %esi,0x10(%esp)
806389ad: 8b 77 0c mov 0xc(%edi),%esi
* 806389b0: 0f b6 49 38 movzbl 0x38(%ecx),%ecx *
806389b4: 8d 56 20 lea 0x20(%esi),%edx
806389b7: 89 54 24 04 mov %edx,0x4(%esp)
806389bb: 89 da mov %ebx,%edx
806389bd: 88 4c 24 0b mov %cl,0xb(%esp)
806389c1: 89 f9 mov %edi,%ecx
806389c3: e8 38 2f fe ff call 8061b900 <rate_control_send_low>
Krzysiek
^ permalink raw reply
* Re: kernel panic on 3.10.0-rc7
From: Krzysztof Mazur @ 2013-07-15 9:27 UTC (permalink / raw)
To: Felix Fietkau; +Cc: Sedat Dilek, peizhao.research, linux-wireless
In-Reply-To: <51E3BB93.2090000@openwrt.org>
On Mon, Jul 15, 2013 at 11:06:27AM +0200, Felix Fietkau wrote:
> Please post the actual message output. Saying "it looks like something
> wrong with the rate control mechanism" doesn't give me anything useful
> to work with.
>
Sorry, I added you to Cc after I removed the original Oops.
On Mon, Jul 1, 2013 at 8:55 AM, Peizhao Hu wrote:
> Hi,
>
> Is there anyone has the same problem with me? I have a cm9 radio card with
> the node.
>
> The kernel compiled and booted alright, but crashed short after I set it up
> in the ad hoc mode. From the debug message output, it looks like something
> wrong with the rate control mechanism when it is trying to the rate
> (minstreal_get_rate function in this case).
>
> Is this a bug?
>
> Kernel version
> 3.10.0-rc7
>
> root@alix-router:~# i[ 250.809354] BUG: unable to handle kernel NULL
> pointe8
> [ 250.812875] IP: [<d0952afa>] minstrel_get_rate+0x1a/0x220 [mac80211]
> [ 250.812875] *pde = 00000000
> [ 250.812875] Oops: 0000 [#1] SMP
> [ 250.812875] Modules linked in: ath5k ath mac80211 cfg80211 arc4
> gpio_cs55]
> [ 250.812875] CPU: 0 PID: 6 Comm: kworker/u2:0 Not tainted 3.10.0-rc7-cca+
> 1
> [ 250.812875] Workqueue: phy0 ieee80211_iface_work [mac80211]
> [ 250.812875] task: c002bfc0 ti: c0076000 task.ti: c0076000
> [ 250.812875] EIP: 0060:[<d0952afa>] EFLAGS: 00010292 CPU: 0
> [ 250.812875] EIP is at minstrel_get_rate+0x1a/0x220 [mac80211]
> [ 250.812875] EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: cc2bf1c0
> [ 250.812875] ESI: ce6cf900 EDI: c0077d00 EBP: c0077cac ESP: c0077c94
> [ 250.812875] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> [ 250.812875] CR0: 8005003b CR2: 00000038 CR3: 0c245000 CR4: 00000090
> [ 250.812875] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
> [ 250.812875] DR6: ffff0ff0 DR7: 00000400
> [ 250.812875] Stack:
> [ 250.812875] 00017901 cc101500 00000180 cc133500 d0967920 cc2bf1e1
> c0077cd
> [ 250.812875] c0077d00 00000180 ce525170 00000000 cc2bf1e0 c0077d00
> cc2bf10
> [ 250.812875] c0077d24 c0077d30 d0927651 c02c5550 c0077cec d092001c
> cc1335c
> [ 250.812875] Call Trace:
> [ 250.812875] [<d091a8dd>] rate_control_get_rate+0x9d/0xe0 [mac80211]
> [ 250.812875] [<d0927651>] ieee80211_beacon_get_tim+0x1a1/0x330 [mac80211]
> [ 250.812875] [<d092001c>] ? ieee80211_assign_beacon+0x1bc/0x1c0
> [mac80211]
> [ 250.812875] [<d0da3fb9>] ath5k_beacon_update+0x29/0x340 [ath5k]
> [ 250.812875] [<d0d99366>] ? ath5k_hw_get_frame_duration+0xa6/0xc0 [ath5k]
> [ 250.812875] [<d0d99140>] ? ath5k_hw_set_ifs_intervals+0x110/0x1b0
> [ath5k]
> [ 250.812875] [<d0da92d3>] ath5k_bss_info_changed+0x113/0x1f0 [ath5k]
> [ 250.812875] [<d0da91c0>] ? ath5k_configure_filter+0x1c0/0x1c0 [ath5k]
> [ 250.812875] [<d0908903>] ieee80211_bss_info_change_notify+0xc3/0x1c0
> [ma]
> [ 250.812875] [<d09141db>] ? __ieee80211_sta_join_ibss+0x19b/0x660
> [mac802]
> [ 250.812875] [<d091442c>] __ieee80211_sta_join_ibss+0x3ec/0x660
> [mac80211]
> [ 250.812875] [<c157be33>] ? printk+0x4d/0x4f
> [ 250.812875] [<d0915b4d>] ieee80211_ibss_work+0x31d/0x3d0 [mac80211]
> [ 250.812875] [<d0916d2d>] ieee80211_iface_work+0x18d/0x310 [mac80211]
> [ 250.812875] [<c105025f>] process_one_work+0x10f/0x380
> [ 250.812875] [<c104e485>] ? start_worker+0x25/0x30
> [ 250.812875] [<c1051000>] ? manage_workers.isra.24+0x180/0x290
> [ 250.812875] [<c105120a>] worker_thread+0xfa/0x310
> [ 250.812875] [<c1051110>] ? manage_workers.isra.24+0x290/0x290
> [ 250.812875] [<c1056674>] kthread+0x94/0xa0
> [ 250.812875] [<c158b1f7>] ret_from_kernel_thread+0x1b/0x28
> [ 250.812875] [<c10565e0>] ? flush_kthread_worker+0x90/0x90
> [ 250.812875] Code: 3d fe 93 f0 5d c3 90 90 90 90 90 90 90 90 90 90 90 55
> 88
> [ 250.812875] EIP: [<d0952afa>] minstrel_get_rate+0x1a/0x220 [mac80211]
> SS:4
> [ 250.812875] CR2: 0000000000000038
> [ 250.815950] ---[ end trace 87b8337e77cb6664 ]---
> [ 250.817834] Kernel panic - not syncing: Fatal exception in interrupt
>
>
>
> --
> Regards;
>
> Peizhao
Krzysiek
^ permalink raw reply
* Re: [PATCH] ath10k: pass also QOS Null frames through mgmt tx path
From: Janusz Dziedzic @ 2013-07-15 9:06 UTC (permalink / raw)
To: Kalle Valo; +Cc: ath10k, linux-wireless
In-Reply-To: <87mwpop93v.fsf@kamboji.qca.qualcomm.com>
On 15 July 2013 09:37, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> Janusz Dziedzic <janusz.dziedzic@tieto.com> writes:
>
>> Fw will report wrong tx status for QOS Null frames
>> sent through data tx path.
>>
>> This patch fixes station(s) keep alive detection
>> triggered from wpa_supplicant/hostapd when work
>> as AP/GO and WMM enabled.
>>
>> Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
>
> I think you mentioned privately that this patch should be dropped. Is
> that still the case?
>
Yes, please drop this patch
BR
Janusz
^ permalink raw reply
* Re: kernel panic on 3.10.0-rc7
From: Felix Fietkau @ 2013-07-15 9:06 UTC (permalink / raw)
To: Krzysztof Mazur; +Cc: Sedat Dilek, peizhao.research, linux-wireless
In-Reply-To: <20130715085239.GA31630@shrek.podlesie.net>
On 2013-07-15 10:52 AM, Krzysztof Mazur wrote:
> On Mon, Jul 01, 2013 at 09:37:19AM +0200, Sedat Dilek wrote:
>> On Mon, Jul 1, 2013 at 8:55 AM, Peizhao Hu <peizhao.research@gmail.com> wrote:
>> > Hi,
>> >
>> > Is there anyone has the same problem with me? I have a cm9 radio card with
>> > the node.
>> >
>> > The kernel compiled and booted alright, but crashed short after I set it up
>> > in the ad hoc mode. From the debug message output, it looks like something
>> > wrong with the rate control mechanism when it is trying to the rate
>> > (minstreal_get_rate function in this case).
>> >
>> > Is this a bug?
>> >
>> > Kernel version
>> > 3.10.0-rc7
>> >
>>
>> Please, always add your kernel-config and some outputs like dmesg and
>> lspci/lsusb for better understanding.
>> 2nd, try v3.10 (released a few hours ago)... There were wireless
>> patches pushed after v3.10-rc7.
>> Then report again.
>>
>
> I have the same problem. I'm using:
>
> 02:04.0 Network controller: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02)
> Subsystem: Hewlett-Packard Company Broadcom 802.11b/g WLAN
> Flags: bus master, fast devsel, latency 64, IRQ 21
> Memory at d0000000 (32-bit, non-prefetchable) [size=8K]
> Kernel driver in use: b43-pci-bridge
>
> with b43 driver and I can easily trigger similar Oops with:
> # ip link set wlan0 up
> # iwlist scan
>
> The bug is introduced by commit 06d961a8e210035bff7e82f466107f9ab4a8fd94
> ("mac80211/minstrel: use the new rate control API").
> The v3.9 is ok and the v3.11-rc1 is still bad. I haven't checked
> wireless tree yet.
>
> Wireless related part of my .config:
> [...]
> CONFIG_WIRELESS=y
> CONFIG_WEXT_CORE=y
> CONFIG_WEXT_PROC=y
> CONFIG_CFG80211=y
> CONFIG_CFG80211_DEFAULT_PS=y
> CONFIG_CFG80211_WEXT=y
> CONFIG_MAC80211=y
> CONFIG_MAC80211_HAS_RC=y
> CONFIG_MAC80211_RC_MINSTREL=y
> CONFIG_MAC80211_RC_DEFAULT_MINSTREL=y
> CONFIG_MAC80211_RC_DEFAULT="minstrel"
> CONFIG_RFKILL=y
> CONFIG_RFKILL_INPUT=y
> [...]
> CONFIG_WLAN=y
> CONFIG_B43=y
> CONFIG_B43_SSB=y
> CONFIG_B43_PCI_AUTOSELECT=y
> CONFIG_B43_PCICORE_AUTOSELECT=y
> CONFIG_B43_PIO=y
> CONFIG_B43_PHY_LP=y
>
> Krzysiek
Please post the actual message output. Saying "it looks like something
wrong with the rate control mechanism" doesn't give me anything useful
to work with.
- Felix
^ permalink raw reply
* Re: kernel panic on 3.10.0-rc7
From: Krzysztof Mazur @ 2013-07-15 8:52 UTC (permalink / raw)
To: Sedat Dilek; +Cc: peizhao.research, linux-wireless, nbd
In-Reply-To: <CA+icZUUQHySKu=qEW3xfheg3DSMuvgB7Dp5PzVGOaiziAPTa5g@mail.gmail.com>
On Mon, Jul 01, 2013 at 09:37:19AM +0200, Sedat Dilek wrote:
> On Mon, Jul 1, 2013 at 8:55 AM, Peizhao Hu <peizhao.research@gmail.com> wrote:
> > Hi,
> >
> > Is there anyone has the same problem with me? I have a cm9 radio card with
> > the node.
> >
> > The kernel compiled and booted alright, but crashed short after I set it up
> > in the ad hoc mode. From the debug message output, it looks like something
> > wrong with the rate control mechanism when it is trying to the rate
> > (minstreal_get_rate function in this case).
> >
> > Is this a bug?
> >
> > Kernel version
> > 3.10.0-rc7
> >
>
> Please, always add your kernel-config and some outputs like dmesg and
> lspci/lsusb for better understanding.
> 2nd, try v3.10 (released a few hours ago)... There were wireless
> patches pushed after v3.10-rc7.
> Then report again.
>
I have the same problem. I'm using:
02:04.0 Network controller: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02)
Subsystem: Hewlett-Packard Company Broadcom 802.11b/g WLAN
Flags: bus master, fast devsel, latency 64, IRQ 21
Memory at d0000000 (32-bit, non-prefetchable) [size=8K]
Kernel driver in use: b43-pci-bridge
with b43 driver and I can easily trigger similar Oops with:
# ip link set wlan0 up
# iwlist scan
The bug is introduced by commit 06d961a8e210035bff7e82f466107f9ab4a8fd94
("mac80211/minstrel: use the new rate control API").
The v3.9 is ok and the v3.11-rc1 is still bad. I haven't checked
wireless tree yet.
Wireless related part of my .config:
[...]
CONFIG_WIRELESS=y
CONFIG_WEXT_CORE=y
CONFIG_WEXT_PROC=y
CONFIG_CFG80211=y
CONFIG_CFG80211_DEFAULT_PS=y
CONFIG_CFG80211_WEXT=y
CONFIG_MAC80211=y
CONFIG_MAC80211_HAS_RC=y
CONFIG_MAC80211_RC_MINSTREL=y
CONFIG_MAC80211_RC_DEFAULT_MINSTREL=y
CONFIG_MAC80211_RC_DEFAULT="minstrel"
CONFIG_RFKILL=y
CONFIG_RFKILL_INPUT=y
[...]
CONFIG_WLAN=y
CONFIG_B43=y
CONFIG_B43_SSB=y
CONFIG_B43_PCI_AUTOSELECT=y
CONFIG_B43_PCICORE_AUTOSELECT=y
CONFIG_B43_PIO=y
CONFIG_B43_PHY_LP=y
Krzysiek
^ permalink raw reply
* RE: Firmware error for Centrino N 2230
From: Cedric GROSS @ 2013-07-15 8:21 UTC (permalink / raw)
To: 'Johannes Berg'; +Cc: 'linux-wireless', 'Adrian Chadd'
In-Reply-To: <b04d657de9d7831febeff7b4ac8f371a@sipsolutions.net>
Hello Johannes,
> De : Johannes Berg [mailto:johannes@sipsolutions.net]
> Envoyé : dimanche 14 juillet 2013 12:52
> À : Cedric GROSS; Adrian Chadd
>
> > Many many many thanks. I will check that tomorrow.
> >
> > FreeBSD driver for intel wireless card is a bit old and need a lot of
> > improvement to manage new NIC.
> > Is there a way to get all assert code meaning ? It could be really a
> > big big help for me.
>
> Unfortunately not, but have you seen the "iwl" FreeBSD driver that we
> posted a while ago? That should help you some. Are you in contact with
> anyone else maybe?
I get this version of iwl : https://github.com/seanbruno/freebsd-iwl
But this one also doesn't work with my card. I also trying to modify for my NIC. For the moment I had a failure at the first RXON command.
I'm in contact only with Hiren Panchasara (hiren@freebsd.org).
I wrote to ilw at linux.intel.com also but no answer for the moment.
>
> johannes
^ permalink raw reply
* Re: [PATCH 00/16] ath10k: pending patches
From: Kalle Valo @ 2013-07-15 8:02 UTC (permalink / raw)
To: linux-wireless; +Cc: ath10k
In-Reply-To: <1373030117-18077-1-git-send-email-kvalo@qca.qualcomm.com>
Kalle Valo <kvalo@qca.qualcomm.com> writes:
> here are pending patches which were commited to ath10k.git while
> ath10k was under review. They were only sent to ath9k-devel, I'm
> resending them now before I reapply them to my new ath.git tree.
>
> Michal Kazior (16):
> ath10k: fix teardown ordering
> ath10k: fix possible deadlock
> ath10k: setup rts/frag thresholds upon vdev creation
> ath10k: do not setup rts/frag thresholds for suspended interfaces
> ath10k: remove ath10k_bus
> ath10k: fix typo in define name
> ath10k: silent warning in IBSS mode
> ath10k: lower print level for a message
> ath10k: provide errno if bmi read/write fails
> ath10k: change function to take struct ath10k as arg
> ath10k: rename hif callback
> ath10k: embed HTC struct inside ath10k
> ath10k: embed HTT struct inside ath10k
> ath10k: improve locking
> ath10k: abort scan properly if wmi_scan_stop fails
> ath10k: add missing debug prints
All 16 applied.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] ath10k: pass also QOS Null frames through mgmt tx path
From: Kalle Valo @ 2013-07-15 7:37 UTC (permalink / raw)
To: Janusz Dziedzic; +Cc: ath10k, linux-wireless
In-Reply-To: <1373624746-3244-1-git-send-email-janusz.dziedzic@tieto.com>
Janusz Dziedzic <janusz.dziedzic@tieto.com> writes:
> Fw will report wrong tx status for QOS Null frames
> sent through data tx path.
>
> This patch fixes station(s) keep alive detection
> triggered from wpa_supplicant/hostapd when work
> as AP/GO and WMM enabled.
>
> Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
I think you mentioned privately that this patch should be dropped. Is
that still the case?
--
Kalle Valo
^ permalink raw reply
* Re: [ath9k-devel] [PATCH] ath10k: Fix crash when using v1 hardware.
From: Michal Kazior @ 2013-07-15 6:55 UTC (permalink / raw)
To: Kalle Valo; +Cc: Ben Greear, ath10k, linux-wireless
In-Reply-To: <87y59d5tgu.fsf@kamboji.qca.qualcomm.com>
Hi,
On 11 July 2013 11:36, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> greearb@candelatech.com writes:
>
>> From: Ben Greear <greearb@candelatech.com>
>>
>> I put a v1 NIC from an TP-LINK AC 1750 AP in
>> a 64-bit PC, and the OS crashes on bootup. I'm not
>> sure how broken my hardware is (possibly completely non
>> functional), but at least with this patch it will no longer
>> crash the OS. Not sure it ever got far enough to try,
>> but I also do not have firmware for the NIC.
>>
>> With this patch I get this info on module load:
>>
>> ath10k_pci 0000:05:00.0: BAR 0: assigned [mem 0xf4400000-0xf45fffff 64bit]
>> ath10k_pci 0000:05:00.0: BAR 0: error updating (0xf4400004 != 0xffffffff)
>> ath10k_pci 0000:05:00.0: BAR 0: error updating (high 0x000000 != 0xffffffff)
>> ath10k_pci 0000:05:00.0: Refused to change power state, currently in D3
>> ath10k: MSI-X interrupt handling (8 intrs)
>> ath10k: Unable to wakeup target
>> ath10k: target takes too long to wake up (awake count 1)
>> ath10k: src_ring ffff88020c0d0a00: write_index is out of bounds: 4294967295 nentries_mask: 15.
>> ath10k: dest_ring ffff88020db2c000: write_index is out of bounds: 4294967295 nentries_mask: 511.
>> ath10k: dest_ring ffff880210d56400: write_index is out of bounds: 4294967295 nentries_mask: 31.
>> ath10k: src_ring ffff880210d57600: write_index is out of bounds: 4294967295 nentries_mask: 31.
>> ath10k: src_ring ffff88020fe70000: write_index is out of bounds: 4294967295 nentries_mask: 2047.
>> ath10k: src_ring ffff880212989b40: write_index is out of bounds: 4294967295 nentries_mask: 1.
>> ath10k: dest_ring ffff880212989960: write_index is out of bounds: 4294967295 nentries_mask: 1.
>> ath10k: Failed to get pcie state addr: -5
>> ath10k: early firmware event indicated
>> ------------[ cut here ]------------
>> WARNING: at /home/greearb/git/linux.wireless-testing/drivers/net/wireless/ath/ath10k/ce.c:771 ath10k_ce_per_engine_service+0x53/0x1b4 [ath10k_pci]()
>> ....
>> (it hits the warning case about 5-6 times and then seems to quiesce OK).
>
> I haven't seen this myself so it might be a hw problem, but difficult to
> say.
>
>> + /* On v1 hardware at least, setup can fail, causing ce_id_state to
>> + * be cleaned up, but this method is still called a few times. Check
>> + * for NULL here so we don't crash. Probably a better fix is to stop
>> + * the ath10k_pci_ce_tasklet sooner.
>> + */
>> + if (WARN_ONCE(!ce_state, "ce_id_to_state[%i] is NULL\n", ce_id))
>> + return;
>> +
>> + ctrl_addr = ce_state->ctrl_addr;
>> +
>
> The tests you add look like workarounds. I would prefer to try fix these
> by going to the source of the problem. Maybe we should add
> ath10k_pci_wake() and ath10k_do_pci_wake()?
The teardown sequence is broken. Interrupts aren't
disabled/unregistered soon enough. I have a pending patch that should
fix this (although it's still more of a workaround than a real fix
since we need proper variable init code/ hw init code separation to be
done). However the patch depends on my recovery patchset so I haven't
posted it yet.
Pozdrawiam / Best regards,
Michał Kazior.
^ permalink raw reply
* [PATCH] ath9k_hw: Fix multicast search for AR9002 family
From: Sujith Manoharan @ 2013-07-15 5:33 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
The multicast search bit is disabled for the AR9003
family, but this is required for AR9002 too. Fix this in
the INI override routine.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath9k/ar5008_phy.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar5008_phy.c b/drivers/net/wireless/ath/ath9k/ar5008_phy.c
index d1acfe9..1576d58 100644
--- a/drivers/net/wireless/ath/ath9k/ar5008_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar5008_phy.c
@@ -610,7 +610,15 @@ static void ar5008_hw_override_ini(struct ath_hw *ah,
REG_SET_BIT(ah, AR_DIAG_SW, (AR_DIAG_RX_DIS | AR_DIAG_RX_ABORT));
if (AR_SREV_9280_20_OR_LATER(ah)) {
- val = REG_READ(ah, AR_PCU_MISC_MODE2);
+ /*
+ * For AR9280 and above, there is a new feature that allows
+ * Multicast search based on both MAC Address and Key ID.
+ * By default, this feature is enabled. But since the driver
+ * is not using this feature, we switch it off; otherwise
+ * multicast search based on MAC addr only will fail.
+ */
+ val = REG_READ(ah, AR_PCU_MISC_MODE2) &
+ (~AR_ADHOC_MCAST_KEYID_ENABLE);
if (!AR_SREV_9271(ah))
val &= ~AR_PCU_MISC_MODE2_HWWAR1;
--
1.8.3.2
^ permalink raw reply related
* RE: [3.10.1 MEI_ME] strange kernel crash
From: Winkler, Tomas @ 2013-07-15 4:55 UTC (permalink / raw)
To: Konstantin Khlebnikov, linux-kernel@vger.kernel.org,
linux-wireless@vger.kernel.org
In-Reply-To: <51E360C1.10204@openvz.org>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogS29uc3RhbnRpbiBLaGxl
Ym5pa292IFttYWlsdG86a29jdDlpQGdtYWlsLmNvbV0gT24gQmVoYWxmIE9mDQo+IEtvbnN0YW50
aW4gS2hsZWJuaWtvdg0KPiBTZW50OiBNb25kYXksIEp1bHkgMTUsIDIwMTMgMDU6MzkNCj4gVG86
IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7IFdpbmtsZXIsIFRvbWFzOyBsaW51eC0NCj4g
d2lyZWxlc3NAdmdlci5rZXJuZWwub3JnDQo+IFN1YmplY3Q6IFJlOiBbMy4xMC4xIE1FSV9NRV0g
c3RyYW5nZSBrZXJuZWwgY3Jhc2gNCj4gDQo+IFRoaXMgaGFzIGhhcHBlbmVkIGFnYWluLiBUaGlz
IHRpbWUgd2l0aG91dCB3YXJuaW5ncyBhbmQgd2l0aG91dCBzdXNwZW5kLQ0KPiByZXN1bWUuDQo+
IFNlZW1zIGxpa2UgJ21laV9tZScgY29ycnVwdHMga2VybmVsIG1lbW9yeS4NCg0KSSB3aWxsIHBv
c3QgdGhlIGZpeCB0b2RheSBJIGhvcGUuDQoNClRoYW5rcw0KVG9tYXMNCg0K
^ permalink raw reply
* Re: [3.10.1 MEI_ME] strange kernel crash
From: Konstantin Khlebnikov @ 2013-07-15 2:38 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org, Tomas Winkler, linux-wireless
In-Reply-To: <51E2FE1C.207@openvz.org>
This has happened again. This time without warnings and without suspend-resume.
Seems like 'mei_me' corrupts kernel memory.
My setup is simple: it's thinkpad x220 which receives flow of wake-on-lan packets via the ethernet.
[ 6596.895370] mei_me 0000:00:16.0: version message writet failed
[ 6596.895373] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
[ 6596.895376] mei_me 0000:00:16.0: version message writet failed
[ 6596.895378] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
[ 6596.895381] mei_me 0000:00:16.0: version message writet failed
[ 6596.895383] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
[ 6596.895386] mei_me 0000:00:16.0: version message writet failed
[ 6596.895388] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
[ 6596.895391] mei_me 0000:00:16.0: version message writet failed
[ 6596.895394] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
[ 6596.895397] mei_me 0000:00:16.0: version message writet failed
[ 6596.895399] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
[ 6596.895402] general protection fault: 0000 [#1] SMP
[ 6596.895423] Modules linked in: iwldvm iwlwifi nfsd auth_rpcgss oid_registry nfs_acl nfs lockd sunrpc bridge stp llc
tun fuse snd_hda_codec_hdmi snd_hda_codec_conexant iTCO_wdt snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_page_alloc
intel_powerclamp coretemp snd_seq_midi snd_seq_midi_event kvm_intel kvm snd_rawmidi cdc_ncm usbnet mii uvcvideo cdc_acm
cdc_wdm snd_seq videobuf2_vmalloc snd_seq_device snd_timer videobuf2_memops videobuf2_core videodev lpc_ich mfd_core
thinkpad_acpi snd wmi i915 soundcore drm_kms_helper hid_logitech_dj sdhci_pci sdhci e1000e ptp
[ 6596.895425] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 3.10.1-zurg-00001-gaa457b5 #107
[ 6596.895426] Hardware name: LENOVO 4291QY6/4291QY6, BIOS 8DET51WW (1.21 ) 08/02/2011
[ 6596.895427] task: ffff88040c0bc560 ti: ffff88040c12e000 task.ti: ffff88040c12e000
[ 6596.895433] RIP: 0010:[<ffffffff8107a471>] [<ffffffff8107a471>] load_cr3+0x21/0x30
[ 6596.895434] RSP: 0018:ffff88040c12fe78 EFLAGS: 00010002
[ 6596.895435] RAX: 000077ff80000000 RBX: ffff88040abf1380 RCX: 0000000000000002
[ 6596.895436] RDX: 0000000080000000 RSI: ffff88040595be70 RDI: 0000780000000001
[ 6596.895436] RBP: ffff88040c12fe78 R08: 0000000000000000 R09: 0000000000000001
[ 6596.895437] R10: 0000000000000001 R11: 7fffffffffffffff R12: ffff88041e292dc0
[ 6596.895438] R13: ffff88040abf1380 R14: 0000000000000000 R15: ffff88040595be70
[ 6596.895440] FS: 0000000000000000(0000) GS:ffff88041e280000(0000) knlGS:0000000000000000
[ 6596.895440] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 6596.895441] CR2: 00007f3ec00571e8 CR3: 0000000408848000 CR4: 00000000000407e0
[ 6596.895442] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 6596.895443] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 6596.895443] Stack:
[ 6596.895445] ffff88040c12fed8 ffffffff81626aa4 ffff88040c12ffd8 0000000000012dc0
[ 6596.895446] ffff88040c12ffd8 0000000000012dc0 ffff88040c0bc560 ffff88040c12ffd8
[ 6596.895447] ffff88040c12ffd8 ffff88040c12ffd8 ffff88040c12ffd8 ffff88040c12ffd8
[ 6596.895448] Call Trace:
[ 6596.895454] [<ffffffff81626aa4>] __schedule+0x784/0x7c0
[ 6596.895456] [<ffffffff816278d9>] schedule_preempt_disabled+0x29/0x70
[ 6596.895459] [<ffffffff8108ec45>] cpu_startup_entry+0x1f5/0x230
[ 6596.895461] [<ffffffff81096588>] ? clockevents_config_and_register+0x28/0x30
[ 6596.895464] [<ffffffff81617ce0>] start_secondary+0x209/0x20b
[ 6596.895479] Code: e8 05 b1 5a 00 5b 41 5c 5d c3 ba 00 00 00 80 48 b8 00 00 00 80 ff 77 00 00 55 48 01 d7 48 0f 42 05
a5 6b b9 00 48 89 e5 48 01 c7 <0f> 22 df 66 66 66 90 5d c3 66 0f 1f 44 00 00 66 66 66 66 90 48
[ 6596.895481] RIP [<ffffffff8107a471>] load_cr3+0x21/0x30
[ 6596.895481] RSP <ffff88040c12fe78>
Konstantin Khlebnikov wrote:
> first and only warning had happened here:
>
> Jul 14 22:49:33 zurg kernel: [ 6169.400920] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
> Jul 14 22:50:03 zurg kernel: [ 6199.422111] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
> Jul 14 22:50:33 zurg kernel: [ 6229.443292] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
> Jul 14 22:51:03 zurg kernel: [ 6259.464476] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
> Jul 14 22:51:33 zurg kernel: [ 6289.485675] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
> Jul 14 22:52:03 zurg kernel: [ 6319.506868] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
>
> soon after that kernel had crashed
>
> [ 6349.664704] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
> [ 6349.664709] mei_me 0000:00:16.0: version message writet failed
> [ 6349.664711] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
> [ 6349.664714] mei_me 0000:00:16.0: version message writet failed
> [ 6349.664716] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
> [ 6349.664719] mei_me 0000:00:16.0: version message writet failed
> [ 6349.988121] kernel tried to execute NX-protected page - exploit attempt? (uid: 1000)
> [ 6349.988162] BUG: unable to handle kernel paging request at ffff88040b242000
> [ 6349.988199] IP: [<ffff88040b242000>] 0xffff88040b241fff
> [ 6349.988227] PGD 1ed4067 PUD 1ed7067 PMD 800000040b2001e3
> [ 6349.988257] Oops: 0011 [#1] SMP
> [ 6349.988276] Modules linked in: iwldvm iwlwifi nfsd auth_rpcgss oid_registry nfs_acl nfs lockd sunrpc bridge stp llc
> tun fuse snd_hda_codec_hdmi snd_hda_codec_conexant snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_page_alloc
> thinkpad_acpi snd_seq_midi snd_seq_midi_event iTCO_wdt snd_rawmidi intel_powerclamp coretemp hid_logitech_dj cdc_ncm
> uvcvideo kvm_intel kvm usbnet videobuf2_vmalloc videobuf2_memops mii videobuf2_core videodev cdc_wdm cdc_acm snd_seq
> snd_seq_device snd_timer i915 snd soundcore lpc_ich mfd_core wmi drm_kms_helper sdhci_pci sdhci e1000e ptp
> [ 6349.988581] CPU: 3 PID: 5297 Comm: xfce4-panel Tainted: G W 3.10.1-zurg-00001-gaa457b5 #107
> [ 6349.988622] Hardware name: LENOVO 4291QY6/4291QY6, BIOS 8DET51WW (1.21 ) 08/02/2011
> [ 6349.988658] task: ffff88040a623e70 ti: ffff880409aec000 task.ti: ffff880409aec000
> [ 6349.988691] RIP: 0010:[<ffff88040b242000>] [<ffff88040b242000>] 0xffff88040b241fff
> [ 6349.988728] RSP: 0018:ffff880409aedb98 EFLAGS: 00010006
> [ 6349.988752] RAX: ffff8803f554b120 RBX: 00000000f554b138 RCX: 00000000000000c3
> [ 6349.988785] RDX: 0000000000000001 RSI: 0000000000000001 RDI: ffff8803f554b120
> [ 6349.988816] RBP: ffff880409aedbd8 R08: 00000000000000c3 R09: 001300360002051e
> [ 6349.988849] R10: 010043e70007033e R11: 0100003201000004 R12: ffff88040a84c8c8
> [ 6349.988880] R13: ffff8803f554b148 R14: 0000000000000001 R15: 0000000000000001
> [ 6349.988913] FS: 00007f3779c239c0(0000) GS:ffff88041e2c0000(0000) knlGS:0000000000000000
> [ 6349.988949] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 6349.988975] CR2: ffff88040b242000 CR3: 000000040a390000 CR4: 00000000000407e0
> [ 6349.989008] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 6349.989040] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 6349.989071] Stack:
> [ 6349.989082] ffffffff8107a7a8 0000000100000000 00000000000000c3 ffff88040a84c8c0
> [ 6349.989121] 0000000000000001 0000000000000001 00000000000000c3 0000000000000286
> [ 6349.989159] ffff880409aedc10 ffffffff8107b994 ffff880405458340 00000000000000e4
> [ 6349.989198] Call Trace:
> [ 6349.989215] [<ffffffff8107a7a8>] ? __wake_up_common+0x58/0x90
> [ 6349.989244] [<ffffffff8107b994>] __wake_up_sync_key+0x44/0x60
> [ 6349.989272] [<ffffffff8147b0da>] sock_def_readable+0x3a/0x70
> [ 6349.989300] [<ffffffff8153c6a8>] unix_stream_sendmsg+0x1f8/0x3f0
> [ 6349.989330] [<ffffffff81477a53>] sock_aio_write+0xe3/0x100
> [ 6349.989357] [<ffffffff811300dc>] do_sync_readv_writev+0x6c/0xa0
> [ 6349.989386] [<ffffffff8113138b>] do_readv_writev+0xbb/0x240
> [ 6349.989414] [<ffffffff8147865d>] ? SYSC_recvfrom+0x10d/0x140
> [ 6349.989441] [<ffffffff8113574f>] ? SYSC_newstat+0x2f/0x40
> [ 6349.989468] [<ffffffff811315a5>] vfs_writev+0x35/0x60
> [ 6349.989493] [<ffffffff811316b9>] SyS_writev+0x49/0xa0
> [ 6349.989518] [<ffffffff811439e5>] ? SyS_poll+0x65/0x100
> [ 6349.989545] [<ffffffff81630919>] system_call_fastpath+0x16/0x1b
> [ 6349.989572] Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 <00> 40 97 0b 04 88 ff ff 08 20 24 0b 04 88 ff ff 08 20 24 0b 04
> [ 6349.989748] RIP [<ffff88040b242000>] 0xffff88040b241fff
> [ 6349.989775] RSP <ffff880409aedb98>
> [ 6349.989792] CR2: ffff88040b242000
>
> There was only one mine patch for intel gpu (https://bugs.freedesktop.org/show_bug.cgi?id=54089)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: Using CC BY-SA for wireless wiki content
From: Larry Finger @ 2013-07-14 22:54 UTC (permalink / raw)
To: Xose Vazquez Perez; +Cc: Luis R. Rodriguez, linux-wireless
In-Reply-To: <51E1B6BB.7060903@gmail.com>
On 07/13/2013 03:21 PM, Xose Vazquez Perez wrote:
> Luis R. Rodriguez wrote:
>
>> Anyone have any issues if we license the wiki content on
>> wireless.kernel.org under CC BY-SA license? That would make it
>> compatible with Wikipedia. Please shout out if you disagree with this
>> move as at this point we have random collaborations but at least as
>> per initial review it seems this would be a good idea. Want to see if
>> anyone disagrees before we do the move.
>
> No problem from my side.
>
>
> waiting for the rest of http://wireless.kernel.org/TrustedEditorsGroup
>
> JohannesBerg
> Zajec
> AlbertPool
> blubber
> SeanSantos
> Nick Lee
> HaukeMehrtens
> gabs
> aspriel
> ChandrakantSharpa
> WimLewis
> PaterStein
> LarryFinger
No problem for me.
Larry
> KalleValo
> Yuryu
> John Linville
> David Wang
> Christian Lamparter
> LucianoCoelho
> ZefirKurtisi
> nbd
> kevin
> BuZZ-dEE
> --
> 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
* [PATCH 3/4] mac80211_hwsim: claim active monitor support
From: Johannes Berg @ 2013-07-14 20:57 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
In-Reply-To: <1373835442-3322-1-git-send-email-johannes@sipsolutions.net>
From: Johannes Berg <johannes.berg@intel.com>
It seems to actually work this way already, so we
may need to do some work to make monitor interfaces
be _not_ active in hwsim instead.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
drivers/net/wireless/mac80211_hwsim.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
index 0a439f8..7b2a622 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -2311,6 +2311,7 @@ static int __init init_mac80211_hwsim(void)
hw->wiphy->flags |= WIPHY_FLAG_SUPPORTS_TDLS |
WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL |
WIPHY_FLAG_AP_UAPSD;
+ hw->wiphy->features |= NL80211_FEATURE_ACTIVE_MONITOR;
/* ask mac80211 to reserve space for magic */
hw->vif_data_size = sizeof(struct hwsim_vif_priv);
--
1.8.0
^ permalink raw reply related
* [PATCH 4/4] mac80211: make active monitor injection work w/ HW queue
From: Johannes Berg @ 2013-07-14 20:57 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
In-Reply-To: <1373835442-3322-1-git-send-email-johannes@sipsolutions.net>
From: Johannes Berg <johannes.berg@intel.com>
When a driver (like hwsim) uses HW queue control an
active monitor vif needs to be used for the queues,
make the code do that. Otherwise we'd bail out and
drop the frames.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/tx.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index f82301b..be4d3ca 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1272,6 +1272,10 @@ static bool __ieee80211_tx(struct ieee80211_local *local,
switch (sdata->vif.type) {
case NL80211_IFTYPE_MONITOR:
+ if (sdata->u.mntr_flags & MONITOR_FLAG_ACTIVE) {
+ vif = &sdata->vif;
+ break;
+ }
sdata = rcu_dereference(local->monitor_sdata);
if (sdata) {
vif = &sdata->vif;
--
1.8.0
^ permalink raw reply related
* [PATCH 2/4] mac80211_hwsim: claim uAPSD support
From: Johannes Berg @ 2013-07-14 20:57 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
In-Reply-To: <1373835442-3322-1-git-send-email-johannes@sipsolutions.net>
From: Johannes Berg <johannes.berg@intel.com>
Since mac80211 does everything, we can just claim it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
drivers/net/wireless/mac80211_hwsim.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
index 11adae8..0a439f8 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -2309,7 +2309,8 @@ static int __init init_mac80211_hwsim(void)
hw->flags |= IEEE80211_HW_SUPPORTS_RC_TABLE;
hw->wiphy->flags |= WIPHY_FLAG_SUPPORTS_TDLS |
- WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL;
+ WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL |
+ WIPHY_FLAG_AP_UAPSD;
/* ask mac80211 to reserve space for magic */
hw->vif_data_size = sizeof(struct hwsim_vif_priv);
--
1.8.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox