Date: Wed, 16 Apr 2008 09:10:23 -0700 From: "Steve Franks" <stevefranks@ieee.org> To: "Roland Smith" <rsmith@xs4all.nl>, freebsd-stable@freebsd.org Subject: Re: umass causes panic on 7 amd64 Message-ID: <539c60b90804160910q3a242d7amb474b40065d6c9c6@mail.gmail.com> In-Reply-To: <20080415192028.GA31706@slackbox.xs4all.nl> References: <539c60b90804111420kcb73e6do8a20dce574d13864@mail.gmail.com> <20080412213225.GB24224@slackbox.xs4all.nl> <539c60b90804141549u6a138ad9u9c77bbfcbbad0ff3@mail.gmail.com> <20080415175347.GA29045@slackbox.xs4all.nl> <539c60b90804151134q7a25a141m1205a1b04d8ffc2c@mail.gmail.com> <20080415192028.GA31706@slackbox.xs4all.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 15, 2008 at 12:20 PM, Roland Smith <rsmith@xs4all.nl> wrote: > On Tue, Apr 15, 2008 at 11:34:31AM -0700, Steve Franks wrote: > > Being a naturally curious guy, with your pointers, I've located the following: > > > > [steve@dystant /var/crash]$ sudo cat info.2 > > Yep. This is what you need. > > > > Dump header from device /dev/ad4s1b > > Architecture: amd64 > > Architecture Version: 2 > > Dump Length: 211496960B (201 MB) > > Blocksize: 512 > > Dumptime: Fri Apr 11 11:02:40 2008 > > As you can see it went wrong _just_ after you plugged in the olympus. > > > > Hostname: dystant.franks-development.dyndns.biz > > Magic: FreeBSD Kernel Dump > > Version String: FreeBSD 7.0-STABLE #14: Mon Mar 10 16:35:38 MST 2008 > > steve@dystant.franks-development.dyndns.biz:/usr/obj/usr/src/sys/GENERIC > > Panic String: page fault > > This is what caused the crash. The system was trying to access memory > that it shouldn't. The question is where did it happen. > > > > Dump Parity: 2580707083 > > Bounds: 2 > > Dump Status: good > > The developers' handbook* will show you how to debug the crashdump. The > developers will be interested in the cause of the crash and the stack > backtrace. See §10.2 of the developers' handbook. > > With that info you could post a question on the -amd64 or -stable list. > > (* if installed you should be able to find it at > file:///usr/share/doc/en_US.ISO8859-1/books/developers-handbook/index.html) > > > > [steve@dystant /var/log]$ cat messages.0 | grep umass > > Apr 11 11:02:39 dystant kernel: umass0: <OLYMPUS C-700 Ultra Zoom, > > I presume that the next line is 'Copyright (c) 1992-2008 The FreeBSD Project.'? > That would indicate that the systems crashes before it gets to assign a > da device to the umass device. > > If it is something like 'da0 at umass-sim0 bus 0 target 0 lun 0' it is > interesting as well, because it can show _where_ things go wrong. > > Try something like "grep -A 1 'umass0: <' /var/log/messages.0" > > By the way, can you reproduce the crash with another umass device? > > > > It could be hardware-related, I guess - the crash is rather faster if > > I plug into the front of the case vs. directly into the motherboard in > > the back. > > That could be interesting. But it could also be caused by the topology > of the usb bus. I'm not an expert on this issue. :-) > > > > The interesting thing is that it is only umass, not ucom, > > ugen, or ums (they all play fine). > > Well, they are different drivers using different code paths through the > kernel. But it will help in narrowing down the cause of the crash. > > My guesstimate would be that it bombs in trying to assign a da device to > the umass device. But I could be wrong. > > BTW, if you post a followup to one of the mailing lists, don't forget to > mention what usb controller you're using. You can easily find that out > with 'dmesg|grep "^usb"'. This will show you how many usb controllers > you have and what type of controller chip they use. > > > > Roland > -- > R.F.Smith http://www.xs4all.nl/~rsmith/ > [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] > pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) > freebsd-stable: as you can see, Roland has been teaching me about crashdumps since my umass brought down one system, and is rather unusable on another. Here's the kgdb output: Best, Steve [steve@dystant /usr/obj/usr/src/sys/GENERIC]$ sudo kgdb kernel.debug /var/crash/vmcore.3 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd". Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read instruction, page not present instruction pointer = 0x8:0x0 stack pointer = 0x10:0xffffffffa0208570 frame pointer = 0x10:0xffffff0001e1ca00 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (swi4: clock sio) trap number = 12 panic: page fault cpuid = 0 Uptime: 32s Physical memory: 1002 MB Dumping 96 MB: 81 65 49 33 17 #0 doadump () at pcpu.h:194 194 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); (kgdb)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?539c60b90804160910q3a242d7amb474b40065d6c9c6>