> 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
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
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
On Thu, 21 Sep 2000 00:05:03 +1100,
Andrew Morton <[EMAIL PROTECTED]> wrote:
>> The downside of this optimization is that all code that is waiting for
>> a lock appears to be in the out of line section and the only label in
>> that section is right at the start. So all lock code appears to be
Keith Owens wrote:
>
> Just because the traces end up in stext_lock does not mean that they
> are the same bug. Locks are optimized for pipeline performance, the
> code for "got the lock" is in the main text section, the code for
> "cannot get lock, need to wait" is moved to a separate text
Keith Owens wrote:
Just because the traces end up in stext_lock does not mean that they
are the same bug. Locks are optimized for pipeline performance, the
code for "got the lock" is in the main text section, the code for
"cannot get lock, need to wait" is moved to a separate text section.
On Thu, 21 Sep 2000 00:05:03 +1100,
Andrew Morton [EMAIL PROTECTED] wrote:
The downside of this optimization is that all code that is waiting for
a lock appears to be in the out of line section and the only label in
that section is right at the start. So all lock code appears to be in
Keith Owens wrote:
...
Waiting on spinlock! Spinner's EIP is [c0130d7a]
...
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
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 from
- 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: NMI Watchdog detecte
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
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
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>:
Hello, using 2.4.0-test9-pre2 and thinking that there are no major bugs
I found this again, I have observed what I think it's the same bug since
2.4.0-test7.
All the traces end up in stext_lock, so I think it' the same bug, this
time it happened when I was about to use the iomega parport zip
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 stext_lock+32ba/7f30 =
Trace; c015db32 generic_make_request+ce/120
Trace; c015dd03 ll_rw_block+17f/1f4
Trace; c0136149
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
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
- 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: NMI Watchdog detected LOCKUP on CPU1
(stext_lock)(2.4.0-test9-pre2)
19 matches
Mail list logo
