Date: Wed, 7 Sep 2011 10:14:26 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-current@freebsd.org Cc: Ryan Stone <rysto32@gmail.com> Subject: Re: panic: sched_priority: invalid priority 3990 on r225375 Message-ID: <201109071014.27026.jhb@freebsd.org> In-Reply-To: <CAFMmRNx45ce5Lg8MVUmmYZc3Y6EYYiguDd3K8neVGT4V=83XxA@mail.gmail.com> References: <CAFMmRNx45ce5Lg8MVUmmYZc3Y6EYYiguDd3K8neVGT4V=83XxA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday, September 04, 2011 7:21:23 pm Ryan Stone wrote: > I've gotten the following panic twice while running recent builds of > head under VirtualBox(FreeBSD 8.2 host). > > panic: sched_priority: invalid priority 3990: nice 0, ticks 1227873280 > ftick 175669871 ltick 175679894 tick pri 3818 > > The crashes happened while I was running a stress test of the network > stack. I have a client machine and a server machine. The client is > running head with a patch that I'm trying to prove out; the server > should be running with basically stock head as of r225375(I think that > there's a couple of minor changes in the tree I used to build the > server with, but I've gotten the crash on the client and the server, > and neither have any uncommitted patches in common). The server is > running several netcat instances in listen mode; the client has a > script sitting in a loop starting netcat instances that connect to > instances running on the server and send data from client -> server. > The client also has a script that changes the routing tables > periodically. > > Both the client and the server have crashed once so far. I haven't > been running any tests on actual hardware so I can't say whether this > is a FreeBSD problem or a VirtualBox problem. I'm going to start > running the same tests against VMs running some version of FreeBSD 8 > to see if I can reproduce the problem there. In the meantime, I've > made a core.txt accessible in case anybody wants to take a look. You > can find it at: > > http://people.freebsd.org/~rstone/sched_priority/core.txt.0.bz2 > > Please let me know if you need any more information. This is due to ts->ts_ticks being way too large. I think it needs a cap to handle this case, but I'm not sure exactly which bits need to be capped, and what the maximum value they should be capped at is. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201109071014.27026.jhb>