jhb Can you get a backtrace in ddb? It looks like a null pointer
jhb dereference, and knowing where it happened would help.
Backtrace told me that the panic was occured when
usbd_get_interface_descriptor() is called from aue_attach().
jhb Finding the file and line of the instruction pointer
On Mon, Apr 15, 2002 at 11:11:36AM +0200, Nick Hibma wrote:
device_set_ivars is always called (in usbd_probe_and_attach) with as an
argument a stack variable. Also, the ivar is not stored or anything in
the if_aue.c driver. So this problem sounds like a problem in revisions
of various files.
On Mon, Apr 15, 2002 at 12:35:46PM -0500, Will Andrews wrote:
On Mon, Apr 15, 2002 at 11:11:36AM +0200, Nick Hibma wrote:
device_set_ivars is always called (in usbd_probe_and_attach) with as an
argument a stack variable. Also, the ivar is not stored or anything in
the if_aue.c driver. So
Following are observed with 5-current kernel as of Apr/13/2002.
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x4
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0189b4a
stack pointer = 0x10:0xc03f5180
frame
On 13-Apr-2002 Makoto Matsushita wrote:
Following are observed with 5-current kernel as of Apr/13/2002.
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x4
fault code= supervisor read, page not present
instruction pointer = 0x8:0xc0189b4a
stack
On Sat, Apr 13, 2002 at 12:44:36PM -0400, John Baldwin wrote:
Can you get a backtrace in ddb? It looks like a null pointer dereference, and
knowing where it happened would help. Finding the file and line of the
instruction pointer using addr2line on kernel.debug would be helpful as well.
It
On 13-Apr-2002 Will Andrews wrote:
On Sat, Apr 13, 2002 at 12:44:36PM -0400, John Baldwin wrote:
Can you get a backtrace in ddb? It looks like a null pointer dereference,
and
knowing where it happened would help. Finding the file and line of the
instruction pointer using addr2line on
