From owner-freebsd-usb@FreeBSD.ORG Sun Mar 4 19:40:08 2007 Return-Path: X-Original-To: freebsd-usb@hub.freebsd.org Delivered-To: freebsd-usb@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A188816A401 for ; Sun, 4 Mar 2007 19:40:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 84B1713C461 for ; Sun, 4 Mar 2007 19:40:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l24Je8Iq067669 for ; Sun, 4 Mar 2007 19:40:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l24Je81P067668; Sun, 4 Mar 2007 19:40:08 GMT (envelope-from gnats) Date: Sun, 4 Mar 2007 19:40:08 GMT Message-Id: <200703041940.l24Je81P067668@freefall.freebsd.org> To: freebsd-usb@FreeBSD.org From: Jonathan Fosburgh Cc: Subject: Re: kern/92083: [ural] [panic] panic using WPA on ural NIC in 6.2-RELEASE X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jonathan Fosburgh List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2007 19:40:08 -0000 The following reply was made to PR kern/92083; it has been noted by GNATS. From: Jonathan Fosburgh To: Sam Leffler Cc: Anders Nordby , bug-followup@freebsd.org Subject: Re: kern/92083: [ural] [panic] panic using WPA on ural NIC in 6.2-RELEASE Date: Sun, 4 Mar 2007 13:32:01 -0600 On Monday 12 February 2007 11:27, Sam Leffler wrote: > Jonathan Fosburgh wrote: > > The last I heard about any of this stuff your problems were related to > usb xfer stalls. If this no longer true then please provide me with a > recipe for recreating the issue. If it's a driver/net80211 issue I will > try to fix it. If it's in the usb subsystem it's unlikely I'm going to > pursue it. > I'm at a loss here. As far as i can tell, my kernel is compiled with=20 debugging symbols, etc, but when I try to analyze the core dumps I get I ge= t=20 mostly unusable garbage. For instance, on a very recent panic: `--# kgdb /usr/obj/usr/src/sys/vmbsd/kernel.debug /usr/crash/vmcore.6 kgdb: kvm_nlist(_stopped_cpus): kgdb: kvm_nlist(_stoppcbs): [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:= =20 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 condition= s. 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: =46atal trap 12: page fault while in kernel mode fault virtual address =3D 0x8 fault code =3D supervisor read data, page not present instruction pointer =3D 0x8:0xffffffff806e34be stack pointer =3D 0x10:0xffffffff92122b10 frame pointer =3D 0x10:0xffffffff92122b40 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 32 (irq21: uhci0 uhci*) trap number =3D 12 panic: page fault Uptime: 2h27m41s Physical memory: 504 MB Dumping 135 MB: 120 104 88 72 56 40 24 8 #0 doadump () at pcpu.h:172 172 pcpu.h: No such file or directory. in pcpu.h Running nm on the kernel and grepping for the instruction pointer I get=20 nothing useable, I wind up with a very large number of symbols. When I run= =20 where in the panic I get things like this: 0 doadump () at pcpu.h:172 #1 0x0000000000000004 in ?? () #2 0xffffffff80234dd9 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:411 #3 0xffffffff802353be in panic (fmt=3D0xffffff001ebf12b0 "\200s=B7\036") at /usr/src/sys/kern/kern_shutdown.c:567 #4 0xffffffff80356a82 in trap_fatal (frame=3D0xffffffff92122a60, eva=3D8) at /usr/src/sys/amd64/amd64/trap.c:696 #5 0xffffffff80356df2 in trap_pfault (frame=3D0xffffffff92122a60, usermode= =3D0) at /usr/src/sys/amd64/amd64/trap.c:614 #6 0xffffffff80357085 in trap (frame=3D0xffffffff92122a60) at /usr/src/sys/amd64/amd64/trap.c:382 #7 0xffffffff80341b3e in calltrap () at /usr/src/sys/amd64/amd64/exception.S:169 #8 0xffffffff806e34be in ?? () #9 0xffffffff80a40ec0 in ?? () #10 0x0000000000000000 in ?? () #11 0xffffff000000d800 in ?? () #12 0xffffffff80a40000 in ?? () #13 0xffffffff92122b70 in ?? () =2D---------- #126 0x0000000000000000 in ?? () #127 0x0000000000000000 in ?? () #128 0x0000000000000000 in ?? () #129 0x0000000000000000 in ?? () #130 0x0000000000000000 in ?? () #131 0x0000000000000000 in ?? () #132 0x0000000000000000 in ?? () Cannot access memory at address 0xffffffff92123000 There are intermittant locations that give usable info, but not very much. = Is=20 there something else I need to do?