umass causes panic on 7 amd64

[Steve Franks]

On Tue, Apr 15, 2008 at 12:20 PM, Roland Smith <rsmith at 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 at 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 at 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 at 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 at 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)