Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 3 Nov 2011 19:42:30 +0100
From:      Hans Petter Selasky <hselasky@c2i.net>
To:        freebsd-current@freebsd.org
Cc:        Jan Henrik Sylvester <me@janh.de>
Subject:   Re: USB3 express card panics on 9.0-RC1
Message-ID:  <201111031942.30498.hselasky@c2i.net>
In-Reply-To: <4EB2895B.3080104@janh.de>
References:  <4EB1602C.6030807@janh.de> <4EB27225.4020504@janh.de> <4EB2895B.3080104@janh.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 03 November 2011 13:30:19 Jan Henrik Sylvester wrote:
> On 11/03/2011 11:51, Jan Henrik Sylvester wrote:
> > On 11/03/2011 09:27, Hans Petter Selasky wrote:
> >> On Wednesday 02 November 2011 16:22:20 Jan Henrik Sylvester wrote:
> >>> I have bought a "Super-speed Express Card To USB 3.0 1-Port" to connect
> >>> an USB3 hard disk to my Thinkpad T510, which only has USB2.
> >>> 
> >>> Trying to hot plug the express card did nothing, but I guess that is
> >>> expected. Hence, I booted with the express card already inserted, only
> >>> to receive a panic upon xhci0 initialization, see below.
> >>> 
> >>> This is on FreeBSD 9.0-RC1/amd64 with a generic kernel installed from
> >>> the official DVD.
> >>> 
> >>> I guess I could test 226803 mentioned in
> >>> http://lists.freebsd.org/pipermail/freebsd-usb/2011-October/010746.html
> >>> , which happened after RC1, but from the commit message, it only fixes
> >>> suspend and resume.
> >>> 
> >>> As I do not have much time now, should I test 226803, find a Linux CD
> >>> to actually identify the device, or anything else?
> >>> 
> >>> Cheers,
> >>> Jan Henrik
> >>> 
> >>> 
> >>> usbus0: 480 Mbps High Speed USB v2.0
> >>> 
> >>> Fatal trap 12: page fault while in kernel mode
> >>> cpuid = 0; apic id = 00
> >>> fault virtual address = 0x18
> >>> fault code = supervisor write data, page not present
> >>> instruction ponter = 0x20:0xffffffff806e80aa
> >>> stack pointer = 0x28:0xffffff810ee50bc0
> >>> frame pointer = 0x28:0xffffff810ee50bf0
> >>> code segment = base 0x0, limit 0xfffff, type 0x16
> >>> = DPL 0, pres 1, long 1, def32 0, gran 1
> >>> processor eflags = interrupt enabled, resume, IOPL = 0
> >>> current process = 15 (xhci0)
> >>> trap number = 12
> >>> panic: page fault
> >>> cpuid = 0
> >>> Uptime = 1s
> >>> Automatic reboot in 15 seconds - press a key on the console to abort
> >> 
> >> Hi,
> >> 
> >> This looks like a NULL-pointer issue inside "xhci_configure_msg()" which
> >> probably should be easy to fix.
> >> 
> >> Could you compile and boot a kernel with kernel debugging enable so
> >> that you
> >> get a backgtrace?
> > 
> > I have not done this before.
> > 
> > The GENERIC kernel already contains "makeoptions DEBUG=-g" (at least it
> > is in /usr/src/sys/amd64/conf/GENERIC and there are all this large
> > /boot/kernel/*.symbols). Is there anything else needed? (I do not need
> > all the stuff that Ken Smith took out just before RC1 in r226405 just to
> > get a trace, since I do not want to do online debugging, or do I need it
> > anyhow?)
> > 
> >  From
> > 
> > http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html
> > , I thought that setting dumpdev="AUTO" in /etc/rc.conf was enough to
> > get a dump in /var/crash/ after the next boot to multiuser. That does
> > not seem to be the case for me. What else do I have to do?
> 
> After reading a bit more, I still do not know why I do not get a crash
> dump with dumpdev="AUTO" (and /var/crash/ having enough space for a full
> memory dump). Is it too early during boot for dumpon to be set?
> 
> After reading http://www.unixguide.net/freebsd/faq/18.13.shtml , I found
> that ffffffff806e8040 t usb_process is the last symbol before
> instruction pointer = 0x20:0xffffffff806e80aa. Does this help?

Try add:

options         KDB                     # Enable kernel debugger support.
options         DDB                     # Support DDB.

--HPS



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