Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 6 Apr 2004 14:14:05 +0200
From:      Bernd Walter <ticso@cicely12.cicely.de>
To:        Heinrich Rebehn <rebehn@ant.uni-bremen.de>
Cc:        freebsd-questions@freebsd.org
Subject:   Re: Recommended USB 2.0 controller fr. 5.2+
Message-ID:  <20040406121404.GD82799@cicely12.cicely.de>
In-Reply-To: <40729B72.80008@ant.uni-bremen.de>
References:  <200403221348.52786.peter.schuller@infidyne.com> <200403221409.01443.peter.schuller@infidyne.com> <20040329113642.GF26269@cicely12.cicely.de> <407157F9.4080701@ant.uni-bremen.de> <20040405130526.GA81325@cicely12.cicely.de> <407176AC.3010604@ant.uni-bremen.de> <20040405152144.GB81325@cicely12.cicely.de> <40729B72.80008@ant.uni-bremen.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 06, 2004 at 01:58:42PM +0200, Heinrich Rebehn wrote:
> Bernd Walter wrote:
> [snip]
> >
> >>Apr  3 12:32:32 antsrv1 kernel: da1: 19077MB (39070080 512 byte sectors: 
> >>255H 63S/T 2432C)
> >>Apr  3 12:33:03 antsrv1 login: ROOT LOGIN (root) ON ttyv0
> >>Apr  3 12:38:08 antsrv1 syslogd: kernel boot file is /boot/kernel/kernel
> >>Apr  3 12:38:08 antsrv1 kernel: panic: ehci_abort_xfer: not in process 
> >>context
> >
> >
> >OK - we have an abort_xfer without any reason given.
> >The panic is because the aborted transfer doesn't exist, which could
> >mean that someone aborted an already completed transfer.
> >Can you please add USB_DEBUG to your kernel and retry.
> >
> >
> I did, but with USB_DEBUG the system reproducibly crashes during boot:

Without a stacktrace or at least the last kernel messages this output
is almost useless.

> kernel: 
> kernel: 
> kernel: Fatal trap 12: page fault while in kernel mode 
> kernel: cpuid = 0; apic id = 00 
> kernel: fault virtual address   = 0xd 
> kernel: fault code              = supervisor write, page not present 
> kernel: instruction pointer     = 0x8:0xc0535482 
> kernel: stack pointer           = 0x10:0xeaccfbb0 
> kernel: frame pointer           = 0x10:0xeaccfbc8 
> kernel: code segment            = base 0x0, limit 0xfffff, type 0x1b 
> kernel: = DPL 0, pres 1, def32 1, gran 1 
> kernel: processor eflags        = interrupt enabled, resume, IOPL = 0 
> kernel: current process         = 246 (sysctl) 
> kernel: trap number             = 12 
> kernel: panic: page fault 
> kernel: cpuid = 0; 
> kernel: 
> kernel: syncing disks, buffers remaining... 6564 6564 6563 6563 6563 
> 6563 6563 6563 6563 6563 6563 6563 6563 6563 6563 6563 6563 6563 6563 
> 6563 6563 6563

You have 6563 dirty buffers when it crashed?
That's amazing - so you are at least already on the way getting
multiuser - otherwise everything is still read-only.
I can't guess what services, etc.. you are starting - you really have
to tell what happens.

-- 
B.Walter                   BWCT                http://www.bwct.de
ticso@bwct.de                                  info@bwct.de



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040406121404.GD82799>