* 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
* [PATCH 1/4] mac80211_hwsim: use ieee80211_free_txskb
From: Johannes Berg @ 2013-07-14 20:57 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
These are only strange error cases, so it's not really
all that important, but the driver really should use
ieee80211_free_tx_skb instead of just dev_kfree_skb.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
drivers/net/wireless/mac80211_hwsim.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
index cb34c78..11adae8 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -867,7 +867,7 @@ static void mac80211_hwsim_tx(struct ieee80211_hw *hw,
if (WARN_ON(skb->len < 10)) {
/* Should not happen; just a sanity check for addr1 use */
- dev_kfree_skb(skb);
+ ieee80211_free_txskb(hw, skb);
return;
}
@@ -884,13 +884,13 @@ static void mac80211_hwsim_tx(struct ieee80211_hw *hw,
}
if (WARN(!channel, "TX w/o channel - queue = %d\n", txi->hw_queue)) {
- dev_kfree_skb(skb);
+ ieee80211_free_txskb(hw, skb);
return;
}
if (data->idle && !data->tmp_chan) {
wiphy_debug(hw->wiphy, "Trying to TX when idle - reject\n");
- dev_kfree_skb(skb);
+ ieee80211_free_txskb(hw, skb);
return;
}
--
1.8.0
^ permalink raw reply related
* [3.10.1] strange kernel crash after thousands suspend-resume cycles
From: Konstantin Khlebnikov @ 2013-07-14 19:38 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org, Tomas Winkler, linux-wireless
first and only warning had happened here:
Jul 14 20:42:50 zurg kernel: [ 225.991608] ------------[ cut here ]------------
Jul 14 20:42:50 zurg kernel: [ 225.991613] WARNING: at net/mac80211/pm.c:113 __ieee80211_suspend+0x6ad/0x6d0()
Jul 14 20:42:50 zurg kernel: [ 225.991633] 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
Jul 14 20:42:50 zurg kernel: [ 225.991635] CPU: 0 PID: 4940 Comm: pm-suspend Not tainted 3.10.1-zurg-00001-gaa457b5 #107
Jul 14 20:42:50 zurg kernel: [ 225.991636] Hardware name: LENOVO 4291QY6/4291QY6, BIOS 8DET51WW (1.21 ) 08/02/2011
Jul 14 20:42:50 zurg kernel: [ 225.991637] 0000000000000009 ffff8803f5761c40 ffffffff81621b62 ffff8803f5761c78
Jul 14 20:42:50 zurg kernel: [ 225.991638] ffffffff8104e8b1 ffff880405560640 0000000000000000 ffff8804055612f8
Jul 14 20:42:50 zurg kernel: [ 225.991639] ffff8804055612f8 ffff880405560860 ffff8803f5761c88 ffffffff8104e98a
Jul 14 20:42:50 zurg kernel: [ 225.991640] Call Trace:
Jul 14 20:42:50 zurg kernel: [ 225.991643] [<ffffffff81621b62>] dump_stack+0x19/0x1b
Jul 14 20:42:50 zurg kernel: [ 225.991646] [<ffffffff8104e8b1>] warn_slowpath_common+0x61/0x80
Jul 14 20:42:50 zurg kernel: [ 225.991647] [<ffffffff8104e98a>] warn_slowpath_null+0x1a/0x20
Jul 14 20:42:50 zurg kernel: [ 225.991648] [<ffffffff815fefad>] __ieee80211_suspend+0x6ad/0x6d0
Jul 14 20:42:50 zurg kernel: [ 225.991651] [<ffffffff815d1a5a>] ieee80211_suspend+0x1a/0x30
Jul 14 20:42:50 zurg kernel: [ 225.991653] [<ffffffff8157ee87>] wiphy_suspend+0x77/0x200
Jul 14 20:42:50 zurg kernel: [ 225.991654] [<ffffffff8157ee10>] ? addresses_show+0xa0/0xa0
Jul 14 20:42:50 zurg kernel: [ 225.991656] [<ffffffff816220dc>] legacy_suspend+0x28/0x60
Jul 14 20:42:50 zurg kernel: [ 225.991659] [<ffffffff81350816>] __device_suspend+0x2c6/0x330
Jul 14 20:42:50 zurg kernel: [ 225.991660] [<ffffffff813520c8>] dpm_suspend+0x58/0x220
Jul 14 20:42:50 zurg kernel: [ 225.991661] [<ffffffff813524d7>] dpm_suspend_start+0x57/0x60
Jul 14 20:42:50 zurg kernel: [ 225.991663] [<ffffffff8108e2e0>] suspend_devices_and_enter+0x70/0x480
Jul 14 20:42:50 zurg kernel: [ 225.991665] [<ffffffff8108e868>] pm_suspend+0x178/0x260
Jul 14 20:42:50 zurg kernel: [ 225.991666] [<ffffffff8108d7b5>] state_store+0x75/0xf0
Jul 14 20:42:50 zurg kernel: [ 225.991668] [<ffffffff8124856f>] kobj_attr_store+0xf/0x20
Jul 14 20:42:50 zurg kernel: [ 225.991670] [<ffffffff81197ff3>] sysfs_write_file+0xd3/0x150
Jul 14 20:42:50 zurg kernel: [ 225.991673] [<ffffffff811306d9>] vfs_write+0xb9/0x1c0
Jul 14 20:42:50 zurg kernel: [ 225.991674] [<ffffffff81130fe9>] SyS_write+0x49/0xa0
Jul 14 20:42:50 zurg kernel: [ 225.991677] [<ffffffff81630919>] system_call_fastpath+0x16/0x1b
Jul 14 20:42:50 zurg kernel: [ 225.991678] ---[ end trace 996fb345fab7f015 ]---
after that kernel has worked fine for a hour and has done thousands s2ram suspend-resume cycles
but 'mei_me' has started generating endless noise...
Jul 14 21:52:28 zurg kernel: [ 2749.332358] cfg80211: Regulatory domain changed to country: RU
Jul 14 21:52:28 zurg kernel: [ 2749.332368] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Jul 14 21:52:28 zurg kernel: [ 2749.332373] cfg80211: (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
Jul 14 21:52:28 zurg kernel: [ 2749.332378] cfg80211: (5735000 KHz - 5835000 KHz @ 20000 KHz), (N/A, 3000 mBm)
Jul 14 21:52:29 zurg kernel: [ 2749.928395] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
Jul 14 21:52:35 zurg kernel: [ 2755.840385] IPv6: ADDRCONF(NETDEV_UP): wwan0: link is not ready
Jul 14 21:52:54 zurg kernel: [ 2775.005762] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 21:52:54 zurg kernel: [ 2775.007722] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 21:52:54 zurg kernel: [ 2775.011081] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 21:52:54 zurg kernel: [ 2775.011534] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 21:52:54 zurg kernel: [ 2775.011560] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 21:52:54 zurg kernel: [ 2775.011752] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 21:52:54 zurg kernel: [ 2775.013369] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 21:52:54 zurg kernel: [ 2775.013731] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 21:52:54 zurg kernel: [ 2775.013756] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 21:52:54 zurg kernel: [ 2775.013980] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 21:52:54 zurg kernel: [ 2775.014346] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 21:52:54 zurg kernel: [ 2775.014666] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 21:52:54 zurg kernel: [ 2775.014710] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 21:52:54 zurg kernel: [ 2775.014906] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 21:52:54 zurg kernel: [ 2775.015319] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 21:52:54 zurg kernel: [ 2775.015720] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 21:52:54 zurg kernel: [ 2775.015746] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 21:52:54 zurg kernel: [ 2775.015934] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 21:52:54 zurg kernel: [ 2775.016381] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
a lot of noise:
blind@zurg:~/src/linux$ sudo grep -c 'unexpected reset' /var/log/messages
161627
Jul 14 22:02:27 zurg kernel: [ 3347.409622] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 22:02:57 zurg kernel: [ 3377.430828] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 22:03:27 zurg kernel: [ 3407.451988] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 22:03:57 zurg kernel: [ 3437.473180] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 22:04:27 zurg kernel: [ 3467.494366] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 22:04:30 zurg kernel: [ 3470.587230] cfg80211: Calling CRDA to update world regulatory domain
Jul 14 22:04:30 zurg kernel: [ 3470.595539] cfg80211: World regulatory domain updated:
Jul 14 22:04:30 zurg kernel: [ 3470.595549] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Jul 14 22:04:30 zurg kernel: [ 3470.595555] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Jul 14 22:04:30 zurg kernel: [ 3470.595559] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Jul 14 22:04:30 zurg kernel: [ 3470.595563] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
Jul 14 22:04:30 zurg kernel: [ 3470.595567] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Jul 14 22:04:30 zurg kernel: [ 3470.595570] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Jul 14 22:04:30 zurg kernel: [ 3470.595595] cfg80211: Calling CRDA for country: GB
Jul 14 22:04:30 zurg kernel: [ 3470.605175] cfg80211: Regulatory domain changed to country: GB
Jul 14 22:04:30 zurg kernel: [ 3470.605185] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Jul 14 22:04:30 zurg kernel: [ 3470.605191] cfg80211: (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
Jul 14 22:04:30 zurg kernel: [ 3470.605195] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
Jul 14 22:04:30 zurg kernel: [ 3470.605198] cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A, 2000 mBm)
Jul 14 22:04:30 zurg kernel: [ 3470.605202] cfg80211: (5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2700 mBm)
Jul 14 22:04:30 zurg kernel: [ 3470.605205] cfg80211: (57240000 KHz - 65880000 KHz @ 2160000 KHz), (N/A, 4000 mBm)
Jul 14 22:04:33 zurg kernel: [ 3473.271126] wlan0: authenticate with 48:5d:60:e1:76:0e
Jul 14 22:04:33 zurg kernel: [ 3473.272752] wlan0: send auth to 48:5d:60:e1:76:0e (try 1/3)
Jul 14 22:04:33 zurg kernel: [ 3473.275101] wlan0: authenticated
Jul 14 22:04:33 zurg kernel: [ 3473.275877] wlan0: associate with 48:5d:60:e1:76:0e (try 1/3)
Jul 14 22:04:33 zurg kernel: [ 3473.279186] wlan0: RX AssocResp from 48:5d:60:e1:76:0e (capab=0x411 status=0 aid=3)
Jul 14 22:04:33 zurg kernel: [ 3473.285250] wlan0: associated
Jul 14 22:04:33 zurg kernel: [ 3473.285307] cfg80211: Calling CRDA for country: RU
Jul 14 22:04:33 zurg kernel: [ 3473.288113] cfg80211: Regulatory domain changed to country: RU
Jul 14 22:04:33 zurg kernel: [ 3473.288116] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Jul 14 22:04:33 zurg kernel: [ 3473.288117] cfg80211: (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
Jul 14 22:04:33 zurg kernel: [ 3473.288118] cfg80211: (5735000 KHz - 5835000 KHz @ 20000 KHz), (N/A, 3000 mBm)
Jul 14 22:04:57 zurg kernel: [ 3497.515565] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 22:05:27 zurg kernel: [ 3527.536767] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 22:05:57 zurg kernel: [ 3557.557918] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 22:06:27 zurg kernel: [ 3587.579166] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 22:06:57 zurg kernel: [ 3617.600307] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 22:07:27 zurg kernel: [ 3647.621479] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 22:07:58 zurg kernel: [ 3677.642714] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 22:08:28 zurg kernel: [ 3707.663909] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 22:08:30 zurg kernel: [ 3710.269613] cfg80211: Calling CRDA to update world regulatory domain
Jul 14 22:08:30 zurg kernel: [ 3710.278641] cfg80211: World regulatory domain updated:
Jul 14 22:08:30 zurg kernel: [ 3710.278651] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Jul 14 22:08:30 zurg kernel: [ 3710.278657] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Jul 14 22:08:30 zurg kernel: [ 3710.278661] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Jul 14 22:08:30 zurg kernel: [ 3710.278665] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
Jul 14 22:08:30 zurg kernel: [ 3710.278669] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Jul 14 22:08:30 zurg kernel: [ 3710.278673] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Jul 14 22:08:30 zurg kernel: [ 3710.278699] cfg80211: Calling CRDA for country: GB
Jul 14 22:08:30 zurg kernel: [ 3710.287280] cfg80211: Regulatory domain changed to country: GB
Jul 14 22:08:30 zurg kernel: [ 3710.287290] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Jul 14 22:08:30 zurg kernel: [ 3710.287295] cfg80211: (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
Jul 14 22:08:30 zurg kernel: [ 3710.287299] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
Jul 14 22:08:30 zurg kernel: [ 3710.287302] cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A, 2000 mBm)
Jul 14 22:08:30 zurg kernel: [ 3710.287306] cfg80211: (5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2700 mBm)
Jul 14 22:08:30 zurg kernel: [ 3710.287310] cfg80211: (57240000 KHz - 65880000 KHz @ 2160000 KHz), (N/A, 4000 mBm)
Jul 14 22:08:33 zurg kernel: [ 3712.911957] wlan0: send auth to 48:5d:60:e1:76:0e (try 1/3)
Jul 14 22:08:33 zurg kernel: [ 3712.914326] wlan0: authenticated
Jul 14 22:08:33 zurg kernel: [ 3712.915010] wlan0: associate with 48:5d:60:e1:76:0e (try 1/3)
Jul 14 22:08:33 zurg kernel: [ 3712.923070] wlan0: RX AssocResp from 48:5d:60:e1:76:0e (capab=0x411 status=0 aid=3)
Jul 14 22:08:33 zurg kernel: [ 3712.931781] wlan0: associated
Jul 14 22:08:33 zurg kernel: [ 3712.931831] cfg80211: Calling CRDA for country: RU
Jul 14 22:08:33 zurg kernel: [ 3712.934361] cfg80211: Regulatory domain changed to country: RU
Jul 14 22:08:33 zurg kernel: [ 3712.934364] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Jul 14 22:08:33 zurg kernel: [ 3712.934366] cfg80211: (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
Jul 14 22:08:33 zurg kernel: [ 3712.934367] cfg80211: (5735000 KHz - 5835000 KHz @ 20000 KHz), (N/A, 3000 mBm)
Jul 14 22:08:58 zurg kernel: [ 3737.685081] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 22:09:28 zurg kernel: [ 3767.706178] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 22:09:58 zurg kernel: [ 3797.727380] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 22:10:28 zurg kernel: [ 3827.748601] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 22:10:58 zurg kernel: [ 3857.769825] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 22:11:28 zurg kernel: [ 3887.791017] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 22:11:58 zurg kernel: [ 3917.812199] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 22:12:28 zurg kernel: [ 3947.833375] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 22:12:58 zurg kernel: [ 3977.854562] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 22:13:28 zurg kernel: [ 4007.875742] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 22:13:58 zurg kernel: [ 4037.896935] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 22:14:28 zurg kernel: [ 4067.918110] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 22:14:58 zurg kernel: [ 4097.939255] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 22:15:28 zurg kernel: [ 4127.960477] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 22:44:02 zurg kernel: [ 5839.167859] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 22:44:32 zurg kernel: [ 5869.189072] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 22:45:02 zurg kernel: [ 5899.210281] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 22:45:32 zurg kernel: [ 5929.231465] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 22:46:02 zurg kernel: [ 5959.252640] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 22:46:32 zurg kernel: [ 5989.273833] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 22:47:02 zurg kernel: [ 6019.295021] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 22:47:32 zurg kernel: [ 6049.316202] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 22:48:02 zurg kernel: [ 6079.337392] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 22:48:32 zurg kernel: [ 6109.358577] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Jul 14 22:49:02 zurg kernel: [ 6139.379733] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
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)
^ permalink raw reply
* Re: Using CC BY-SA for wireless wiki content
From: Hauke Mehrtens @ 2013-07-14 19:29 UTC (permalink / raw)
To: Xose Vazquez Perez; +Cc: Luis R. Rodriguez, linux-wireless
In-Reply-To: <51E1B6BB.7060903@gmail.com>
On 07/13/2013 10: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
I am fine with changing the License to CC BY-SA.
> gabs
> aspriel
> ChandrakantSharpa
> WimLewis
> PaterStein
> LarryFinger
> 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
* Re: Using CC BY-SA for wireless wiki content
From: Xose Vazquez Perez @ 2013-07-14 18:58 UTC (permalink / raw)
To: Rafał Miłecki; +Cc: Luis R. Rodriguez, linux-wireless
In-Reply-To: <CACna6rzERC7AZrJwLp0oP5xpjuJqvbi6SqyQPj4rQvhWSB3rTQ@mail.gmail.com>
On 07/14/2013 07:45 PM, Rafał Miłecki wrote:
> According to the:
>> Please shout out if you disagree with this
>> move
>
> I believe some of us assumed:
> no shouting out == agreement
Yes.
But it is much better to be crystal clear about licenses issues.
^ permalink raw reply
* Re: Using CC BY-SA for wireless wiki content
From: Rafał Miłecki @ 2013-07-14 17:45 UTC (permalink / raw)
To: Xose Vazquez Perez; +Cc: Luis R. Rodriguez, linux-wireless
In-Reply-To: <51E1B6BB.7060903@gmail.com>
2013/7/13 Xose Vazquez Perez <xose.vazquez@gmail.com>:
> 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
According to the:
> Please shout out if you disagree with this
> move
I believe some of us assumed:
no shouting out == agreement
I'm totally OK with that.
--
Rafał
^ permalink raw reply
* Re: [PATCH 00/50] USB: cleanup spin_lock in URB->complete()
From: Ming Lei @ 2013-07-14 14:33 UTC (permalink / raw)
To: Andy Walls
Cc: Greg Kroah-Hartman, linux-usb, Oliver Neukum, Alan Stern,
linux-input, linux-bluetooth, netdev, linux-wireless, linux-media,
alsa-devel, linux-kernel
In-Reply-To: <1373807844.4998.10.camel@palomino.walls.org>
On Sun, Jul 14, 2013 at 9:17 PM, Andy Walls <awalls@md.metrocast.net> wrote:
> On Thu, 2013-07-11 at 17:05 +0800, Ming Lei wrote:
>> Hi,
>>
>> As we are going to run URB->complete() in tasklet context[1][2],
>
> Hi,
>
> Please pardon my naivete, but why was it decided to use tasklets to
> defer work, as opposed to some other deferred work mechanism?
>
> It seems to me that getting rid of tasklets has been an objective for
> years:
>
> http://lwn.net/Articles/239633/
> http://lwn.net/Articles/520076/
> http://lwn.net/Articles/240054/
We discussed the problem in the below link previously[1], Steven
and Thomas suggested to use threaded irq handler, but which
may degrade USB mass storage performance, so we have to
take tasklet now until we rewrite transport part of USB mass storage
driver.
Also the conversion[2] has avoided the tasklet spin lock problem
already.
[1], http://marc.info/?t=137079119200001&r=1&w=2
[2], http://marc.info/?l=linux-usb&m=137286326726326&w=2
Thanks,
--
Ming Lei
^ permalink raw reply
* Re: [PATCH 00/50] USB: cleanup spin_lock in URB->complete()
From: Andy Walls @ 2013-07-14 13:17 UTC (permalink / raw)
To: Ming Lei
Cc: Greg Kroah-Hartman, linux-usb, Oliver Neukum, Alan Stern,
linux-input, linux-bluetooth, netdev, linux-wireless, linux-media,
alsa-devel, linux-kernel
In-Reply-To: <1373533573-12272-1-git-send-email-ming.lei@canonical.com>
On Thu, 2013-07-11 at 17:05 +0800, Ming Lei wrote:
> Hi,
>
> As we are going to run URB->complete() in tasklet context[1][2],
Hi,
Please pardon my naivete, but why was it decided to use tasklets to
defer work, as opposed to some other deferred work mechanism?
It seems to me that getting rid of tasklets has been an objective for
years:
http://lwn.net/Articles/239633/
http://lwn.net/Articles/520076/
http://lwn.net/Articles/240054/
Regards,
Andy
> and
> hard interrupt may be enabled when running URB completion handler[3],
> so we might need to disable interrupt when acquiring one lock in
> the completion handler for the below reasons:
>
> - URB->complete() holds a subsystem wide lock which may be acquired
> in another hard irq context, and the subsystem wide lock is acquired
> by spin_lock()/read_lock()/write_lock() in complete()
>
> - URB->complete() holds a private lock with spin_lock()/read_lock()/write_lock()
> but driver may export APIs to make other drivers acquire the same private
> lock in its interrupt handler.
>
> For the sake of safety and making the change simple, this patch set
> converts all spin_lock()/read_lock()/write_lock() in completion handler
> path into their irqsave version mechanically.
>
> But if you are sure the above two cases do not happen in your driver,
> please let me know and I can drop the unnecessary change.
>
> Also if you find some conversions are missed, also please let me know so
> that I can add it in the next round.
>
>
> [1], http://marc.info/?l=linux-usb&m=137286322526312&w=2
> [2], http://marc.info/?l=linux-usb&m=137286326726326&w=2
> [3], http://marc.info/?l=linux-usb&m=137286330626363&w=2
>
[snip]
>
>
> Thanks,
> --
> Ming Lei
^ permalink raw reply
* RE: Firmware error for Centrino N 2230
From: Johannes Berg @ 2013-07-14 10:51 UTC (permalink / raw)
To: Cedric GROSS, Adrian Chadd
Cc: 'Emmanuel Grumbach', 'linux-wireless',
linux-wireless-owner
In-Reply-To: <000301ce8077$252f1830$6f8d4890$@info>
> 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?
johannes
^ permalink raw reply
* RE: Firmware error for Centrino N 2230
From: Cedric GROSS @ 2013-07-14 9:47 UTC (permalink / raw)
To: 'Emmanuel Grumbach'; +Cc: 'linux-wireless'
In-Reply-To: <CANUX_P2K9_q_FnkzDrn4=Y3rzn3FvkPjCB4qGmts=7kni9oW4A@mail.gmail.com>
Hello Emmanuel,
> De : Emmanuel Grumbach [mailto:egrumbach@gmail.com]
> Envoyé : dimanche 14 juillet 2013 07:03
> À : sedat.dilek@gmail.com
> Cc : Cedric GROSS; linux-wireless
> Objet : Re: Firmware error for Centrino N 2230
>
> >>> > I’m trying to adapt current freebsd driver for supporting my 2230
> >>> NIC.
> >>> >
> >>> > I try to follow ucode command order defined in kernel 3.2 but I
> >>> > reach some difficulties because firmware raise error.
> >>> >
> >>> > Runtime uCode is alive. So far I sent calib result (cmd xB0),
> >>> > configured advanced BT coexistence (cmd x9B,xCC and xCD) running
> >>> > runtime calib (cmd
> >>> > x65) but the command configuring valid chain (cmd x65) failed as
> >>> > the result below :
>
> cmd 0x65? it is not valid chain command.
Yep was typo, it's 0x98.
>
> 1987 means that you haven't sent the Xtal calibration.
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.
Best regards
Cedric
^ permalink raw reply
* Re: Firmware error for Centrino N 2230
From: Emmanuel Grumbach @ 2013-07-14 5:03 UTC (permalink / raw)
To: sedat.dilek; +Cc: Cedric GROSS, linux-wireless
In-Reply-To: <CA+icZUX9jvAcvEkKSsN-KU2GWxPVGg9Z=soecwJtPL0soHD4Zw@mail.gmail.com>
>>> > I’m trying to adapt current freebsd driver for supporting my 2230
>>> NIC.
>>> >
>>> > I try to follow ucode command order defined in kernel 3.2 but I reach
>>> > some difficulties because firmware raise error.
>>> >
>>> > Runtime uCode is alive. So far I sent calib result (cmd xB0),
>>> > configured advanced BT coexistence (cmd x9B,xCC and xCD) running
>>> > runtime calib (cmd
>>> > x65) but the command configuring valid chain (cmd x65) failed as the
>>> > result below :
cmd 0x65? it is not valid chain command.
1987 means that you haven't sent the Xtal calibration.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox