From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Wed 05 Feb 2003 - 18:55:19 GMT
On Wed, Feb 05, 2003 at 04:46:21PM +0000, Paul Sladen wrote:
> On Mon, 3 Feb 2003, John Goerzen wrote:
>
> Sorry I didn't express a `bite', I [still] haven't had time to look through
> the call-path.
>
> > Scheduling in interrupt kernel BUG at sched.c:570! Invalid operand: 0000
> >
> > Adhoc c01093ef <system_call+33/38>
> > Adhoc c011a201 <schedule+501/530>
> > Adhoc c01208c8 <release_task+e8/110>
> > Adhoc c01218dc <sys_wait4+39c/410>
> > Adhoc c01218de <sys_wait4+39e/410>
> > Adhoc c012b419 <sys_release_ip_info+29/60>
> ^^^^^^^^^^^^^^^^^^^
> Yes, this is ctx related. I'm guessing a locking issue, which if it is
> there, could explain quite a lot of other things to.
I tend to agree ...
Justin M Kuntz reported a kernel oops in
sched.c 570 on a 2.4.20 ctx16 with reiserfs
on january 01 2003, so this seems to be
the same race ...
> > Adhoc c012c12a <.text.lock.sys+ea/190>
> > Adhoc c026910a <tcp_sendpage+11a/160>
> > Adhoc c027ad7d <tcp_v4_do_rcv+10d/1c0>
> > Adhoc c02882ef <inet_sock_destruct+ff/1c0>
> > Adhoc c02a4f99 <rwsem_down_write_failed+29/40>
> > Adhoc c02a510c <rwsem_down_failed_common+5c/7e>
> > Adhoc c02b910a <timer_bug_msg+912a/37b20>
> > Adhoc c02fbc00 <fs_table+40/220>
> > Adhoc c02fbf00 <uts_sem+8/28>
> > Adhoc ffffffff <END_OF_CODE+76b8dc8/????>
>
> If you can regularly reproduce these, then dumping them (in full) via
> serial/netconsole/lights-out would be useful.
would suggest to attach a kernel debugger
and analyze the scheduler structures ...
best,
Herbert
> Thanks,
>
> -Paul
> --
> Nottingham, GB
>
>