From owner-freebsd-stable@FreeBSD.ORG Fri May 22 20:31:50 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83055106566B for ; Fri, 22 May 2009 20:31:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 18C868FC19 for ; Fri, 22 May 2009 20:31:49 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1M7bPA-000MXg-5A; Fri, 22 May 2009 23:31:48 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n4MKVfSp037228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 May 2009 23:31:42 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n4MKVfCo088901; Fri, 22 May 2009 23:31:41 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n4MKVeRr088899; Fri, 22 May 2009 23:31:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 22 May 2009 23:31:40 +0300 From: Kostik Belousov To: kmenzel@whisolutions.com Message-ID: <20090522203140.GD1927@deviant.kiev.zoral.com.ua> References: <4A16FC7B.7060401@icarz.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dfOvyYudzT1RPUKx" Content-Disposition: inline In-Reply-To: <4A16FC7B.7060401@icarz.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.1 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1M7bPA-000MXg-5A 223a56e38845da42fd297ca42ac7a146 X-Terabit: YES Cc: "freebsd-stable@FreeBSD.ORG" Subject: Re: devd panic on i386 7.2 Release with CARP X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 20:31:50 -0000 --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 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 metric 0= =20 > mtu 1500 > <118> options=3D2009 > <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 ) > <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 to continue, or q 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--