* [parisc-linux] 2.4.6-pa5 crashes on B160L
@ 2001-07-08 15:21 Scott Ashcroft
2001-07-08 21:10 ` Matthew Wilcox
0 siblings, 1 reply; 7+ messages in thread
From: Scott Ashcroft @ 2001-07-08 15:21 UTC (permalink / raw)
To: parisc-linux
2.4.0-pa51 boots fine. 2.4.6-pa5 goes:
Dumping Stack from 10554000 to 10554840:
4000 00000000 00000040 00000000 00000000 102833a0 00000000 00000000
ffffffff
4020 00000003 00000000 00000000 00000000 00000000 00000000 ffffffff
102832a0
4040 102832a0 0000001f 10548000 102cc000 10289600 00000000 00000000
00000000
4060 00000000 00000000 00000000 00000001 00000000 00000000 00000000
00000000
4080 00000000 102cc000 102cc000 10074000 00000000 00000000 10074098
102cc098
40a0 00000000 102ea01c 105540a8 105540a8 10554808 00000000 00000000
00000000
40c0 00000000 00000000 00000000 00000000 00000000 00000000 00000000
10554000
40e0 10119f98 00000000 00000001 00000000 00000000 0000001e 00000000
0000001f
4100 00000000 00000000 00000000 00000000 00000000 00000000 80000000
00000000
4120 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
4140 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
4160 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
4180 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
41a0 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
41c0 fffffeff 00000000 ffffffff 00000000 10283f64 ffffffff ffffffff
ffffffff
41e0 ffffffff ffffffff ffffffff 00800000 05000000 00000000 ffffffff
ffffffff
4200 ffffffff 000007bb 000007bb 00000400 00000400 ffffffff ffffffff
ffffffff
4220 ffffffff ffffffff ffffffff 00007377 61707065 72000000 00000000
00000000
4240 00000000 00000000 00000000 00000000 00000000 00000000 f0000c30
f0100000
4260 000000fd 00000001 00000001 1029ccd4 0004000e 0000004d 0000004e
f000a37c
4280 00043002 0006e000 00007bbb 00800327 00000000 00000000 00007bbb
00800327
42a0 00007bbb 10284810 00000001 1055cba0 102465bc 0004000e 0000004d
00000000
42c0 10100130 10118414 00000000 00007bbb 00800327 f0100000 102d3667
0000004d
42e0 00000024 0000003c 0000003e 10283010 00000001 102d3667 f000a37c
102d3643
4300 102d3643 00007bbb 00000002 0000001d 00007bbb 102d7810 102dc044
00000001
4320 1025b278 0006e000 f000a37c 00043002 0006e000 00007bbb 00008124
102d3643
4340 102d3643 101581a4 0000001d 00000800 00007bbb f0100000 00000003
00000000
4360 102cc554 1025b464 00000000 1030d0c0 00000020 10284438 00000005
10284010
4380 1028443c 101581a4 00000018 000000c0 102cc840 1012d4ac 00000003
00000000
43a0 102cc594 1025b270 00000000 1030de40 00000020 10284438 00000002
10284010
43c0 1028443c 10157c00 00000000 00000000 00000000 00000000 0000004e
00008124
43e0 00000001 102cc594 000000f0 1030d240 00000000 10037000 1055e040
f0000174
4400 f0000c30 10131fb0 0000000f 00000001 00000001 10554740 10105cf8
00000001
4420 000000f0 00043002 000000f0 1030d0c0 0028a000 00000000 10289040
10289060
4440 102891fc 00000000 00000000 00000000 1055444c 00000000 00000000
00000000
4460 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
4480 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
44a0 00000000 00000000 00000000 10105c4c 00000000 00000000 00000000
00000000
44c0 102cc000 00000000 aaaaaaaa 00000000 00000000 00000000 00000000
00000000
44e0 00000000 00000000 00000000 10100144 00000000 00000000 00000000
00000000
4500 00000000 aaaaaaaa 00000000 00000000 00000000 00000000 00000000
00000000
4520 00000000 00000000 00000000 1029ce6c 00000000 00000000 00000000
00000000
4540 102e9810 10554000 10289600 102cc000 102c955c 102c9520 00000000
1055454c
4560 1055454c 00000000 102c955c 102a3258 00000000 00000000 00000000
00000000
4580 102c955c 1029ccd4 0004000e 0000004d 102e9810 10284ee4 10289600
102cc000
45a0 102c955c 102c9518 10554000 102a4e8c 102cc000 102c955c 102c94e8
00000000
45c0 102916fc 00000040 102e4404 102e4348 102916fc 00000040 1025cff8
1025d274
45e0 102e3010 102e3010 102c9518 102a4980 102cc000 102c955c 102c9508
10554548
4600 0004fe0f 10294810 102a4980 10291010 102917c4 102e4348 102e4404
10000080
4620 1028e748 0000004d 0004000e 1029ccd4 00000001 00000001 000000fd
f0100000
4640 f0000c30 f0000174 00000020 1025d080 1028d26c 10294cf4 10294810
00000002
4660 102659e8 102954c8 102917c4 1026e010 00000000 102e9810 10554840
102d7810
4680 000f0800 00000000 0000001f 00000000 0000001f 00000000 0000001f
00000000
46a0 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
46c0 00000010 00000020 7f7fffff ffffffff 43ebebeb e0000000 00000000
00000000
46e0 45e69c6a 25b7ea20 41800000 00000000 00000010 00000010 00000000
00000000
4700 00000040 00000080 00000100 00000200 00000400 00000800 7fffffff
7fffffff
4720 41000000 00000000 7fffffff 7fffffff 40800000 00000000 41000000
00000000
4740 40300000 00000000 40200000 00000000 40200000 00000000 41800000
7fffffff
4760 40000000 00000000 40000000 00000000 40800000 00000000 41000000
00000000
4780 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
47a0 00000000 00000000 102a4990 102a4994 f0102918 00000000 0004000e
0000004d
47c0 102d366e 0000001f 0e601200 00000000 1025d080 10283010 00000001
102d366e
47e0 102ed5a0 102d3646 102d3643 101bad34 0000000f 00000001 00000001
1029ccd4
4800 00000002 ffffffff ffffffff 0000000a 00000020 00000000 1026ceac
105547c9
4820 00000020 f0000174 f0000c30 10106748 0000000f 00000001 00000001
1029ccd4
Kernel Fault: Code=26 regs=10554600 (Addr=1025d080)
YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001111111000001111
r0-3 00000000 10294810 102a4980 10291010
r4-7 102917c4 102e4348 102e4404 10000080
r8-11 1028e748 0000004d 0004000e 1029ccd4
r12-15 00000001 00000001 000000fd f0100000
r16-19 f0000c30 f0000174 00000020 1025d080
r20-23 1028d26c 10294cf4 10294810 00000002
r24-27 102659e8 102954c8 102917c4 1026e010
r28-31 00000000 102e9810 10554840 102d7810
sr0-3 00000000 00000000 00000000 00000000
sr4-7 00000000 00000000 00000000 00000000
IASQ: 00000000 00000000 IAOQ: 102a4990 102a4994
IIR: 0e601200 ISR: 00000000 IOR: 1025d080
ORIG_R28: 0004000e
What else is needed to debug this? Is there a ksymoops equivalent?
I can supply .config, System.map on request.
Cheers,
Scott
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [parisc-linux] 2.4.6-pa5 crashes on B160L
2001-07-08 15:21 [parisc-linux] 2.4.6-pa5 crashes on B160L Scott Ashcroft
@ 2001-07-08 21:10 ` Matthew Wilcox
2001-07-08 23:31 ` Grant Grundler
2001-07-09 1:41 ` [parisc-linux] 2.4.6-pa5 crashes on B160L Scott Ashcroft
0 siblings, 2 replies; 7+ messages in thread
From: Matthew Wilcox @ 2001-07-08 21:10 UTC (permalink / raw)
To: Scott Ashcroft; +Cc: parisc-linux
On Sun, Jul 08, 2001 at 04:21:28PM +0100, Scott Ashcroft wrote:
> 2.4.0-pa51 boots fine. 2.4.6-pa5 goes:
>
> Dumping Stack from 10554000 to 10554840:
The stack dump isn't really necessary ... Does anyone else think we
should turn it off by default?
> Kernel Fault: Code=26 regs=10554600 (Addr=1025d080)
>
> YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
> PSW: 00000000000001001111111000001111
> r0-3 00000000 10294810 102a4980 10291010
> r4-7 102917c4 102e4348 102e4404 10000080
> r8-11 1028e748 0000004d 0004000e 1029ccd4
> r12-15 00000001 00000001 000000fd f0100000
> r16-19 f0000c30 f0000174 00000020 1025d080
> r20-23 1028d26c 10294cf4 10294810 00000002
> r24-27 102659e8 102954c8 102917c4 1026e010
> r28-31 00000000 102e9810 10554840 102d7810
> sr0-3 00000000 00000000 00000000 00000000
> sr4-7 00000000 00000000 00000000 00000000
>
> IASQ: 00000000 00000000 IAOQ: 102a4990 102a4994
> IIR: 0e601200 ISR: 00000000 IOR: 1025d080
> ORIG_R28: 0004000e
>
> What else is needed to debug this? Is there a ksymoops equivalent?
> I can supply .config, System.map on request.
I tend to look it up by hand -- 102a4990 is the most interesting address,
(IAOQ) and r2 is sometimes also interesting (not in this case, it
would seem).
It'd also be helpful to show where the kernel got to before it did the
stack dump -- might help track it down.
--
Revolutions do not require corporate support.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [parisc-linux] 2.4.6-pa5 crashes on B160L
2001-07-08 21:10 ` Matthew Wilcox
@ 2001-07-08 23:31 ` Grant Grundler
2001-07-08 23:48 ` Matthew Wilcox
2001-07-09 15:34 ` B132 dies too (was Re: [parisc-linux] 2.4.6-pa5 crashes on B160L) LaMont Jones
2001-07-09 1:41 ` [parisc-linux] 2.4.6-pa5 crashes on B160L Scott Ashcroft
1 sibling, 2 replies; 7+ messages in thread
From: Grant Grundler @ 2001-07-08 23:31 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: parisc-linux
Matthew Wilcox wrote:
> The stack dump isn't really necessary ... Does anyone else think we
> should turn it off by default?
...
No. I don't think we should turn it off.
Not until we can get memory core dumps on crashes like HPUX does.
> It'd also be helpful to show where the kernel got to before it did the
> stack dump -- might help track it down.
Isn't that what the stack dump is for?
If one is really good (like jsm) and has a matching vmlinux and System.map,
one can backtrace the stack by hand by looking at stack frame (return pointer
is in the stack frame) and seeing how much each subroutine grows the stack
(look at code around subroutine call, iirc). I think the mail archives
have a concise desription of exactly how to use the stack dump.
But I am too lazy to look for it now.
If one is lazy and not quite so good (like me), then look at build-tools/astk
script. astk can sift through the stackdump for kernel symbols to produce
something almost sortof like a stack trace with some extra garbage in it.
> > What else is needed to debug this? Is there a ksymoops equivalent?
> > I can supply .config, System.map on request.
>
> I tend to look it up by hand -- 102a4990 is the most interesting address,
> (IAOQ) and r2 is sometimes also interesting (not in this case, it
> would seem).
I use build-tools/a.c (compiled of course) to lookup symbols in a System.map.
The only other thing needed to debug the problem is for someone to unwind
the stack, see how it got where it was and then stare at the code until it's
clear why it crashed.
grant
Grant Grundler
parisc-linux {PCI|IOMMU|SMP} hacker
+1.408.447.7253
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [parisc-linux] 2.4.6-pa5 crashes on B160L
2001-07-08 23:31 ` Grant Grundler
@ 2001-07-08 23:48 ` Matthew Wilcox
2001-07-09 1:20 ` Grant Grundler
2001-07-09 15:34 ` B132 dies too (was Re: [parisc-linux] 2.4.6-pa5 crashes on B160L) LaMont Jones
1 sibling, 1 reply; 7+ messages in thread
From: Matthew Wilcox @ 2001-07-08 23:48 UTC (permalink / raw)
To: Grant Grundler; +Cc: Matthew Wilcox, parisc-linux
On Sun, Jul 08, 2001 at 05:31:25PM -0600, Grant Grundler wrote:
> No. I don't think we should turn it off.
> Not until we can get memory core dumps on crashes like HPUX does.
So far, I've seen _one_ useful stack dump posted to this list. The others
have just caused extra hassle & confusion for our users. And that
one stack dump was from Ryan , after repeated to-ing-and-froing with a
repeatable problem -- so he could have turned on an option very easily.
> Isn't that what the stack dump is for?
It's only useful if you've also got the System.map. If we didn't do
the stack dump, the users would probably send more information which
came before the stack dump.
--
Revolutions do not require corporate support.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [parisc-linux] 2.4.6-pa5 crashes on B160L
2001-07-08 23:48 ` Matthew Wilcox
@ 2001-07-09 1:20 ` Grant Grundler
0 siblings, 0 replies; 7+ messages in thread
From: Grant Grundler @ 2001-07-09 1:20 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: parisc-linux
Matthew Wilcox wrote:
> If we didn't do
> the stack dump, the users would probably send more information which
> came before the stack dump.
*sigh*
My gut feeling is you are right.
Despite asking for *full* console output, seems everyone trims the output.
I'm not sure an option would fix this. Perhaps we only get register dumps
instead. :^/
However, it's useful as an option if one can (a) reproduce the problem and
(b) enable stack dump as a boot parameter with exactly the same kernel bits.
Sorry for the 180 so suddenly.
grant
Grant Grundler
parisc-linux {PCI|IOMMU|SMP} hacker
+1.408.447.7253
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [parisc-linux] 2.4.6-pa5 crashes on B160L
2001-07-08 21:10 ` Matthew Wilcox
2001-07-08 23:31 ` Grant Grundler
@ 2001-07-09 1:41 ` Scott Ashcroft
1 sibling, 0 replies; 7+ messages in thread
From: Scott Ashcroft @ 2001-07-09 1:41 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: parisc-linux
On Sun, Jul 08, 2001 at 10:10:12PM +0100, Matthew Wilcox wrote:
> On Sun, Jul 08, 2001 at 04:21:28PM +0100, Scott Ashcroft wrote:
> > Kernel Fault: Code=26 regs=10554600 (Addr=1025d080)
> >
> > YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
> > PSW: 00000000000001001111111000001111
> > r0-3 00000000 10294810 102a4980 10291010
> > r4-7 102917c4 102e4348 102e4404 10000080
> > r8-11 1028e748 0000004d 0004000e 1029ccd4
> > r12-15 00000001 00000001 000000fd f0100000
> > r16-19 f0000c30 f0000174 00000020 1025d080
> > r20-23 1028d26c 10294cf4 10294810 00000002
> > r24-27 102659e8 102954c8 102917c4 1026e010
> > r28-31 00000000 102e9810 10554840 102d7810
> > sr0-3 00000000 00000000 00000000 00000000
> > sr4-7 00000000 00000000 00000000 00000000
> >
> > IASQ: 00000000 00000000 IAOQ: 102a4990 102a4994
> > IIR: 0e601200 ISR: 00000000 IOR: 1025d080
> > ORIG_R28: 0004000e
> >
> > What else is needed to debug this? Is there a ksymoops equivalent?
> > I can supply .config, System.map on request.
>
> I tend to look it up by hand -- 102a4990 is the most interesting address,
> (IAOQ) and r2 is sometimes also interesting (not in this case, it
> would seem).
102a494c ? probe_serial_pci
would seem to be the one.
> It'd also be helpful to show where the kernel got to before it did the
> stack dump -- might help track it down.
Forgot to say it was right at the start of booting.
Cheers,
Scott
^ permalink raw reply [flat|nested] 7+ messages in thread
* B132 dies too (was Re: [parisc-linux] 2.4.6-pa5 crashes on B160L)
2001-07-08 23:31 ` Grant Grundler
2001-07-08 23:48 ` Matthew Wilcox
@ 2001-07-09 15:34 ` LaMont Jones
1 sibling, 0 replies; 7+ messages in thread
From: LaMont Jones @ 2001-07-09 15:34 UTC (permalink / raw)
To: Grant Grundler; +Cc: Matthew Wilcox, parisc-linux, lamont
My B132 (which works 2.4.0) crashes sometime between palo launching the
kernel, and it having a working console (serial). That is to say, no info
at all. If someone wants the machine in order to debug it, just holler...
> If one is really good (like jsm) and has a matching vmlinux and System.map,
> one can backtrace the stack by hand by looking at stack frame (return pointer
> is in the stack frame) and seeing how much each subroutine grows the stack
> (look at code around subroutine call, iirc). I think the mail archives
> have a concise desription of exactly how to use the stack dump.
> But I am too lazy to look for it now.
Backtracing is extremely straight-forward, and can be automated, AFAIK.
Walking the stack forward is a bit more challenging, but not entirely
beyond possibility most of the time...
lamont
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2001-07-09 15:35 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-07-08 15:21 [parisc-linux] 2.4.6-pa5 crashes on B160L Scott Ashcroft
2001-07-08 21:10 ` Matthew Wilcox
2001-07-08 23:31 ` Grant Grundler
2001-07-08 23:48 ` Matthew Wilcox
2001-07-09 1:20 ` Grant Grundler
2001-07-09 15:34 ` B132 dies too (was Re: [parisc-linux] 2.4.6-pa5 crashes on B160L) LaMont Jones
2001-07-09 1:41 ` [parisc-linux] 2.4.6-pa5 crashes on B160L Scott Ashcroft
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.