FreeBSD 5.1-R kernel panic
bruce at cran.org.uk
Mon Jul 21 16:18:37 PDT 2003
On Mon, Jul 21, 2003 at 06:43:11PM +0000, Bosko Milekic wrote:
> On Mon, Jul 21, 2003 at 06:24:07PM -0400, Mik Firestone wrote:
> > For what it is worth, I am having the exact same problem. I cvsup'd and
> > builtworld on Sunday, July 20, and my machine has been crashing about every
> > half-hour since. It starts slowing down, the load average begins to
> > climb until it eventually grinds to a halt. If I wait long enough, I
> > will see the same panic Stephane saw.
> > Doing a ps -auxw shows that usb0 is using the vast majority of the CPU
> > time before the grinding halt. I have tried leaving the machine in
> > multi-user and sigle-user mode with the same results. I have attempted
> > to compile a new kernel that does not have the USB stuff compiled in,
> > but my machine won't stay running long enough.
> > I do have the debugger compiled in, but I do not know enough of what I
> > am doing to provide reasonable information to the list. If somebody
> > can tell me the commands to run in the debugger, I will let my machine
> > panic again and grab that data.
> > Mik
> Does reverting to pre-July 20 get rid of your problem? Note that the
> originator of the first Email mentionned that he is running what
> appeared to be stock 5.1-RELEASE, which may or may not be related to
> what you're seeing.
> If reverting to pre-July 20 gets rid of your problem, perhaps we can
> figure out what commit triggered this behavior for you. Also, do you
> have PAE enabled?
It sounds like the same or similar problem reported in the 'USB crappiness'
thread - the system slows down, and then any command crashes the system with
the error about kmem. I posted a backtrace to the problem in usb_mem.c, and
the developer has posted a temporary fix - it was a problem with bus_dma,
it was allocating too much memory and running out of kernel memory.
If the kernel debugger is compiled in, the system should drop to the db>
prompt when it panics. Type 'tr' and post the results it gives. This
panic appears to stop memory dumps working, otherwise you could set the
dumpdev variable in rc.conf also get
the source listing of where the problem occurs: the FreeBSD Developers Handbook
has more information.
More information about the freebsd-current