> 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
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:
>
> 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 sect
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
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 with
10 matches
Mail list logo
