[BProc] unsubscribe

[Raj K. <RKa...@nv...>]

-----Original Message-----
From: bpr...@li...
[mailto:bpr...@li...] 
Sent: Tuesday, October 22, 2002 12:09 PM
To: bpr...@li...
Subject: BProc-users digest, Vol 1 #151 - 1 msg


Send BProc-users mailing list submissions to
	bpr...@li...

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/bproc-users
or, via email, send a message with subject or body 'help' to
	bpr...@li...

You can reach the person managing the list at
	bpr...@li...

When replying, please edit your Subject line so it is more specific than
"Re: Contents of BProc-users digest..."


Today's Topics:

   1. Re: another 3.2.0 oops (er...@he...)

--__--__--

Message: 1
Date: Mon, 21 Oct 2002 15:07:42 -0400
From: er...@he...
To: Nicholas Henke <he...@se...>
Cc: bpr...@li...
Subject: Re: [BProc] another 3.2.0 oops

On Mon, Oct 21, 2002 at 10:06:44AM -0400, Nicholas Henke wrote:
> Hrm -- I seems to be breaking things again. The following oops 
> occurred running my 'noop' script again -- the ps script is that 
> script, just remove the bpsh $node ps line. I have seen this oops 
> twice so far -- the
> Code: was the same in both. If the trace is bogus, I would _really_
> appreciate any pointers you could give me to get better traces for you. 
> 
> Cheers!
> Nic
> 
> Unable to handle kernel paging request at virtual address 0804a59b 
> *pde = 1bde1067
> Oops: 0003
> CPU: 1
> EIP: [<c0116c6c>]   Not tainted
> Using defaults from ksymoops -t elf32-i386 -a i386
> EFLAGS: 00010046
> Process bpslave (pid: 31698, stackpage=d8a45000)
> Stack: 00000001 00000282 00000003 dca85ef0 dc488cc0 00000000 dbd9800 
> c010608c dca85ef0 dc40bfa0 00000000 e097af39 00000000 00000000 
> 00000000 00000000 00000000
> 00000000 00000000 00000000 00000000 00000000 00000000 00000011
> Call Trace: [<c010608c>] [<e097af1d>] [<e096f329>] [<e097a698>]
> [<e096f313>]
> [<e097a698>]
> Code: c7 01 00 00 00 00 8b 41 3c 85 c0 75 2d a1 c0 d1 26 c0 8d 51
> 
> >>EIP; c0116c6c <__wake_up+4c/c0>   <=====
> Trace; c010608c <__up_wakeup+8/c>
> Trace; e097af1d <__module_using_checksums+5893/????>
> Trace; e096f329 <[bproc]bproc_iod_release+3d/89>
> Trace; e097a698 <__module_using_checksums+500e/????>
> Trace; e096f313 <[bproc]bproc_iod_release+27/89>
> Trace; e097a698 <__module_using_checksums+500e/????>

Hrm.  It's hard to give generic pointers.  I usually try to look at the
whole mess and try to figure it out.

This back trace looks reasonable except for the __module_using_checksums
part.  That's weird.  A lot of the time I get the module binary and look for
the code in it to see what function it's in.  In this case you're in
__wake_up so that's not that useful.

As always reproducing it is the most reliable way to go.  I just saw some
more weirdness so I'm looking into it.

- Erik



--__--__--

_______________________________________________
BProc-users mailing list
BPr...@li...
https://lists.sourceforge.net/lists/listinfo/bproc-users


End of BProc-users Digest