7981: cpu0 unhandled wrmsr: 0x198 data 0
kvm: 17981: cpu1 unhandled wrmsr: 0x198 data 0
BUG: NMI Watchdog detected LOCKUP on CPU19, ip 814c5aee, registers:
CPU 19
Modules linked in: act_police cls_u32 sch_ingress sch_htb ip6_tables
iptable_filter ip_tables ebtable_nat ebtables stp llc openvswi
On Sat, Sep 22, 2007 at 10:35:45PM -0700, Andrew Morton wrote:
> On Sun, 23 Sep 2007 13:30:40 +0800 Fengguang Wu <[EMAIL PROTECTED]> wrote:
>
> > > That's interensting. serial_in(). We have had NMI watchdog expiries when
> > > the kernel is printing a large amount of stuff out a slow serial port
On Sun, 23 Sep 2007 13:30:40 +0800 Fengguang Wu <[EMAIL PROTECTED]> wrote:
> > That's interensting. serial_in(). We have had NMI watchdog expiries when
> > the kernel is printing a large amount of stuff out a slow serial port with
> > interrutps disabled. But I thought we'd pretty much plugged
l/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/
> > >
> > > 2.6.23-rc6-mm1 is a 29MB diff against 2.6.23-rc6.
> >
> >
> > This bug appears in 2.6.23-rc3-mm1, too.
>
> hm, there isn't much info here.
>
> > The message:
> >
&g
is a 29MB diff against 2.6.23-rc6.
>
>
> This bug appears in 2.6.23-rc3-mm1, too.
hm, there isn't much info here.
> The message:
>
> [ 3267.844826] NMI Watchdog detected LOCKUP on CPU 0
> [ 3267.849515] CPU 0
> [ 3267.851525] Modules linked in: binfmt_misc
st 2.6.23-rc6.
>
>
> This bug appears in 2.6.23-rc3-mm1, too.
>
> The message:
>
> [ 3267.844826] NMI Watchdog detected LOCKUP on CPU 0
> [ 3267.849515] CPU 0
> [ 3267.851525] Modules linked in: binfmt_misc ipt_MASQUERADE iptable_mangle
> iptable_nat nf_con
Chuck Ebbert wrote:
> Michal Piotrowski wrote:
>
>> Hi,
>>
>> / filesystem was full
>>
>> [39525.460000] BUG: NMI Watchdog detected LOCKUP on CPU1, eip 08056990,
>> registers:
>> [39525.468000] Modules linked in: loop ipt_MAS
On Tue, 8 May 2007, Andrew Morton wrote:
> happens when a local process sends packets with invalid IP headers
> through raw sockets.
[...]
> Whatever happens, that printk should be toned down, shouldn't it? We
> prefer to not let unprivileged apps spam the logs.
Isn't "unprivileged app sendi
Michal Piotrowski wrote:
> Hi,
>
> / filesystem was full
>
> [39525.46] BUG: NMI Watchdog detected LOCKUP on CPU1, eip 08056990,
> registers:
> [39525.468000] Modules linked in: loop ipt_MASQUERADE iptable_nat nf_nat
> autofs4 af_packet nf_conntrack_netbios_ns ipt_
On 08/05/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
On Tue, 08 May 2007 10:35:14 +0200 Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> Hi,
>
> / filesystem was full
>
> [39525.46] BUG: NMI Watchdog detected LOCKUP on CPU1, eip 08056990,
registers:
> [39525.4
Andrew Morton wrote:
> Whatever happens, that printk should be toned down, shouldn't it? We
> prefer to not let unprivileged apps spam the logs.
Only priviledged apps can send these packets. I've never seen it in
practice except for one case that was a bug in the network stack, so
I'd prefer to
On Tue, 08 May 2007 10:35:14 +0200 Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> Hi,
>
> / filesystem was full
>
> [39525.460000] BUG: NMI Watchdog detected LOCKUP on CPU1, eip 08056990,
> registers:
> [39525.468000] Modules linked in: loop ipt_MASQUERADE ip
Hi,
/ filesystem was full
[39525.46] BUG: NMI Watchdog detected LOCKUP on CPU1, eip 08056990,
registers:
[39525.468000] Modules linked in: loop ipt_MASQUERADE iptable_nat nf_nat
autofs4 af_packet nf_conntrack_netbios_ns ipt_REJECT nf_conntrack_ipv4 xt_state
nf_conntrack nfnetlink
Hi,
One of my NFS servers just blew up on me. I found the following in the log -
hope it is useful :
NMI Watchdog detected LOCKUP on CPU 1
CPU 1
Modules linked in: sg eeprom i2c_i801
Pid: 284, comm: scsi_eh_2 Not tainted 2.6.18.1 #1
RIP: 0010:[] [] __delay+0xa/0x20
RSP: :81022fbf5d80
On Thu, 2006-12-14 at 22:59 -0800, Tilman Schmidt wrote:
> [] rb_insert_color+0x55/0xbe
> [] enqueue_hrtimer+0x10a/0x116
> [] hrtimer_start+0x78/0x93
> [] get_signal_to_deliver+0xf3/0x74e
> [] do_notify_resume+0x93/0x655
> [] work_notifysig+0x13/0x1a
> [] 0xb7f5f410
Not really helpful.
> C
as able to collect this BUG message (copied manually,
beware of typos):
BUG: NMI Watchdog detected LOCKUP on CPU0, eip c021cf4d, registers:
Modules linked in: xt_pkttype ipt_LOG xt_limit usbserial snd_rtctimer
snd_seq_dummy snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device thermal
processor fan butt
moops 2.3.4 on i686 2.4.0-ac9. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.0-ac9/ (default)
-m /boot/System.map-2.4.0-ac9 (specified)
NMI Watchdog detected LOCKUP on CPU0, registers:
CPU:0
EIP:0010:[]
Using defaults
This morning my dual P2/300 with 320MB memory gave me:
NMI Watchdog detected LOCKUP on CPU0, registers:
CPU:0
EPI:0023:[<08076580>]
EFLAGS: 0292
eax: fb54ba8e ebx: bba692c5 ecx: b6fb4d53 edx: 562a18f5
esi: 216266e2 edi: 92811b25 ebp: 27cd9569 esp: 080f0148
ds: 002
> Yes, SYSRQ+P should definetly show the stack trace.
And on SMP it would be nice to backtrace all cpus. (perhaps make this
another sysrq option)
Anton
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at
On Thu, Sep 21, 2000 at 12:42:25AM +1100, Andrew Morton wrote:
> What about the ALT-SYSRQ-P thing? I guess that wouldn't be necessary if
> handle_sysrq() did a show_stack(0), which it doesn't, and probably
> should.
Yes, SYSRQ+P should definetly show the stack trace.
Andrea
-
To unsubscribe fro
Keith Owens wrote:
>
> ...
> > Waiting on spinlock! Spinner's EIP is []
> > ...
>
> Is the extra code worth it? The ix86 oops dump runs the stack printing
> anything that looks like a kernel address.
Fair enough.
What about the ALT-SYSRQ-P thing? I guess that wouldn't be necessary
ou have to do is work out who is holding
>> onto io_request_lock.
>
>What do you think of this addition to the x86 debug code, Keith:
>
>If you get an NMI oops it says:
>
> NMI Watchdog detected LOCKUP on CPU1, registers:
> CPU:1
> EIP:
s work out who is holding
> onto io_request_lock.
What do you think of this addition to the x86 debug code, Keith:
If you get an NMI oops it says:
NMI Watchdog detected LOCKUP on CPU1, registers:
CPU:1
EIP:0010:[]
EFLAGS: 0086
Waitin
about...
:-)
Jeff
- Original Message -
From: "David S. Miller" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Tuesday, September 19, 2000 7:41 PM
Subject: Re:
Date:Tue, 19 Sep 2000 19:44:30 -0600
From: "Jeff V. Merkey" <[EMAIL PROTECTED]>
It does not seem to be saving any memory space doing it this way,
since I've noticed tons of these little segments all over the
place.
None of them can be eliminated because each one branches b
Keith,
I've seen a some problems with the way Linus (or whoever) did this. I
had a bug I worked on for 5 weeks related to the buggy 2.7 gcc linker on
Caldera Linux 2.4 that would for whatever reason fail to fixup all the
.test.lock code sections in a file (probably because there were so many
of
On Tue, 19 Sep 2000 19:53:19 +0200,
Jorge Nerin <[EMAIL PROTECTED]> wrote:
>All the traces end up in stext_lock, so I think it' the same bug
>>>EIP; c01df3aa<=
>Trace; c015db32
>Trace; c015dd03
>Trace; c0136149
>Trace; c01363fd
>Trace; c01079bb
>Code; c01df3aa
> <_EIP>:
>Co
test9-pre2/ (default)
-m /boot/System.map-2.4.0-test9-pre2 (specified)
cpu: 0, clocks: 668188, slice: 222729
cpu: 1, clocks: 668188, slice: 222729
NMI Watchdog detected LOCKUP on CPU1, registers:
CPU:1
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 0082
eax:
28 matches
Mail list logo
