>
> > I started a loop for test, doing cat /proc/net/dev in a loop and at
> the
> > same link link up and down from console, but up and down is slow
> process
> > and the loop did not seem to trigger the warning over night, so it was
>
ss
> and the loop did not seem to trigger the warning over night, so it was
> not so simple.
>
I am busy with other priority tasks. One of my colleague Deepak will
work this with you.
I added him to CC list.
Thanks.
>
>> > > [ 83.716570] BUG: spinlock lockup
ASF[0] TSOcap[1]
>>> > > [ 75.184557] tg3 0000:00:02.1 eth1: dma_rwctrl[763f]
>>> > > dma_mask[32-bit]
>>> > > [ 75.184708] PCI: Enabling device: (0003:00:02.0), cmd 2
>>> > > [ 75.375322] tg3 0003:00:02.0 (unnamed net_dev
Enabling device: (0003:00:02.0), cmd 2
>> > > [ 75.375322] tg3 0003:00:02.0 (unnamed net_device) (uninitialized):
>> > > Cannot get nvram lock, tg3_nvram_init failed
>> > > [ 75.714681] tg3 0003:00:02.0 eth2: Tigon3 [partno(none) rev 2003]
eth2: attached PHY is 5704
> > > (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
> > > [ 75.714694] tg3 0003:00:02.0 eth2: RXcsums[1] LinkChgREG[0] MIirq[0]
> > > ASF[0] TSOcap[1]
> > > [ 75.714699] tg3 0003:00:02.0 eth2: dma_rwctrl[763f]
> > > d
> On Sat, Oct 8, 2016 at 10:15 PM, Meelis Roos wrote:
> >> That did not go well - bisect found the following commit but that does
> >> not seem to be related at all. So probably the reproducibility is not
> >> 100% but more random.
> >
> > Now I reproduced the bug even with 4.7-rc1 so it is older
ttached PHY is 5704
>> > (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
>> > [ 75.714694] tg3 0003:00:02.0 eth2: RXcsums[1] LinkChgREG[0] MIirq[0]
>> > ASF[0] TSOcap[1]
>> > [ 75.714699] tg3 0003:00:02.0 eth2: dma_rwctrl[763f] dma_mask[32-bit]
>>
it]
> > [ 75.714819] PCI: Enabling device: (0003:00:02.1), cmd 2
> > [ 75.905278] tg3 0003:00:02.1 (unnamed net_device) (uninitialized):
> > Cannot get nvram lock, tg3_nvram_init failed
> > [ 76.244470] tg3 0003:00:02.1 eth3: Tigon3 [partno(none) rev 2003]
> >
76.244482] tg3 0003:00:02.1 eth3: RXcsums[1] LinkChgREG[0] MIirq[0]
> ASF[0] TSOcap[1]
> [ 76.244488] tg3 0003:00:02.1 eth3: dma_rwctrl[763f] dma_mask[32-bit]
> [ 83.643317] tg3 :00:02.0 eth0: No firmware running
> [...]
> [ 83.716570] BUG: spinlock lockup suspected o
On 05/30/2014 01:24 PM, Jan Kara wrote:
> Now with the attachment... :)
Jan, I suspect that the issue Jet has reported is different from mine.
Your patch (or even removing all of print_PIC() didn't solve the issue
I've reported.
Thanks,
Sasha
--
To unsubscribe from this list: send the line "u
Now with the attachment... :)
On Fri 30-05-14 19:23:27, Jan Kara wrote:
> On Fri 30-05-14 18:58:10, Jan Kara wrote:
> > On Fri 30-05-14 18:19:48, Peter Zijlstra wrote:
> > > On Fri, May 30, 2014 at 06:16:47PM +0200, Peter Zijlstra wrote:
> > > > On Fri, May 30, 2014 at 05:50:51PM +0200, Jan Kara
On Fri 30-05-14 18:58:10, Jan Kara wrote:
> On Fri 30-05-14 18:19:48, Peter Zijlstra wrote:
> > On Fri, May 30, 2014 at 06:16:47PM +0200, Peter Zijlstra wrote:
> > > On Fri, May 30, 2014 at 05:50:51PM +0200, Jan Kara wrote:
> > > > > [7.492350] ==
On Fri 30-05-14 18:19:48, Peter Zijlstra wrote:
> On Fri, May 30, 2014 at 06:16:47PM +0200, Peter Zijlstra wrote:
> > On Fri, May 30, 2014 at 05:50:51PM +0200, Jan Kara wrote:
> > > > [7.492350] ==
> > > > [7.492350] [ INFO: possible circu
On Fri, May 30, 2014 at 06:16:47PM +0200, Peter Zijlstra wrote:
> On Fri, May 30, 2014 at 05:50:51PM +0200, Jan Kara wrote:
> > > [7.492350] ==
> > > [7.492350] [ INFO: possible circular locking dependency detected ]
> > > [7.492350] 3
On Fri, May 30, 2014 at 05:50:51PM +0200, Jan Kara wrote:
> > [7.492350] ==
> > [7.492350] [ INFO: possible circular locking dependency detected ]
> > [7.492350] 3.15.0-rc5-00567-gbafe980 #1 Not tainted
> > [7.492350] -
Dear Will,
Thanks for your input. We debug by adding print as below and found
very big value difference between next and owner(more then 1000). So
it seams memory corruption.
linux/lib/spinlock_debug.c
msg, raw_smp_processor_id(),
current->comm, task_pid_nr(cur
On Tue, Jan 21, 2014 at 06:37:31AM +, naveen yadav wrote:
> Thanks for your reply,
>
> We are using Cortex A15.
> yes, this is with ticket lock.
>
> We will check value of arch_spinlock_t and share it. It is bit
> difficult to reproduce this scenario.
>
> If you have some idea ,please sugge
, Will Deacon wrote:
> On Sat, Jan 18, 2014 at 07:25:51AM +, naveen yadav wrote:
>> We are using 3.8.x kernel on ARM, We are facing soft lockup issue.
>> Following are the logs.
>
> Which CPU/SoC are you using?
>
>> BUG: spinlock lockup suspected on CPU#0, pr
On Sat, Jan 18, 2014 at 07:25:51AM +, naveen yadav wrote:
> We are using 3.8.x kernel on ARM, We are facing soft lockup issue.
> Following are the logs.
Which CPU/SoC are you using?
> BUG: spinlock lockup suspected on CPU#0, process1/525
> lock: 0xd8ac9a64, .magic: dead4ead,
Dear All,
We are using 3.8.x kernel on ARM, We are facing soft lockup issue.
Following are the logs.
BUG: spinlock lockup suspected on CPU#0, process1/525
lock: 0xd8ac9a64, .magic: dead4ead, .owner: /-1, .owner_cpu: -1
1 . Looks like lock is available as owner is -1, why arch_spin_trylock
is
Hi
On Tue, Jan 14, 2014 at 2:45 PM, Fengguang Wu wrote:
> Hi David,
>
> I'm not sure if this is a good bisect because the errors are noisy,
> however it's good to inform you of this possibility.
>
> First bad commit may be a3483353c ("drm: check for !kdev in
> drm_unplug_minor()")
To be honest,
On Fri, 2013-04-26 at 15:08 +0100, Mark Jackson wrote:
> I've encountered a lockup on ubifs ... any ideas ?
>
> # ifup eth1
> [ 3451.254040] Unable to handle kernel NULL pointer dereference at virtual
> address
> [ 3451.262627] pgd = cf468000
> [ 3451.265489] [] *pgd=8f48c831, *p
I've got several systems with similar hardware which crash with BUG:
spinlock errors on async_umap_flush_lock such as:
BUG: spinlock lockup suspected on CPU#0, sh/1166
lock: async_umap_flush_lock+0x0/0x20, .magic: dead4ead, .owner: swapper/23/0,
.owner_cpu: 23
BUG: spinlock lockup suspect
3451.496127] [] (pagevec_lru_move_fn+0x90/0xe4) from []
(0xcf481808)
[ 3485.901588] BUG: spinlock lockup suspected on CPU#0, flush-ubifs_0_0/844
[ 3485.908722] lock: contig_page_data+0x214/0x9c4, .magic: dead4ead, .owner:
sh/913, .owner_cpu: 0
[ 3485.918048] [] (unwind_backtrace+0x0/0x138) from []
(do_ra
Jarek Poplawski wrote, On 02/15/2008 10:03 PM:
...
> ...On the other hand this:
>
>> Feb 15 15:50:17 217.151.X.X [1521315.068984] BUG: spinlock lockup on CPU#1,
>> ksoftirqd/1/7, f0551180
>
> seems to point just at spinlock lockup, so it's more about the full rep
u could try with some other debugging options? E.g. since lockdep
> doesn't help - turn this off. Instead try some others, like these:
...On the other hand this:
> Feb 15 15:50:17 217.151.X.X [1521315.068984] BUG: spinlock lockup on CPU#1,
> ksoftirqd/1/7, f0551180
seems to point just a
Denys Fedoryshchenko wrote, On 02/15/2008 08:42 PM:
...
> I have similar crashes on completely different hardware with same job (QOS),
> so i think it is actually some nasty bug in networking.
Maybe you could try with some other debugging options? E.g. since lockdep
doesn't help - turn this off.
This server was working fine under load under FreeBSD, and worked fine before
with other tasks under Linux. I dont think it is RAM.
Additionally it is server hardware (Dell PowerEdge) with ECC, MCE and other
layers, who will report about any hardware issue most probably, and i think
even better
2008/2/15 Denys Fedoryshchenko <[EMAIL PROTECTED]>:
> I have random crashes, at least once per week. It is very difficult to catch
> error message, and only recently i setup netconsole. Now i got crash, but
> there is no traceback and only single line came over netconsole, mentioned
> before.
Server crashed(not responding over network), last line over netconsole was
Feb 15 15:50:17 217.151.X.X [1521315.068984] BUG: spinlock lockup on CPU#1,
ksoftirqd/1/7, f0551180
I have random crashes, at least once per week. It is very difficult to catch
error message, and only recently i setup
30 matches
Mail list logo
