RE: plug aue ethernet goes to panic
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 using jhb addr2line on kernel.debug would be helpful as well. But unfortunately, my kernel.debug prints uhub0: device problem, disabling port 2 and doesn't panic :-( *** I've confirmed that kernel and its module are in sync. There no /modules directory since this machine was born as 5-current box, and /boot/modules directory is empty. ident(1) output of src/sys/dev/usb is attached below. -- - Makoto `MAR' Matsushita /sys/dev/usb/dsbr100io.h: $FreeBSD: src/sys/dev/usb/dsbr100io.h,v 1.1 2002/03/04 03:51:19 alfred Exp $ /sys/dev/usb/hid.c: $NetBSD: hid.c,v 1.17 2001/11/13 06:24:53 lukem Exp $ $FreeBSD: src/sys/dev/usb/hid.c,v 1.18 2002/04/07 17:53:58 joe Exp $ /sys/dev/usb/hid.h: $NetBSD: hid.h,v 1.6 2000/06/01 14:28:57 augustss Exp $ $FreeBSD: src/sys/dev/usb/hid.h,v 1.11 2002/04/01 19:01:08 joe Exp $ /sys/dev/usb/if_aue.c: $FreeBSD: src/sys/dev/usb/if_aue.c,v 1.56 2002/04/07 12:19:50 joe Exp $ $FreeBSD: src/sys/dev/usb/if_aue.c,v 1.56 2002/04/07 12:19:50 joe Exp $ /sys/dev/usb/if_auereg.h: $FreeBSD: src/sys/dev/usb/if_auereg.h,v 1.13 2002/04/07 12:04:01 joe Exp $ /sys/dev/usb/if_cue.c: $FreeBSD: src/sys/dev/usb/if_cue.c,v 1.28 2002/04/07 12:19:50 joe Exp $ $FreeBSD: src/sys/dev/usb/if_cue.c,v 1.28 2002/04/07 12:19:50 joe Exp $ /sys/dev/usb/if_cuereg.h: $FreeBSD: src/sys/dev/usb/if_cuereg.h,v 1.10 2002/04/07 12:04:01 joe Exp $ /sys/dev/usb/if_kue.c: $FreeBSD: src/sys/dev/usb/if_kue.c,v 1.40 2002/04/07 12:19:50 joe Exp $ $FreeBSD: src/sys/dev/usb/if_kue.c,v 1.40 2002/04/07 12:19:50 joe Exp $ /sys/dev/usb/if_kuereg.h: $FreeBSD: src/sys/dev/usb/if_kuereg.h,v 1.10 2002/04/07 12:04:02 joe Exp $ /sys/dev/usb/kue_fw.h: $FreeBSD: src/sys/dev/usb/kue_fw.h,v 1.2 2000/04/03 20:58:23 n_hibma Exp $ /sys/dev/usb/ohci.c: $NetBSD: ohci.c,v 1.121 2002/03/16 16:11:18 tsutsui Exp $ $FreeBSD: src/sys/dev/usb/ohci.c,v 1.102 2002/04/07 16:36:30 joe Exp $ /sys/dev/usb/ohcireg.h: $NetBSD: ohcireg.h,v 1.17 2000/04/01 09:27:35 augustss Exp $ $FreeBSD: src/sys/dev/usb/ohcireg.h,v 1.18 2002/04/01 13:21:43 joe Exp $ /sys/dev/usb/ohcivar.h: $NetBSD: ohcivar.h,v 1.30 2001/12/31 12:20:35 augustss Exp $ $FreeBSD: src/sys/dev/usb/ohcivar.h,v 1.32 2002/04/07 15:16:31 joe Exp $ /sys/dev/usb/rio500_usb.h: $FreeBSD: src/sys/dev/usb/rio500_usb.h,v 1.1 2000/04/08 17:02:13 n_hibma Exp $ /sys/dev/usb/ucom.c: $NetBSD: ucom.c,v 1.39 2001/08/16 22:31:24 augustss Exp $ $FreeBSD: src/sys/dev/usb/ucom.c,v 1.16 2002/04/01 21:30:36 jhb Exp $ /sys/dev/usb/ucomvar.h: $NetBSD: ucomvar.h,v 1.9 2001/01/23 21:56:17 augustss Exp $ $FreeBSD: src/sys/dev/usb/ucomvar.h,v 1.1 2002/03/18 18:23:39 joe Exp $ /sys/dev/usb/udbp.c: $FreeBSD: src/sys/dev/usb/udbp.c,v 1.14 2002/04/04 21:03:17 jhb Exp $ /sys/dev/usb/udbp.h: $FreeBSD: src/sys/dev/usb/udbp.h,v 1.1 2000/05/01 22:48:22 n_hibma Exp $ /sys/dev/usb/ufm.c: $FreeBSD: src/sys/dev/usb/ufm.c,v 1.4 2002/03/11 16:38:53 imp Exp $ /sys/dev/usb/ugen.c: $NetBSD: ugen.c,v 1.51 2001/11/13 07:59:32 augustss Exp $ $FreeBSD: src/sys/dev/usb/ugen.c,v 1.59 2002/03/11 16:22:15 joe Exp $ /sys/dev/usb/ugraphire_rdesc.h: $NetBSD: usb/ugraphire_rdesc.h,v 1.1 2000/12/29 01:47:49 augustss Exp $ $FreeBSD: src/sys/dev/usb/ugraphire_rdesc.h,v 1.1 2002/04/07 17:04:01 joe Exp $ /sys/dev/usb/uhci.c: $NetBSD: uhci.c,v 1.158 2002/03/17 18:02:53 augustss Exp $ $FreeBSD: src/sys/dev/usb/uhci.c,v 1.119 2002/04/07 18:33:12 joe Exp $ /sys/dev/usb/uhcireg.h: $NetBSD: uhcireg.h,v 1.15 2002/02/11 11:41:30 augustss Exp $ $FreeBSD: src/sys/dev/usb/uhcireg.h,v 1.20 2002/04/07 18:06:34 joe Exp $ /sys/dev/usb/uhcivar.h: $NetBSD: uhcivar.h,v 1.33 2002/02/11 11:41:30 augustss Exp $ $FreeBSD: src/sys/dev/usb/uhcivar.h,v 1.33 2002/04/07 18:06:34 joe Exp $ /sys/dev/usb/uhid.c: $NetBSD: uhid.c,v 1.45 2001/10/26 17:58:21 augustss Exp $ $FreeBSD: src/sys/dev/usb/uhid.c,v 1.49 2002/04/07 17:13:00 joe Exp $ /sys/dev/usb/uhub.c: $NetBSD: uhub.c,v 1.57 2001/11/20 16:08:37 augustss Exp $ $FreeBSD: src/sys/dev/usb/uhub.c,v 1.42 2002/04/07 11:29:31 joe Exp $ /sys/dev/usb/ukbd.c: $FreeBSD: src/sys/dev/usb/ukbd.c,v 1.37 2002/04/07 13:16:17 joe Exp $ /sys/dev/usb/ulpt.c: $NetBSD: ulpt.c,v 1.46 2001/12/31 12:15:21 augustss Exp $ $FreeBSD: src/sys/dev/usb/ulpt.c,v 1.43 2002/03/11 16:22:15 joe Exp $ /sys/dev/usb/umass.c: $FreeBSD: src/sys/dev/usb/umass.c,v 1.60 2002/04/11 21:09:41 jhb Exp $ $NetBSD: umass.c,v 1.28 2000/04/02 23:46:53 augustss Exp $ /sys/dev/usb/umodem.c: $NetBSD: umodem.c,v 1.5
Re: plug aue ethernet goes to panic
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. Please check that your kernel modules kernel are in sync. Do this by rebuilding the kernel and the modules from scratch. Also, after you've installed your kernel check that all your kernel files have been updated. Do you by any chance have a stale /modules or /boot/modules directory lying around? You should have only kernel modules in /boot/kernel*/ and NOT in /modules* or /boot/modules*. If the problem persists, please mail me the output of ident /sys/dev/usb/*.[ch] find /modules /boot -type f -ls Nick, You really should talk to Joe Karthauser. He's already confirmed that it *is* an issue in the code (and not any kind of misconfiguration on my part). I've already spent enough time debugging the problem. I recently MFC'd the support for my device to -stable so I could use the machine on the network without it panicking on me. However, when Joe fixes the problem I will give it another shot [same machine has -CURRENT on another partition that I use for occasional hacking]. Thanks for the suggestions, though. Regards, -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: plug aue ethernet goes to panic
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 this problem sounds like a problem in revisions of various files. Please check that your kernel modules kernel are in sync. Do this by rebuilding the kernel and the modules from scratch. Also, after you've installed your kernel check that all your kernel files have been updated. Do you by any chance have a stale /modules or /boot/modules directory lying around? You should have only kernel modules in /boot/kernel*/ and NOT in /modules* or /boot/modules*. If the problem persists, please mail me the output of ident /sys/dev/usb/*.[ch] find /modules /boot -type f -ls Nick, You really should talk to Joe Karthauser. He's already confirmed that it *is* an issue in the code (and not any kind of misconfiguration on my part). I've already spent enough time debugging the problem. I recently MFC'd the support for my device to -stable so I could use the machine on the network without it panicking on me. However, when Joe fixes the problem I will give it another shot [same machine has -CURRENT on another partition that I use for occasional hacking]. Nick, I've introduced a probe and attach bug somewhere with aue, and I'm guessing with cue and kue too. I'm gradually getting to the bottom of it, but this is the first time I've gone near the attach code so it's taking me longer than it should. Joe msg37291/pgp0.pgp Description: PGP signature
RE: plug aue ethernet goes to panic
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 pointer = 0x10:0xc03f5180 frame pointer = 0x10:0xc03f5180 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) trap number = 12 panic: page fault Loading kernel is OK, it boots fine if my 'aue' ethernet is not plugged. When I plug aue to the PC, kernel panic with messages above. Also, kernel panics after usb0, uhub0 is attached (same reason). Does anybody have aue see this?, or I'm alone? 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. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: plug aue ethernet goes to panic
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 *is* a null pointer deref. Joe and I looked at this problem, and it seems a function called device_get_ivars() isn't doing its job in sys/dev/usb/usb_port.h. So the variable is getting filled with a NULL pointer for the iface element and is later deref'd. That's the limit of my debugging, and Joe is looking into the problem actively. Regards, -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: plug aue ethernet goes to panic
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 kernel.debug would be helpful as well. It *is* a null pointer deref. Joe and I looked at this problem, and it seems a function called device_get_ivars() isn't doing its job in sys/dev/usb/usb_port.h. So the variable is getting filled with a NULL pointer for the iface element and is later deref'd. That's the limit of my debugging, and Joe is looking into the problem actively. Well, if device_get_ivars() is returning a NULL pointer, then it probably means its parent bus device isn't setting up the ivars for the child device properly. As far as I understand, you can think of ivars as being per-device variables or state often used by a parent bus to set bus-specific information for a child device. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
