On 3/22/21 6:20 PM, Brian Norris wrote:
On Mon, Mar 22, 2021 at 4:58 PM Ben Greear wrote:
On 7/22/20 6:00 AM, Felix Fietkau wrote:
On 2020-07-22 14:55, Johannes Berg wrote:
On Wed, 2020-07-22 at 14:27 +0200, Felix Fietkau wrote:
I'm considering testing a different approach (with
s? I realized I'm running Felix's patch since his mt76
driver needs it. Any chance it will go upstream?
Thanks,
Ben
- Felix
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
On 12/17/20 2:24 PM, Brian Norris wrote:
On Tue, Dec 15, 2020 at 10:23:33AM -0800, Ben Greear wrote:
On 12/15/20 9:21 AM, Youghandhar Chintala wrote:
From: Rakesh Pillai
Currently in case of target hardware restart ,we just reconfig and
re-enable the security keys and enable the network
/drivers that *can* support seamless
restarts?
If not, then just could always enable this feature in mac80211?
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
up_64+0xa4/0xb0
[2.531065] #2
[0.624831] __common_interrupt: 2.55 No irq handler for vector
[2.542389] #3
[0.624831] __common_interrupt: 3.55 No irq handler for vector
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
On 9/21/20 12:50 PM, Ben Greear wrote:
Hello,
I'm seeing this build failure, any idea what is the issue? I've cleared my
ccache (ccache --clear)
but that did not help. A pull from this morning builds on Fedora-29 with same
.config file. I tried
that same commit on my F32 sy
t/linux-linus/Makefile:1198: prepare0] Error 2
make: *** [/home/greearb/git/linux-linus/Makefile:185: __sub-make] Error 2
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
ecord)) { ... }
All in all, I think I'd want to compile this out (while leaving other debug
compiled
in) since it seems this stuff would be rarely used and it adds method calls to
hot
paths.
That is a decision for Kalle though, so see what he says...
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
On 06/27/2020 10:12 PM, Rakesh Pillai wrote:
-Original Message-
From: Ben Greear
Sent: Saturday, June 27, 2020 8:58 PM
To: Rakesh Pillai ; ath...@lists.infradead.org
Cc: linux-wirel...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ath10k: Add history for
Enable
- IRQ Disable
- NAPI poll
- CE service
- WMI cmd
- WMI event
- WMI tx completion
This will help in debugging any crash or any
improper behaviour.
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
test_bit(ATH10K_FLAG_CRASH_FLUSH, &ar->dev_flags)) {
Don't you mean !test_bit(ATH10K_FLAG_CRASH_FLUSH, &ar->dev_flags)) ???
Or maybe I'm just mis-reading your patch?
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
tie this into a watch-dog program to allow automatic
reboot
of the system soon after this event is seen, for instance.
Could you post your devlink RFC patches somewhere public?
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
hat said, at least in my experience with ath10k-ct, the OS normally recovers
fine
from firmware crashes. ath10k already reports full crash reports on udev, so
easy for user-space to notice and report bug reports upstream if it cares to.
Probably
other NICs do the same, and if not, they certainly coul
On 05/18/2020 10:09 AM, Luis Chamberlain wrote:
On Mon, May 18, 2020 at 09:58:53AM -0700, Ben Greear wrote:
On 05/18/2020 09:51 AM, Luis Chamberlain wrote:
On Sat, May 16, 2020 at 03:24:01PM +0200, Johannes Berg wrote:
On Fri, 2020-05-15 at 21:28 +, Luis Chamberlain wrote
ware has crashed.
You can listen for udev events (I think that is the right term),
and find crashes that way. You get the actual crash info as well.
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
rmware should behave similarly.
Seems like upstream ath10k could really benefit from having some test beds
so you can actually test code on different chips and have confidence
in your changes!
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
On 09/11/2019 06:21 AM, Linus Torvalds wrote:
On Wed, Sep 11, 2019 at 2:03 PM Ben Greear wrote:
Out of curiosity, I'm interested to know what ath10k NIC chipset this is from.
It's a Dell XPS 13 9380, with
02:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac
Wirele
ver.
For what it's worth, we see that WARN_ON often when ath10k firmware crashes,
but it
seems to not be a big deal and the system normally recovers fine.
Out of curiosity, I'm interested to know what ath10k NIC chipset this is from.
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
On 1/7/19 9:57 AM, Tim Chen wrote:
On 12/31/18 8:22 AM, Ben Greear wrote:
On 12/21/2018 05:17 PM, Tim Chen wrote:
If you don't worry about security and performance is paramount, then
boot with "nospectre_v2". That's explained in the document.
There seem to be lots o
On 12/21/2018 05:17 PM, Tim Chen wrote:
On 12/21/18 1:59 PM, Ben Greear wrote:
On 12/21/18 9:44 AM, Tim Chen wrote:
Thomas,
Andi and I have made an update to our draft of the Spectre admin guide.
We may be out on Christmas vacation for a while. But we want to
send it out for everyone to
anything
beyond negligible performance impact for those running systems where performance
is more important than security?
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
longer
valid. Can someone let me know what patch fixes this crash so I can apply it
while
bisecting?
https://www.spinics.net/lists/linux-block/msg17809.html
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
vior, then that might be something to consider.
Right now I don't see the point of handling packets that don't cross
network namespace boundaries specially, other than to preserve backwards
compatibility.
Well, backwards compat is a big deal all by itself!
Thanks,
Ben
Eric
--
Be
e times w/out deadlocking.
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
On 02/09/2017 11:03 PM, Valo, Kalle wrote:
Ben Greear writes:
On 02/07/2017 01:14 AM, Valo, Kalle wrote:
Adrian Chadd writes:
Removing this method makes the diff to FreeBSD larger, as "vif" in
FreeBSD is a different pointer.
(Yes, I have ath10k on freebsd working and I'd
icult for Adrian and makes the code no easier to read
for the rest of us?
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
formance regressions? I'll be complaining if
so, but will test first :)
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
On 09/28/2016 02:11 PM, David Rientjes wrote:
On Tue, 27 Sep 2016, Ben Greear wrote:
I have been running this patch for a while:
ath10k: Use GPF_DMA32 for firmware swap memory.
This fixes OS crash when using QCA 9984 NIC on x86-64 system
without vt-d enabled.
Also tested
.
Signed-off-by: Ben Greear
drivers/net/wireless/ath/ath10k/wmi.c
index e20aa39..727b3aa 100644
@@ -4491,7 +4491,7 @@ static int ath10k_wmi_alloc_chunk(struct ath10k *ar, u32
req_id,
if (!pool_size)
return -EINVAL
that source.
Why are you so concerned about the warning anyway?
Thanks,
Ben
On Wed, Jun 8, 2016 at 9:21 PM, Ben Greear wrote:
On 06/08/2016 08:46 AM, Prasun Maiti wrote:
Please tell me if I mention that this code is untested in commit log,
then could you check the code kindly and also help
ut even then it needs to be clearly stated in the commit
log that it's untested.
Please resend once you have tested this, I'm dropping this now.
--
Kalle Valo
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
On 05/13/2016 11:21 AM, David Miller wrote:
From: Ben Greear
Date: Fri, 13 May 2016 09:57:19 -0700
How do you feel about a new socket-option to allow a socket to
request the old veth behaviour?
I depend upon the opinions of the experts who work upstream on and
maintain these components
Mr Miller:
How do you feel about a new socket-option to allow a socket to
request the old veth behaviour?
Thanks,
Ben
On 04/30/2016 10:30 PM, Willy Tarreau wrote:
On Sat, Apr 30, 2016 at 03:43:51PM -0700, Ben Greear wrote:
On 04/30/2016 03:01 PM, Vijay Pandurangan wrote:
Consider:
- App A
On 04/30/2016 03:01 PM, Vijay Pandurangan wrote:
On Sat, Apr 30, 2016 at 5:52 PM, Ben Greear wrote:
Good point, so if you had:
eth0 <-> raw <-> user space-bridge <-> raw <-> vethA <-> veth B <->
userspace-stub <->eth1
and user-space hub enabled
On 04/30/2016 02:36 PM, Vijay Pandurangan wrote:
On Sat, Apr 30, 2016 at 5:29 PM, Ben Greear wrote:
On 04/30/2016 02:13 PM, Vijay Pandurangan wrote:
On Sat, Apr 30, 2016 at 4:59 PM, Ben Greear
wrote:
On 04/30/2016 12:54 PM, Tom Herbert wrote:
We've put considerable effort
On 04/30/2016 02:13 PM, Vijay Pandurangan wrote:
On Sat, Apr 30, 2016 at 4:59 PM, Ben Greear wrote:
On 04/30/2016 12:54 PM, Tom Herbert wrote:
We've put considerable effort into cleaning up the checksum interface
to make it as unambiguous as possible, please be very careful to
foll
might want to send raw frames that do have
broken checksums (lets assume a real NIC, not veth), and I want them
to hit the wire with those bad checksums.
How do I configure the checksumming in this case?
Thanks,
Ben
Tom
On Sat, Apr 30, 2016 at 12:40 PM, Ben Greear wrote:
On 04/30/2016
programs would be sufficient I think.
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
On 04/28/2016 03:29 AM, Sabrina Dubroca wrote:
Hello,
2016-04-27, 17:14:44 -0700, Ben Greear wrote:
On 04/27/2016 05:00 PM, Hannes Frederic Sowa wrote:
Hi Ben,
On Wed, Apr 27, 2016, at 20:07, Ben Hutchings wrote:
On Wed, 2016-04-27 at 08:59 -0700, Ben Greear wrote:
On 04/26/2016 04:02 PM
On 04/27/2016 05:00 PM, Hannes Frederic Sowa wrote:
Hi Ben,
On Wed, Apr 27, 2016, at 20:07, Ben Hutchings wrote:
On Wed, 2016-04-27 at 08:59 -0700, Ben Greear wrote:
On 04/26/2016 04:02 PM, Ben Hutchings wrote:
3.2.80-rc1 review patch. If anyone has any objections, please let me know.
I
AL, as that
- will cause bad checksum on forwarded packets */
- if (skb->ip_summed == CHECKSUM_NONE &&
- rcv->features & NETIF_F_RXCSUM)
- skb->ip_summed = CHECKSUM_UNNECESSARY;
length = skb->len;
if (dev_forwar
On 04/12/2016 01:29 PM, Eric Dumazet wrote:
On Tue, 2016-04-12 at 13:23 -0700, Ben Greear wrote:
It worked well enough for years that I didn't even know other algorithms were
available. It was broken around 4.0 time, and I reported it to the list,
and no one seemed to really care enough
On 04/12/2016 01:17 PM, Eric Dumazet wrote:
On Tue, 2016-04-12 at 13:11 -0700, Ben Greear wrote:
On 04/12/2016 12:31 PM, Machani, Yaniv wrote:
On Tue, Apr 12, 2016 at 18:04:52, Ben Greear wrote:
On 04/12/2016 07:52 AM, Eric Dumazet wrote:
On Tue, 2016-04-12 at 12:17 +, Machani, Yaniv
On 04/12/2016 12:31 PM, Machani, Yaniv wrote:
On Tue, Apr 12, 2016 at 18:04:52, Ben Greear wrote:
On 04/12/2016 07:52 AM, Eric Dumazet wrote:
On Tue, 2016-04-12 at 12:17 +, Machani, Yaniv wrote:
If you are using 'Cubic' TCP congestion control, then please try
something dif
found.
If you are using 'Cubic' TCP congestion control, then please try something
different.
It was broken last I checked, at least when used with the ath10k driver.
https://marc.info/?l=linux-netdev&m=144405216005715&w=2
Thanks,
Ben
--
Ben Greear
Candela Tech
hain+0x2e/0x73
[] do_exit+0x224/0x1157
[] ? swapin_walk_pmd_entry+0x1c3/0x1c3
[] ? release_task+0x738/0x738
[] ? SyS_futex+0x152/0x1ee
[] ? do_futex+0xb4d/0xb4d
[] ? mark_held_locks+0x2d/0x90
[] ? lockdep_sys_exit+0x1a/0x91
[] ? lockdep_sys_exit_thunk+0x12/0x14
[] SyS_exit+0x1d/0x1d
[] entry_
that appear
to be hashtable related!
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
On 03/31/2016 12:46 AM, Johannes Berg wrote:
On Wed, 2016-03-30 at 09:52 -0700, Ben Greear wrote:
If someone can fix rhashtable, then great.
I read some earlier comments [1] back when someone else reported
similar problems, and the comments seemed to indicate that rhashtable
was broken in
On 03/30/2016 09:38 AM, David Miller wrote:
From: Johannes Berg
Date: Wed, 30 Mar 2016 11:14:12 +0200
On Tue, 2016-03-29 at 09:16 -0700, Ben Greear wrote:
Looks like rhashtable has too much policy in it to properly deal with
cases where there are too many hash collisions, so I am going to
Looks like rhashtable has too much policy in it to properly deal with
cases where there are too many hash collisions, so I am going to work on
reverting it's use in mac80211.
Thanks,
Ben
On 03/28/2016 01:29 PM, Ben Greear wrote:
Hello!
I have a use case for mac80211 where I create mul
hash to at least function in a linear-search manner.
Any idea what I can do to get rid of the EBUSY return code problem, or how
to debug it further?
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
On 01/12/2015 12:55 PM, Guenter Roeck wrote:
> On Mon, Jan 12, 2015 at 12:08:22PM -0800, Ben Greear wrote:
>>
>> Any idea what is wrong?
>>
>> -rc3 compiled ok, then I rebased just now, and get this:
>>
> My auto-builders are all happy, with no build or qemu fa
s
CC arch/x86/ia32/sys_ia32.o
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.
55049] [] SyS_finit_module+0x75/0xc0
[4.855049] [] ? vm_mmap_pgoff+0x7b/0xa0
[4.855049] [] sysenter_do_call+0x12/0x12
[4.855049] ---[ end trace 9ef1310c3c12d97e ]---
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list:
On 07/24/2014 04:08 PM, Ben Greear wrote:
> A few of our systems are repeatedly crashing when upgraded from
> the 3.14.6+ to 3.14.13+ kernels. Both kernels have a fair bit
> of our out-of-tree patches, so could be our fault.
Ahh, looks like a bad merge of a stable patch with a slightly
31 e4 4d 8b 7e 08 4c 89 e7 49 8b 37 e8 fa ec ff ff
RIP [] anon_vma_clone+0x88/0xf5
RSP
CR2: 003f9840b000
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
Sorry, ...this and previous patch should not have gone to LKML.
Will send it over to ath10k list where it was supposed to go.
Thanks,
Ben
On 05/15/2014 11:31 AM, gree...@candelatech.com wrote:
> From: Ben Greear
>
> When the driver cannot provide proper rssi, mark
>
ice, auto enable
> that mode?
You could just force pktgen to not support multi-skb on vlan interfaces?
I thought we went through this a year or two ago and came up with
something like a 'pktgen-challenged' network interface flag?
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc htt
On 02/26/2014 11:50 AM, Ben Greear wrote:
> This is from the ath10k tree, which was recently rebased on top of
> 3.14.0-rc4.
>
> I'm getting the error below, but I cannot find any reference to 'spinlokk'
> in the source tree. The build tree has two mentions, b
[arch/x86] Error 2
make[1]: *** [sub-make] Error 2
make: *** [all] Error 2
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kern
On 12/31/2013 08:09 AM, Julia Lawall wrote:
On Tue, 31 Dec 2013, Ben Greear wrote:
On 12/30/2013 10:32 PM, Julia Lawall wrote:
I'm just thinking of a programmer, e.g. changing a struct like this:
struct foo {
u8 addr[ETH_ALEN];
- u16 dummy;
};
I don't know of a wa
er.kernel.org/majordomo-info.html
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majord
On 11/06/2013 03:52 AM, Clemens Ladisch wrote:
> Ben Greear wrote:
>> Similarly named methods elsewhere seem to indicate it is supposed to be
>> ones-based counting (ie, bit (1<<0) would be considred 'bit 1'.
>
> ffs() is defined to use one-based counting:
&g
Similarly named methods elsewhere seem to indicate it is supposed to be
ones-based counting (ie, bit (1<<0) would be considred 'bit 1'.
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubsc
Seems there is a 64-bit division in there somewhere.
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
On 06/29/2013 09:26 AM, Eric Dumazet wrote:
On Sat, 2013-06-29 at 09:11 -0700, Ben Greear wrote:
Do you know if your patch should go in 3.9?
Yes it should.
Ok, I'll add that to my tree.
Your test case sounds a bit like what gives us the rare crash in tcp_collapse
(we have lo
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FA
On 06/13/2013 08:50 AM, Catalin Marinas wrote:
On Wed, Jun 12, 2013 at 01:28:13AM +0100, Ben Greear wrote:
On 06/11/2013 12:52 PM, Ben Greear wrote:
On 06/10/2013 03:32 PM, Catalin Marinas wrote:
On 10 June 2013 19:22, Ben Greear wrote:
We had a system go OOM while doing lots of wireless
managed to go through this
code within a single RCU period?
I think that if the rcu_assign_pointer logic wasn't 'published'
before a second thread came through this logic it could cause
this leakage?
The actual code I'm curious about is in net/mac80211/scan.c, in
the cfg80211_bss_
On 06/11/2013 12:52 PM, Ben Greear wrote:
On 06/10/2013 03:32 PM, Catalin Marinas wrote:
On 10 June 2013 19:22, Ben Greear wrote:
We had a system go OOM while doing lots of wireless
stations. (System had 8GB of RAM, so I suspect a leak).
I enabled kmemleak in a 3.9.5 (plus some local
On 06/10/2013 03:32 PM, Catalin Marinas wrote:
On 10 June 2013 19:22, Ben Greear wrote:
We had a system go OOM while doing lots of wireless
stations. (System had 8GB of RAM, so I suspect a leak).
I enabled kmemleak in a 3.9.5 (plus some local patches) and
I see the entries below. Any idea
On 06/10/2013 03:32 PM, Catalin Marinas wrote:
On 10 June 2013 19:22, Ben Greear wrote:
We had a system go OOM while doing lots of wireless
stations. (System had 8GB of RAM, so I suspect a leak).
I enabled kmemleak in a 3.9.5 (plus some local patches) and
I see the entries below. Any idea
_call_rcu.clone.1+0x58/0x22a
[] call_rcu+0x17/0x19
[] put_object+0x46/0x4a
[] delete_object_full+0x2d/0x32
[] kmemleak_free+0x59/0x7a
[] slab_free_hook+0x21/0x87
[] kmem_cache_free+0xbe/0x15d
[] final_putname+0x38/0x3c
--
Ben Greear
Candela Technologies Inc http://www.c
On 06/06/2013 02:40 PM, Tejun Heo wrote:
On Thu, Jun 06, 2013 at 02:29:49PM -0700, gree...@candelatech.com wrote:
From: Ben Greear
The stop machine logic can lock up if all but one of
the migration threads make it through the disable-irq
step and the one remaining thread gets stuck in
t to add a link to the email thread.. The commit message
and patch has enough info that I think an interested party could find
the email thread easily enough if they needed more history.
And, much of the email thread is me running in circles thinking
I am going insane :)
Thanks,
Ben
--
Ben
On 06/06/2013 01:55 PM, Tejun Heo wrote:
Hello, Ben.
On Wed, Jun 05, 2013 at 08:41:01PM -0700, Ben Greear wrote:
On 06/05/2013 08:26 PM, Eric Dumazet wrote:
On Wed, 2013-06-05 at 20:14 -0700, Tejun Heo wrote:
Ah, so, that's why it's showing up now. We probably have had the same
On 06/05/2013 08:46 PM, Eric Dumazet wrote:
On Wed, 2013-06-05 at 20:41 -0700, Ben Greear wrote:
On 06/05/2013 08:26 PM, Eric Dumazet wrote:
On Wed, 2013-06-05 at 20:14 -0700, Tejun Heo wrote:
Ah, so, that's why it's showing up now. We probably have had the same
issue all along b
nough if we can agree on the max
number of
loops (and if indeed my version of the patch is acceptable).
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On 06/05/2013 02:11 PM, Tejun Heo wrote:
(cc'ing wireless crowd, tglx and Ingo. The original thread is at
http://thread.gmane.org/gmane.linux.kernel/1500158/focus=55005 )
Hello, Ben.
On Wed, Jun 05, 2013 at 01:58:31PM -0700, Ben Greear wrote:
Hmm, wonder if I found it. I previousl
On 06/05/2013 12:31 PM, Ben Greear wrote:
This is no longer really about the module unlink, so changing
subject.
On 06/05/2013 12:11 PM, Ben Greear wrote:
On 06/05/2013 11:48 AM, Tejun Heo wrote:
Hello, Ben.
On Wed, Jun 05, 2013 at 09:59:00AM -0700, Ben Greear wrote:
One pattern I notice
This is no longer really about the module unlink, so changing
subject.
On 06/05/2013 12:11 PM, Ben Greear wrote:
On 06/05/2013 11:48 AM, Tejun Heo wrote:
Hello, Ben.
On Wed, Jun 05, 2013 at 09:59:00AM -0700, Ben Greear wrote:
One pattern I notice repeating for at least most of the hangs is
On 06/05/2013 11:48 AM, Tejun Heo wrote:
Hello, Ben.
On Wed, Jun 05, 2013 at 09:59:00AM -0700, Ben Greear wrote:
One pattern I notice repeating for at least most of the hangs is that all but
one
CPU thread has irqs disabled and is in state 2. But, there will be one thread
in state 1 that
On 06/04/2013 09:41 PM, Rusty Russell wrote:
Ben Greear writes:
On 06/04/2013 02:18 PM, Ben Greear wrote:
I've been trying to figure out why I see the migration/* processes
hang in a busy loop
While reading the stop_machine.c file, I think I might have an
answer.
The set_state() m
On 06/04/2013 02:18 PM, Ben Greear wrote:
I've been trying to figure out why I see the migration/* processes
hang in a busy loop
While reading the stop_machine.c file, I think I might have an
answer.
The set_state() method sets the thread_ack to the current number
of threads.
op forever.
Does this make sense?
Any ideas on how to fix this properly?
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Mo
On 06/04/2013 09:53 AM, Ben Greear wrote:
On 06/04/2013 07:07 AM, Joe Lawrence wrote:
On Tue, 04 Jun 2013 15:26:28 +0930
Rusty Russell wrote:
Do you have a backtrace of the 3.9.4 crash? You can add "CFLAGS_module.o
= -O0" to get a clearer backtrace if you want...
Hi Rusty,
ut the atomic thread counter sits at 1, so no progress is ever made.
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg443471.html
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On 06/03/2013 08:59 AM, Ben Greear wrote:
On 06/03/2013 07:17 AM, Joe Lawrence wrote:
Hi Rusty,
I had pointed Ben (offlist) to that bugzilla entry without realizing
there were other earlier related fixes in this space. Re-viewing bz-
58011, it looks like it was opened against 3.8.12, while
) related lockup still exists in 3.9.4 for me,
so I will also try applying that other kobject patch and continue testing
today...
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
On 05/31/2013 02:40 PM, Ben Greear wrote:
On 05/31/2013 12:22 PM, Ben Greear wrote:
While trying to verify that the kobject patch
(see "Please add to stable: module: don't unlink the module until we've removed all
exposure." email)
fixed the problems I was seeing, I hit
On 05/31/2013 12:22 PM, Ben Greear wrote:
While trying to verify that the kobject patch
(see "Please add to stable: module: don't unlink the module until we've removed all
exposure." email)
fixed the problems I was seeing, I hit what I believe is a different problem.
Much
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
On 05/30/2013 12:39 PM, Ben Greear wrote:
I'm seeing a crash (on hacked 3.9.3+ kernels). It's rare, but in a kernel
larded down with debugging, we are having some luck reproducing it.
Please note, this kernel is running a fair amount of my patches, so it could
be my bug. We did no
t(kobj);
err = -EINVAL;
goto out;
}
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo i
On 05/28/2013 09:15 AM, Rafael Aquini wrote:
On Tue, May 28, 2013 at 09:00:45AM -0700, Ben Greear wrote:
On 05/27/2013 03:41 PM, Francois Romieu wrote:
atom...@redhat.com :
[...]
Failed GFP_ATOMIC allocations by the network stack result in dropped
packets, which will be received on a
just because some shit ends in your backyard.
We should rate-limit these messages at least. When a system is low on memory
the logs can quickly fill up with useless OOM messages, further slowing
the system...
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
pus with NMI
drm_kms_helper: panic occurred, switching back to text console
Rebooting in 10 seconds..
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.ker
On 05/08/2013 01:35 PM, Al Viro wrote:
On Wed, May 08, 2013 at 01:32:06PM -0700, Ben Greear wrote:
I'm seeing a crash when unloading the ath9k module.
It seems relay_close() is being passed bad memory.
The relay_open call uses an ath9k debugfs directory, so
that may be removed before the
ry is removed?
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 04/10/2013 11:05 AM, Luis R. Rodriguez wrote:
On Wed, Apr 10, 2013 at 10:59 AM, Ben Greear wrote:
On 04/10/2013 10:55 AM, Luis R. Rodriguez wrote:
Curious if anyone has worked on latency and jitter benchmarks in using
netlink, specifically with nl80211. Has anyone benchmarked this? Ben
1 - 100 of 251 matches
Mail list logo
