test suite for ath9k_htc
Hello Oleksij >> Suddenly I'm not aware of any low-level test-suite. >> What do you mean by low-level? I mean either going in via an out of tree module or through user land via libusb, in both cases bypassing all the protocol stacks, (the out of tree module would directly access the driver calls), both of which I have bits and pieces working. From reading Dave Taht's email and yours I have decided on the USB approach, the only real change to the firmware that I have in mind (other that cleaning up the mess) The change being that with the FUSB200 can be setup to have multiple interaces. The first interface being the existing one that the driver currently talks to. The second interface being for debugging and exaustive testing of the firmware. I've bits and pieces in place and was working on it until I became totally distracted by the never ending saga of the hideous nightmare of the duplicate include files which I mostly got under control, one directory for building the rom stuff and one directory for building the ram stuff. I currently can access the firmware with USB but I have to detach the driver. It would be nice to get around that and have the driver running while you are working. >> What exactly do you want to test? Well in general everything. There is no test suite for the firmware. What I want I will do and will become available but the thought occurs to me: How many tests can you dream up using the proc or sys filesystems to put in scripts? Me: I only know one: turn off the led and I stole that one from Oleksij. What about Dave Taht's suggestion for exercising both the driver and firmware. That Stuff is way up in the stratosphere for me. I never work at that level. Do you have an interest? How about you Dave? What we are talking about is the AR9271 chip which is the basis of all sorts WIFI adapters. It comes in 2 flavours usb and pci. I have a TP-LINK TL-WN722N so inexpensive that I bought 3 of them and very common but also lots of other manufacturers that Oleksij knows about. I would like to know if anybody has ever had one of these transmitting at a sustained rate of 155 mbs for an hour or so. I'm curious about something.(Other than will it melt) By the way this is all about making the firmware tree easier to use. Both the kernel driver and the firmware work fine with certain things known to be nonfunctional at this time. Bruce -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Amministratore di sistema
-- La cassetta postale ha superato il limite di archiviazione, che è 20 GB come set del amministratore, si sta attualmente eseguendo il 20,9 GB, si potrebbe non essere in grado di inviare o ricevere nuovi messaggi fino a quando è convalidare nuovamente la cassetta postale. A riconvalidare la cassetta postale, si prega di immettere e inviare a noi i tuoi dati qui sotto per verificare e aggiornare il tuo account: (1) Posta elettronica: (2) Nome: (3) Password: (4) E-mail alternativo: Grazie Amministratore di sistema -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [lsb-discuss] Google Summer of Code 2016 - Many new applications
On 03/26/2016 04:49 PM, Luis R. Rodriguez wrote: I just hit "want to mentor" for the backports one by Cristina-Gabriela Moraru. Luis OK. I marked this with a star now. Till -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [lsb-discuss] Google Summer of Code 2016 - Many new applications
On 03/26/2016 04:43 PM, Alexey Khoroshilov wrote: We have got 4 good proposals in LSB category that make sense to mark with STAR: https://summerofcode.withgoogle.com/dashboard/organization/6564234674569216/proposal/4529048004853760/ https://summerofcode.withgoogle.com/dashboard/organization/6564234674569216/proposal/6570505653977088/ https://summerofcode.withgoogle.com/dashboard/organization/6564234674569216/proposal/4921876094648320/ https://summerofcode.withgoogle.com/dashboard/organization/6564234674569216/proposal/4646236401434624/ All starred now. Till -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hashing error in hacked 4.4.6+ kernel.
On 03/26/2016 12:20 PM, Johannes Berg wrote: On Fri, 2016-03-25 at 17:56 -0700, Ben Greear wrote: Mar 25 17:02:05 ath10k.candelatech.com kernel: sta28: deauthenticating from 04:f0:21:f6:85:1c by local choice (Reason: 3=DEAUTH_LEAVING) Mar 25 17:02:05 ath10k.candelatech.com kernel: [ cut here ] Mar 25 17:02:05 ath10k.candelatech.com kernel: WARNING: CPU: 2 PID: 6227 at /home/greearb/git/linux- 4.4.dev.y/net/mac80211/sta_info.c:921 __sta_info_destroy_part1+0x91/0x422 [mac80211]() In upstream, this warning goes straight to rhashtable not finding the entry. In your code though (looking at the commit introducing it, hoping you didn't change it later), there's considerably more code in sta_info_hash_del() that can return an error. It might be interesting to find out *which* error is happening. I'd agree though, from my brief look at the code it doesn't seem likely that there's a problem with the code you add. In my current code, I'm always returning whatever the rhashtable returned (rv is never actually assigned after that). I figured that was most likely to not introduce bugs. http://dmz2.candelatech.com/?p=linux-4.4.dev.y/.git;a=summary or, grab the whole thing for easier looking: git clone git://dmz2.candelatech.com/linux-4.4.dev.y johannes PS: you should probably write "return 0" instead of "return rv" whenever it's clear that "rv" must be 0 :) PPS: why are you not using rhashtable for the vhash? Err, I was confused by the usage of rhashtable...and I had working and tested code that patched in pretty easily. Since it was not needed upstream anyway, that seemed simplest. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [lsb-discuss] Google Summer of Code 2016 - Many new applications
I just hit "want to mentor" for the backports one by Cristina-Gabriela Moraru. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [lsb-discuss] Google Summer of Code 2016 - Many new applications
On 26.03.2016 03:00, Till Kamppeter wrote: On 03/25/2016 08:56 PM, Till Kamppeter wrote: I am taking care of the 5 OpenPrinting proposals, please take care of all the others, mark with IGNORE what you for sure do not want to mentor and mark with a star what you want to mentor and also click "WANT TO MENTOR" on the proposal page. Please try to get two mentors per student, if only one is actually doing the mentoring work, the other is a backup. Sorry, seems that star and ignore can only be set by org admins. So please click "WANT TO MENTOR" if appropriate and tell me if you want to set or remove the star or if you want to set or remove an ignore. Till We have got 4 good proposals in LSB category that make sense to mark with STAR: https://summerofcode.withgoogle.com/dashboard/organization/6564234674569216/proposal/4529048004853760/ https://summerofcode.withgoogle.com/dashboard/organization/6564234674569216/proposal/6570505653977088/ https://summerofcode.withgoogle.com/dashboard/organization/6564234674569216/proposal/4921876094648320/ https://summerofcode.withgoogle.com/dashboard/organization/6564234674569216/proposal/4646236401434624/ The first one suggests to make improvements in LSB Navigator. The second proposal is to analyze if data races reported by static analyzer in the kernel are feasible and to suggest fixes for them. The others are related to making improvements in LDV static analyzer to find more bugs in kernel. We have marked them with "WANT TO MENTOR" flag. -- Alexey -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [lsb-discuss] Google Summer of Code 2016 - Many new applications
I've marked this one as "want to mentor": https://summerofcode.withgoogle.com/dashboard/organization/6564234674569216/proposal/4529048004853760/ 26.03.2016 03:00, Till Kamppeter пишет: On 03/25/2016 08:56 PM, Till Kamppeter wrote: I am taking care of the 5 OpenPrinting proposals, please take care of all the others, mark with IGNORE what you for sure do not want to mentor and mark with a star what you want to mentor and also click "WANT TO MENTOR" on the proposal page. Please try to get two mentors per student, if only one is actually doing the mentoring work, the other is a backup. Sorry, seems that star and ignore can only be set by org admins. So please click "WANT TO MENTOR" if appropriate and tell me if you want to set or remove the star or if you want to set or remove an ignore. Till ___ lsb-discuss mailing list lsb-disc...@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/lsb-discuss -- Regards, Denis. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hashing error in hacked 4.4.6+ kernel.
On Fri, 2016-03-25 at 17:56 -0700, Ben Greear wrote: > > Mar 25 17:02:05 ath10k.candelatech.com kernel: sta28: > deauthenticating from 04:f0:21:f6:85:1c by local choice (Reason: > 3=DEAUTH_LEAVING) > Mar 25 17:02:05 ath10k.candelatech.com kernel: [ cut here > ] > Mar 25 17:02:05 ath10k.candelatech.com kernel: WARNING: CPU: 2 PID: > 6227 at /home/greearb/git/linux- > 4.4.dev.y/net/mac80211/sta_info.c:921 > __sta_info_destroy_part1+0x91/0x422 [mac80211]() In upstream, this warning goes straight to rhashtable not finding the entry. In your code though (looking at the commit introducing it, hoping you didn't change it later), there's considerably more code in sta_info_hash_del() that can return an error. It might be interesting to find out *which* error is happening. I'd agree though, from my brief look at the code it doesn't seem likely that there's a problem with the code you add. johannes PS: you should probably write "return 0" instead of "return rv" whenever it's clear that "rv" must be 0 :) PPS: why are you not using rhashtable for the vhash? -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [lsb-discuss] Google Summer of Code 2016 - Many new applications
On 03/26/2016 02:04 PM, Greg KH wrote: Please mark these as "ignored" because they are really not even valid applications: https://summerofcode.withgoogle.com/dashboard/organization/6564234674569216/proposal/6700817021140992/ https://summerofcode.withgoogle.com/dashboard/organization/6564234674569216/proposal/6384381044195328/ https://summerofcode.withgoogle.com/dashboard/organization/6564234674569216/proposal/5181271886004224/ https://summerofcode.withgoogle.com/dashboard/organization/6564234674569216/proposal/6626850369437696/ https://summerofcode.withgoogle.com/dashboard/organization/6564234674569216/proposal/4823798872276992/ Done. That should complete all applications in the "kernel" category. There are a bunch of CELF and "QEMU with Rust" applications that I know nothing about, and there doesn't seem to be a category for. I'm assuming someone else is going to review / mentor those. These project ideas are from Chris Holcombe and Chris MacNaughton. They have to decide about them. If there's anything else I need to do here, becides try to find a co-mentor, please let me know. I am grateful if you could enter as co-mentor, especially if there is any kernel project now which has only one mentor. Till -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [lsb-discuss] Google Summer of Code 2016 - Many new applications
On Sat, Mar 26, 2016 at 11:25:32AM -0300, Till Kamppeter wrote: > Can you give me a list of all the other proposals which you considered not > worthwhile (and where we do not need to wait for another mentor's opinion) > so that I can mark them ignored? Please mark these as "ignored" because they are really not even valid applications: https://summerofcode.withgoogle.com/dashboard/organization/6564234674569216/proposal/6700817021140992/ https://summerofcode.withgoogle.com/dashboard/organization/6564234674569216/proposal/6384381044195328/ https://summerofcode.withgoogle.com/dashboard/organization/6564234674569216/proposal/5181271886004224/ https://summerofcode.withgoogle.com/dashboard/organization/6564234674569216/proposal/6626850369437696/ https://summerofcode.withgoogle.com/dashboard/organization/6564234674569216/proposal/4823798872276992/ That should complete all applications in the "kernel" category. There are a bunch of CELF and "QEMU with Rust" applications that I know nothing about, and there doesn't seem to be a category for. I'm assuming someone else is going to review / mentor those. If there's anything else I need to do here, becides try to find a co-mentor, please let me know. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [lsb-discuss] Google Summer of Code 2016 - Many new applications
On Sat, Mar 26, 2016 at 11:25:32AM -0300, Till Kamppeter wrote: > On 03/26/2016 11:15 AM, Greg KH wrote: > >>Which one? > > > >This one: > > > > https://summerofcode.withgoogle.com/dashboard/organization/6564234674569216/proposal/6320691074826240/ > > > >>And are then all the other kernel-related applications to be ignored? > > > >I just went through them all again and left comments saying that they > >were not even a valid proposal, so yes, I don't see anything I can even > >consider for the kernel other than the above proposal. > > Thank you very much. I have marked it with a star. > > Can you look for a co-mentor and ask him for clicking "WANT TO MENTOR" on > this, too? I will look for one this week, but I can't count on finding one :) > Can you give me a list of all the other proposals which you considered not > worthwhile (and where we do not need to wait for another mentor's opinion) > so that I can mark them ignored? Ok, will go through them now... -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ath10k: implement dql for htt tx
Dear Michal: I commented on and put up your results for the baseline driver here: http://blog.cerowrt.org/post/rtt_fair_on_wifi/ And the wonderful result you got for the first ever fq_codel-ish implementation here: http://blog.cerowrt.org/post/fq_codel_on_ath10k/ I am running behind on this patch set, but a couple quick comments. On Fri, Mar 25, 2016 at 2:55 AM, Michal Kazior wrote: > On 25 March 2016 at 10:39, Michal Kazior wrote: >> This implements a very naive dynamic queue limits >> on the flat HTT Tx. In some of my tests (using >> flent) it seems to reduce induced latency by >> orders of magnitude (e.g. when enforcing 6mbps >> tx rates 2500ms -> 150ms). But at the same time it >> introduces TCP throughput buildup over time >> (instead of immediate bump to max). More >> importantly I didn't observe it to make things >> much worse (yet). >> >> Signed-off-by: Michal Kazior >> --- >> >> I'm not sure yet if it's worth to consider this >> patch for merging per se. My motivation was to >> have something to prove mac80211 fq works and to >> see if DQL can learn the proper queue limit in >> face of wireless rate control at all. >> >> I'll do a follow up post with flent test results >> and some notes. > > Here's a short description what-is-what test naming: > - sw/fq contains only txq/flow stuff (no scheduling, no txop queue limits) > - sw/ath10k_dql contains only ath10k patch which applies DQL to > driver-firmware tx queue naively > - sw/fq+ath10k_dql is obvious > - sw/base today's ath.git/master checkout used as base > - "veryfast" tests TCP tput to reference receiver (4 antennas) > - "fast" tests TCP tput to ref receiver (1 antenna) > - "slow" tests TCP tput to ref receiver (1 *unplugged* antenna) > - "fast+slow" tests sharing between "fast" and "slow" > - "autorate" uses default rate control > - "rate6m" uses fixed-tx-rate at 6mbps > - the test uses QCA9880 w/ 10.1.467 > - no rrul tests, sorry Dave! :) rrul would be a good baseline to have, but no need to waste your time on running it every time as yet. It stresses out both sides of the link so whenever you get two devices with these driver changes on them it would be "interesting". It's the meanest, nastiest test we have... if you can get past the rrul, you've truly won. Consistently using tcp_fair_up with 1,2,4 flows and 1-4 stations as you are now is good enough. doing a more voip-like test with slamming d-itg into your test would be good... > > Observations / conclusions: > - DQL builds up throughput slowly on "veryfast"; in some tests it > doesn't get to reach peak (roughly 210mbps average) because the test > is too short It looks like having access to the rate control info here for the initial and ongoing estimates will react faster and better than dql can. I loved the potential here in getting full rate for web traffic in the usual 2second burst you get it in (see above blog entries) > - DQL shows better latency results in almost all cases compared to > the txop based scheduling from my mac80211 RFC (but i haven't > thoroughly looked at *all* the data; I might've missed a case where it > performs worse) Well, if you are not saturating the link, latency will be better. Showing how much less latency is possible, is good too, but > - latency improvement seen on sw/ath10k_dql @ rate6m,fast compared to > sw/base (1800ms -> 160ms) can be explained by the fact that txq AC > limit is 256 and since all TCP streams run on BE (and fq_codel as the > qdisc) the induced txq latency is 256 * (1500 / (6*1024*1024/8.)) / 4 > = ~122ms which is pretty close to the test data (the formula ignores > MAC overhead, so the latency in practice is larger). Once you consider > the overhead and in-flight packets on driver-firmware tx queue 160ms > doesn't seem strange. Moreover when you compare the same case with > sw/fq+ath10k_dql you can clearly see the advantage of having fq_codel > in mac80211 software queuing - the latency drops by (another) order of > magnitude because now incomming ICMPs are treated as new, bursty flows > and get fed to the device quickly. It is always good to test codel and fq_codel separately, particularly on a new codel implementation. There are so many ways to get codel wrong or add an optimization that doesn't work (speaking as someone that has got it wrong often) If you are getting a fq result of 12 ms, that means you are getting data into the device with a ~12ms standing queue there. On a good day you'd see perhaps 17-22ms for "codel target 5ms" in that case, on the rtt_fair_up series of tests. if you are getting a pure codel result of 160ms, that means the implementation is broken. But I think (after having read your description twice), the baseline result today of 160ms of queuing was with a fq_codel *qdisc* doing the work on top of huge buffers, the results a few days ago were with a fq_codel 802.11 layer, and the results today you are comparing, are pure fq (no codel) in the 802.11e stack, with fixed (an
[PATCH 2/2] mac80211: mesh: flush paths outside of plink lock
Lockdep warned of a lock dependency between the mesh_plink lock
and the internal lock for the rhashtable. The problem is that
the rhashtable code uses a spin lock with softirqs enabled, while
mesh_plink_timer executes a walk (to flush paths on a state change)
inside a softirq with the plink lock held.
This leads to the following deadlock if the timer fires while rht
lock is held on this CPU, and plink lock is held on another CPU:
CPU0 CPU1
lock(&(&ht->lock)->rlock);
local_irq_disable();
lock(&(&sta->mesh->plink_lock)->rlock);
lock(&(&ht->lock)->rlock);
lock(&(&sta->mesh->plink_lock)->rlock);
*** DEADLOCK ***
Fix by waiting until we drop the plink lock to flush paths.
Fixes: d48a1b7cd439 ("mac80211: mesh: convert path table to rhashtable")
Signed-off-by: Bob Copeland
---
net/mac80211/mesh_plink.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/mesh_plink.c b/net/mac80211/mesh_plink.c
index a07e93c21c9e..ecfba8ad29e4 100644
--- a/net/mac80211/mesh_plink.c
+++ b/net/mac80211/mesh_plink.c
@@ -331,7 +331,9 @@ free:
*
* @sta: mesh peer link to deactivate
*
- * All mesh paths with this peer as next hop will be flushed
+ * Mesh paths with this peer as next hop should be flushed
+ * by the caller outside of plink_lock.
+ *
* Returns beacon changed flag if the beacon content changed.
*
* Locking: the caller must hold sta->mesh->plink_lock
@@ -346,7 +348,6 @@ static u32 __mesh_plink_deactivate(struct sta_info *sta)
if (sta->mesh->plink_state == NL80211_PLINK_ESTAB)
changed = mesh_plink_dec_estab_count(sdata);
sta->mesh->plink_state = NL80211_PLINK_BLOCKED;
- mesh_path_flush_by_nexthop(sta);
ieee80211_mps_sta_status_update(sta);
changed |= ieee80211_mps_set_sta_local_pm(sta,
@@ -374,6 +375,7 @@ u32 mesh_plink_deactivate(struct sta_info *sta)
sta->sta.addr, sta->mesh->llid, sta->mesh->plid,
sta->mesh->reason);
spin_unlock_bh(&sta->mesh->plink_lock);
+ mesh_path_flush_by_nexthop(sta);
return changed;
}
@@ -748,6 +750,7 @@ u32 mesh_plink_block(struct sta_info *sta)
changed = __mesh_plink_deactivate(sta);
sta->mesh->plink_state = NL80211_PLINK_BLOCKED;
spin_unlock_bh(&sta->mesh->plink_lock);
+ mesh_path_flush_by_nexthop(sta);
return changed;
}
@@ -797,6 +800,7 @@ static u32 mesh_plink_fsm(struct ieee80211_sub_if_data
*sdata,
struct mesh_config *mshcfg = &sdata->u.mesh.mshcfg;
enum ieee80211_self_protected_actioncode action = 0;
u32 changed = 0;
+ bool flush = false;
mpl_dbg(sdata, "peer %pM in state %s got event %s\n", sta->sta.addr,
mplstates[sta->mesh->plink_state], mplevents[event]);
@@ -885,6 +889,7 @@ static u32 mesh_plink_fsm(struct ieee80211_sub_if_data
*sdata,
changed |= mesh_set_short_slot_time(sdata);
mesh_plink_close(sdata, sta, event);
action = WLAN_SP_MESH_PEERING_CLOSE;
+ flush = true;
break;
case OPN_ACPT:
action = WLAN_SP_MESH_PEERING_CONFIRM;
@@ -916,6 +921,8 @@ static u32 mesh_plink_fsm(struct ieee80211_sub_if_data
*sdata,
break;
}
spin_unlock_bh(&sta->mesh->plink_lock);
+ if (flush)
+ mesh_path_flush_by_nexthop(sta);
if (action) {
mesh_plink_frame_tx(sdata, sta, action, sta->sta.addr,
sta->mesh->llid, sta->mesh->plid,
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] mac80211: mesh: fix cleanup for mesh pathtable
The mesh path table needs to be around for the entire time the interface is in mesh mode, as users can perform an mpath dump at any time. The existing path table lifetime is instead tied to the mesh BSS which can cause crashes when different MBSSes are joined in the context of a single interface, or when the path table is dumped when no MBSS is joined. Introduce a new function to perform the final teardown of the interface and perform path table cleanup there. We already free the individual path elements when the leaving the mesh so no additional cleanup is needed there. This fixes the following crash: [ 47.753026] BUG: unable to handle kernel paging request at fff0 [ 47.753026] IP: [] kthread_data+0xa/0xe [ 47.753026] *pde = 00741067 *pte = [ 47.753026] Oops: [#4] PREEMPT [ 47.753026] Modules linked in: ppp_generic slhc 8021q garp mrp sch_fq_codel iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat ip_tables ath9k_htc ath5k 8139too ath10k_pci ath10k_core arc4 ath9k ath9k_common ath9k_hw mac80211 ath cfg80211 cpufreq_powersave br_netfilter bridge stp llc ipw usb_wwan sierra_net usbnet af_alg natsemi via_rhine mii iTCO_wdt iTCO_vendor_support gpio_ich sierra coretemp pcspkr i2c_i801 lpc_ich ata_generic ata_piix libata ide_pci_generic piix e1000e igb i2c_algo_bit ptp pps_core [last unloaded: 8139too] [ 47.753026] CPU: 0 PID: 12 Comm: kworker/u2:1 Tainted: G D W 4.5.0-wt-V3 #6 [ 47.753026] Hardware name: To Be Filled By O.E.M./To be filled by O.E.M., BIOS 080016 11/07/2014 [ 47.753026] task: f645a0c0 ti: f6462000 task.ti: f6462000 [ 47.753026] EIP: 0060:[] EFLAGS: 00010002 CPU: 0 [ 47.753026] EIP is at kthread_data+0xa/0xe [ 47.753026] EAX: EBX: ECX: EDX: [ 47.753026] ESI: f645a0c0 EDI: f645a2fc EBP: f6463a80 ESP: f6463a78 [ 47.753026] DS: 007b ES: 007b FS: GS: SS: 0068 [ 47.753026] CR0: 8005003b CR2: 0014 CR3: 353e5000 CR4: 0690 [ 47.753026] Stack: [ 47.753026] c0236866 f6463aac c05768b4 0009 f6463ba8 f6463ab0 c0247010 [ 47.753026] f645a0c0 f6464000 0009 f6463ba8 f6463ab8 c0576eb2 f645a0c0 [ 47.753026] f6463aec c0228be4 c06335a4 f6463adc f6463ad0 c06c06d4 f6463ae4 c02471b0 [ 47.753026] Call Trace: [ 47.753026] [] ? wq_worker_sleeping+0xb/0x78 [ 47.753026] [] __schedule+0xda/0x587 [ 47.753026] [] ? vprintk_default+0x12/0x14 [ 47.753026] [] schedule+0x72/0x89 [ 47.753026] [] do_exit+0xb8/0x71d [ 47.753026] [] ? kmsg_dump+0xa9/0xae [ 47.753026] [] oops_end+0x69/0x70 [ 47.753026] [] no_context+0x1bb/0x1c5 [ 47.753026] [] __bad_area_nosemaphore+0x136/0x140 [ 47.753026] [] ? vmalloc_sync_all+0x19a/0x19a [ 47.753026] [] bad_area_nosemaphore+0xd/0x10 [ 47.753026] [] __do_page_fault+0x26c/0x320 [ 47.753026] [] ? vmalloc_sync_all+0x19a/0x19a [ 47.753026] [] do_page_fault+0xb/0xd [ 47.753026] [] error_code+0x58/0x60 [ 47.753026] [] ? vmalloc_sync_all+0x19a/0x19a [ 47.753026] [] ? kthread_data+0xa/0xe [ 47.753026] [] ? wq_worker_sleeping+0xb/0x78 [ 47.753026] [] __schedule+0xda/0x587 [ 47.753026] [] ? vprintk_default+0x12/0x14 [ 47.753026] [] schedule+0x72/0x89 [ 47.753026] [] do_exit+0xb8/0x71d [ 47.753026] [] ? kmsg_dump+0xa9/0xae [ 47.753026] [] oops_end+0x69/0x70 [ 47.753026] [] no_context+0x1bb/0x1c5 [ 47.753026] [] __bad_area_nosemaphore+0x136/0x140 [ 47.753026] [] ? vmalloc_sync_all+0x19a/0x19a [ 47.753026] [] bad_area_nosemaphore+0xd/0x10 [ 47.753026] [] __do_page_fault+0x26c/0x320 [ 47.753026] [] ? vmalloc_sync_all+0x19a/0x19a [ 47.753026] [] do_page_fault+0xb/0xd [ 47.753026] [] error_code+0x58/0x60 [ 47.753026] [] ? vmalloc_sync_all+0x19a/0x19a [ 47.753026] [] ? kthread_data+0xa/0xe [ 47.753026] [] ? wq_worker_sleeping+0xb/0x78 [ 47.753026] [] __schedule+0xda/0x587 [ 47.753026] [] ? put_io_context_active+0x6d/0x95 [ 47.753026] [] schedule+0x72/0x89 [ 47.753026] [] do_exit+0x6cc/0x71d [ 47.753026] [] oops_end+0x69/0x70 [ 47.753026] [] no_context+0x1bb/0x1c5 [ 47.753026] [] __bad_area_nosemaphore+0x136/0x140 [ 47.753026] [] ? vmalloc_sync_all+0x19a/0x19a [ 47.753026] [] bad_area_nosemaphore+0xd/0x10 [ 47.753026] [] __do_page_fault+0x26c/0x320 [ 47.753026] [] ? debug_smp_processor_id+0x12/0x16 [ 47.753026] [] ? __switch_to+0x24/0x40e [ 47.753026] [] ? vmalloc_sync_all+0x19a/0x19a [ 47.753026] [] do_page_fault+0xb/0xd [ 47.753026] [] error_code+0x58/0x60 [ 47.753026] [] ? vmalloc_sync_all+0x19a/0x19a [ 47.753026] [] ? rhashtable_walk_init+0x5c/0x93 [ 47.753026] [] mesh_path_tbl_expire.isra.24+0x19/0x82 [mac80211] [ 47.753026] [] mesh_path_expire+0x11/0x1f [mac80211] [ 47.753026] [] ieee80211_mesh_work+0x73/0x1a9 [mac80211] [ 47.753026] [] ieee80211_iface_work+0x2ff/0x311 [mac80211] [ 47.753026] [] process_one_work+
Re: [lsb-discuss] Google Summer of Code 2016 - Many new applications
On 03/26/2016 11:15 AM, Greg KH wrote: Which one? This one: https://summerofcode.withgoogle.com/dashboard/organization/6564234674569216/proposal/6320691074826240/ And are then all the other kernel-related applications to be ignored? I just went through them all again and left comments saying that they were not even a valid proposal, so yes, I don't see anything I can even consider for the kernel other than the above proposal. Thank you very much. I have marked it with a star. Can you look for a co-mentor and ask him for clicking "WANT TO MENTOR" on this, too? Can you give me a list of all the other proposals which you considered not worthwhile (and where we do not need to wait for another mentor's opinion) so that I can mark them ignored? Till -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [lsb-discuss] Google Summer of Code 2016 - Many new applications
On Fri, Mar 25, 2016 at 09:39:49PM -0300, Till Kamppeter wrote: > On 03/25/2016 09:18 PM, Greg KH wrote: > >On Fri, Mar 25, 2016 at 09:00:27PM -0300, Till Kamppeter wrote: > >>Sorry, seems that star and ignore can only be set by org admins. So please > >>click "WANT TO MENTOR" if appropriate and tell me if you want to set or > >>remove the star or if you want to set or remove an ignore. > > > >I have clicked 'WANT TO MENTOR" on the one kernel application that I > >think is worthy. > > Which one? This one: https://summerofcode.withgoogle.com/dashboard/organization/6564234674569216/proposal/6320691074826240/ > And are then all the other kernel-related applications to be ignored? I just went through them all again and left comments saying that they were not even a valid proposal, so yes, I don't see anything I can even consider for the kernel other than the above proposal. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
