Re: plug aue ethernet goes to panic

2002-04-15 Thread Nick Hibma


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

Thanks.

Nick


On Sat, 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.

 Regards,


-- 
[EMAIL PROTECTED]  http://www.van-laarhoven.org/
[EMAIL PROTECTED]http://www.etla.net/~n_hibma/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



RE: plug aue ethernet goes to panic

2002-04-15 Thread Makoto Matsushita


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

2002-04-15 Thread Will Andrews

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

2002-04-15 Thread Josef Karthauser

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

2002-04-15 Thread Gerhard Sittig

On Mon, Apr 15, 2002 at 21:57 +0900, Makoto Matsushita wrote:
 
 But unfortunately, my kernel.debug prints
 
   uhub0: device problem, disabling port 2
 
 and doesn't panic :-(

Oh, how I know this message ... :)

Does http://www.FreeBSD.org/cgi/query-pr.cgi?pr=33004 help you
here?  It has patches for uhci as well as ohci to make this
message disappear.  At least it worked for me and the PR's
originator.


virtually yours   82D1 9B9C 01DC 4FB4 D7B4  61BE 3F49 4F77 72DE DA76
Gerhard Sittig   true | mail -s get gpg key [EMAIL PROTECTED]
-- 
 If you don't understand or are scared by any of the above
 ask your parents or an adult to help you.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



RE: plug aue ethernet goes to panic

2002-04-13 Thread John Baldwin


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

2002-04-13 Thread Will Andrews

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

2002-04-13 Thread John Baldwin


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