Date: Fri, 22 May 2009 23:31:40 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: kmenzel@whisolutions.com Cc: "freebsd-stable@FreeBSD.ORG" <freebsd-stable@freebsd.org> Subject: Re: devd panic on i386 7.2 Release with CARP Message-ID: <20090522203140.GD1927@deviant.kiev.zoral.com.ua> In-Reply-To: <4A16FC7B.7060401@icarz.com> References: <4A16FC7B.7060401@icarz.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--dfOvyYudzT1RPUKx
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, May 22, 2009 at 03:26:51PM -0400, Ken Menzel wrote:
>=20
> I am having a problem with one of my freebsd 7.2R boxes panicing on=20
> start of devd after upgrading to 7.2R. It is an old DELL 2400 dual=20
> processor. This is a build from completely refreshed sources.
>=20
> - generic kernel does not panic (built by me)
> - custom kernel does not panic with devd_enable=3D"NO" set in rc.conf, bu=
t=20
> !!! __ I can start devd AFTER booting by hand at the command prompt!
>=20
> - custom kernel (carp and more memory ) does panic if devd is started=20
> automatically by rc.d scripts (the default behaviour).=20
>=20
> Do I really need devd for anything if I am not using USB? Anyone have=20
> any idea of how to fix this?
>=20
> My kernel config is pretty simple, I am building a test i386 box with a=
=20
> carp kernel to try and repro this on another box, but that box is really=
=20
> slow.
>=20
> After booting I just run
> kes# devd
> devd: Setting hw.bus.devctl_disable to 0
> kes#
=2E..
> <118>lo0: flags=3D8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
> <118> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
> <118> inet6 ::1 prefixlen 128
> <118> inet 127.0.0.1 netmask 0xff000000
> <118>fxp0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0=
=20
> mtu 1500
> <118> options=3D2009<RXCSUM,VLAN_MTU,WOL_MAGIC>
> <118> ether 00:b0:d0:3e:c7:19
> <118> inet 207.99.22.32 netmask 0xffffff80 broadcast 207.99.22.127
> <118> media: Ethernet autoselect (100baseTX <full-duplex>)
> <118> status: active
> <118>add net default: gateway 207.99.22.1
> <118>Additional routing options:
> <118>.
> <118>Starting devd.
>=20
>=20
> Fatal trap 12: page fault while in kernel mode
> cpuid =3D 1; apic id =3D 00
> fault virtual address =3D 0x0
> fault code =3D supervisor read, page not present
> instruction pointer =3D 0x20:0xc0874488
> stack pointer =3D 0x28:0xf7bd0b68
> frame pointer =3D 0x28:0xf7bd0b68
> code segment =3D base 0x0, limit 0xfffff, type 0x1b
> =3D DPL 0, pres 1, def32 1, gran 1
> processor eflags =3D interrupt enabled, resume, IOPL =3D 0
> current process =3D 388 (devd)
> trap number =3D 12
> panic: page fault
> cpuid =3D 1
> Uptime: 2m12s
> Physical memory: 2035 MB
> Dumping 68 MB: 53 37 21 5
>=20
> Reading symbols from /boot/kernel/acpi.ko...Reading symbols from=20
> /boot/kernel/acpi.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/acpi.ko
> #0 doadump () at pcpu.h:196
> 196 __asm __volatile("movl %%fs:0,%0" : "=3Dr" (td));
> (kgdb) backtrace
> #0 doadump () at pcpu.h:196
> #1 0xc07e2a07 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c=
:418
> #2 0xc07e2cd9 in panic (fmt=3DVariable "fmt" is not available.
> ) at /usr/src/sys/kern/kern_shutdown.c:574
> #3 0xc0ae895c in trap_fatal (frame=3D0xf7bd0b28, eva=3D0)
> at /usr/src/sys/i386/i386/trap.c:939
> #4 0xc0ae8be0 in trap_pfault (frame=3D0xf7bd0b28, usermode=3D0, eva=3D0)
> at /usr/src/sys/i386/i386/trap.c:852
> #5 0xc0ae958c in trap (frame=3D0xf7bd0b28) at=20
> /usr/src/sys/i386/i386/trap.c:530
> #6 0xc0acdc9b in calltrap () at /usr/src/sys/i386/i386/exception.s:159
> #7 0xc0874488 in strlen (str=3D0x0) at /usr/src/sys/libkern/strlen.c:41
> #8 0xc080a46c in devread (dev=3D0xc548b900, uio=3D0xf7bd0c60, ioflag=3D0)
> at /usr/src/sys/kern/subr_bus.c:458
> #9 0xc07a6039 in giant_read (dev=3D0xc548b900, uio=3D0xf7bd0c60, ioflag=
=3D0)
> at /usr/src/sys/kern/kern_conf.c:414
> #10 0xc076cecd in devfs_read_f (fp=3D0xc58ba260, uio=3D0xf7bd0c60,
> cred=3D0xc5470300, flags=3D0, td=3D0xc56288c0)
> at /usr/src/sys/fs/devfs/devfs_vnops.c:1007
> #11 0xc081be86 in dofileread (td=3D0xc56288c0, fd=3D3, fp=3D0xc58ba260,
> auio=3D0xf7bd0c60, offset=3D-1, flags=3D0) at file.h:245
> #12 0xc081c1f8 in kern_readv (td=3D0xc56288c0, fd=3D3, auio=3D0xf7bd0c60)
> at /usr/src/sys/kern/sys_generic.c:193
> #13 0xc081c2df in read (td=3D0xc56288c0, uap=3D0xf7bd0cfc)
> at /usr/src/sys/kern/sys_generic.c:109
> ---Type <return> to continue, or q <return> to quit---
> #14 0xc0ae8f35 in syscall (frame=3D0xf7bd0d38)
> at /usr/src/sys/i386/i386/trap.c:1090
> #15 0xc0acdd00 in Xint0x80_syscall () at=20
> /usr/src/sys/i386/i386/exception.s:255
> #16 0x00000033 in ?? ()
> Previous frame inner to this frame (corrupt stack?)
> (kgdb)
The strlen was supplied NULL pointer. This means that n1->dei_data
is NULL. Brief looking over the RELENG_7 code does not reveal any
caller of devctl_queue_data outside subr_bus.c, and all uses inside
subr_bus.c seems to be safe.
Added options in the config cannot affect this behaviour, I believe.
You may add check at the start of the devctl_queue_data() to verify
that data !=3D NULL, and panic when it is. This way, we will see where
it happen.
--dfOvyYudzT1RPUKx
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (FreeBSD)
iEYEARECAAYFAkoXC6wACgkQC3+MBN1Mb4izcQCg3qmBm5GdgSFnTwemuof5GAP7
I3gAoIOnjp7o8LKxHXY0mlSxJgT2XT5L
=7Sm7
-----END PGP SIGNATURE-----
--dfOvyYudzT1RPUKx--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090522203140.GD1927>