From owner-freebsd-stable@FreeBSD.ORG Mon Aug 11 21:23:43 2008 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 6449310656A3 for ; Mon, 11 Aug 2008 21:23:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id C1C078FC08 for ; Mon, 11 Aug 2008 21:23:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m7BLNSRX069839; Mon, 11 Aug 2008 17:23:35 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: pluknet Date: Mon, 11 Aug 2008 13:15:23 -0400 User-Agent: KMail/1.9.7 References: <20080730113449.GD407@cdnetworks.co.kr> <200808111128.50840.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200808111315.23879.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Mon, 11 Aug 2008 17:23:35 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8009/Mon Aug 11 14:57:09 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-stable@freebsd.org, Ulrich Spoerlein Subject: Re: cpufreq(4) panic on RELENG_7 (was: Re: Call for bfe(4) testers.) 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: Mon, 11 Aug 2008 21:23:43 -0000 On Monday 11 August 2008 12:35:17 pm pluknet wrote: > 2008/8/11 John Baldwin : > > On Saturday 09 August 2008 07:16:37 am Ulrich Spoerlein wrote: > >> Hi John, > >> > >> I now figured out the "who", the "why" still eludes me. > >> > >> So, after your MFC of ichss.c on June 27th the device now attaches at = my > >> laptop. It didn't before, so it could cause no trouble. > >> > >> With ichss loaded, the kernel will panic 1-3 minutes after powerd has > >> been started (if I kill powerd early enough, it seems pretty stable). > >> > >> I'm now running a kernel from 2008-08-08 with > >> hint.ichss.0.disabled=3D"1" > > > > Ok. Can you get a crashdump from a crash? > > >=20 > ehm,. I am not Ulrich Spoerlein, but I can help with this issue. >=20 > my crashdump from kgdb and some debug info. > (ouch, I forgot to include it in my prev. mail > http://lists.freebsd.org/pipermail/freebsd-stable/2008-August/044182.html= ) >=20 > wbr, > pluknet >=20 > Unread portion of the kernel message buffer: >=20 >=20 > Fatal trap 12: page fault while in kernel mode > fault virtual address =3D 0x38 > fault code =3D supervisor read, page not present > instruction pointer =3D 0x20:0xc056cf46 > stack pointer =3D 0x28:0xe6592ac8 > frame pointer =3D 0x28:0xe6592ac8 > 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 2507 (powerd) > Physical memory: 1014 MB > Dumping 120 MB: 105 89 73 57 41 25 9 >=20 > #0 doadump () at pcpu.h:195 > 195 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:195 > #1 0xc0458f89 in db_fncall (dummy1=3D-1010027648, dummy2=3D0, dummy3=3D0, > dummy4=3D0xe6592860 "0=AC=CA=C3") at /media/src-7/sys/ddb/db_command.= c:516 > #2 0xc045953a in db_command (last_cmdp=3D0xc07dcf14, cmd_table=3D0x0,=20 dopager=3D1) > at /media/src-7/sys/ddb/db_command.c:413 > #3 0xc0459655 in db_command_loop ()=20 at /media/src-7/sys/ddb/db_command.c:466 > #4 0xc045b17c in db_trap (type=3D12, code=3D0) > at /media/src-7/sys/ddb/db_main.c:228 > #5 0xc0575023 in kdb_trap (type=3D12, code=3D0, tf=3D0xe6592a88) > at /media/src-7/sys/kern/subr_kdb.c:524 > #6 0xc07460bf in trap_fatal (frame=3D0xe6592a88, eva=3D56) > at /media/src-7/sys/i386/i386/trap.c:890 > #7 0xc074636b in trap_pfault (frame=3D0xe6592a88, usermode=3D0, eva=3D56) > at /media/src-7/sys/i386/i386/trap.c:812 > #8 0xc0746d36 in trap (frame=3D0xe6592a88) > at /media/src-7/sys/i386/i386/trap.c:490 > #9 0xc072fd4b in calltrap () at /media/src-7/sys/i386/i386/exception.s:1= 39 > #10 0xc056cf46 in device_is_attached (dev=3D0x0) > at /media/src-7/sys/kern/subr_bus.c:2228 > #11 0xc0512de7 in cf_set_method (dev=3D0xc3c9c880, level=3D0xc4525ef4, > priority=3D100) at /media/src-7/sys/kern/kern_cpu.c:332 > #12 0xc0511452 in cpufreq_curr_sysctl (oidp=3D0xc3c8bac0, arg1=3D0xc3bc7c= 00, > arg2=3D0, req=3D0xe6592ba4) at cpufreq_if.h:32 > ---Type to continue, or q to quit--- > #13 0xc0554b67 in sysctl_root (oidp=3DVariable "oidp" is not available. > ) > at /media/src-7/sys/kern/kern_sysctl.c:1306 > #14 0xc0554cd1 in userland_sysctl (td=3D0xc4245440, name=3D0xe6592c14,=20 namelen=3D4, > old=3D0x0, oldlenp=3D0x0, inkernel=3D0, new=3D0xbfbfe7c4, newlen=3D4, > retval=3D0xe6592c10, flags=3D0) at /media/src-7/sys/kern/kern_sysctl.= c:1401 > #15 0xc0555a7c in __sysctl (td=3D0xc4245440, uap=3D0xe6592cfc) > at /media/src-7/sys/kern/kern_sysctl.c:1336 > #16 0xc07466d5 in syscall (frame=3D0xe6592d38) > at /media/src-7/sys/i386/i386/trap.c:1035 > #17 0xc072fdb0 in Xint0x80_syscall () > at /media/src-7/sys/i386/i386/exception.s:196 > #18 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) f 11 > #11 0xc0512de7 in cf_set_method (dev=3D0xc3c9c880, level=3D0xc4525ef4, > priority=3D100) at /media/src-7/sys/kern/kern_cpu.c:332 > 332 if (!device_is_attached(set->dev)) { > (kgdb) list > 327 } > 328 > 329 /* Next, set any/all relative frequencies via their drive= rs.=20 */ > 330 for (i =3D 0; i < level->rel_count; i++) { > 331 set =3D &level->rel_set[i]; > 332 if (!device_is_attached(set->dev)) { > 333 error =3D ENXIO; > 334 goto out; > 335 } > 336 > (kgdb) p level.rel_count > $1 =3D 1986356271 > (kgdb) p i > $2 =3D 0 > (kgdb) p level.rel_set > $3 =3D {{freq =3D 0, volts =3D 0, power =3D 0, lat =3D 0, dev =3D 0x0, sp= ec =3D {0, 0, 0, > 0}}, {freq =3D 0, volts =3D 0, power =3D 0, lat =3D 0, dev =3D 0x0,= spec =3D {0,=20 0, > 0, 0}}, {freq =3D 0, volts =3D 0, power =3D 0, lat =3D 0, dev =3D 0= x0, spec =3D=20 {0, > 0, 0, 0}}, {freq =3D 0, volts =3D 0, power =3D 0, lat =3D 0, dev = =3D 0x0, spec =3D=20 { > 0, 0, 0, 0}}, {freq =3D 0, volts =3D 0, power =3D 0, lat =3D 0, dev= =3D 0x0, > spec =3D {0, 0, 0, 0}}, {freq =3D 0, volts =3D 0, power =3D 0, lat = =3D 0, > dev =3D 0x656e7552, spec =3D {828858701, 1162760014, 0, 134632492}}, { > freq =3D 0, volts =3D 53, power =3D -1024, lat =3D -1, dev =3D 0x7fff= ffff, spec =3D=20 { > ----- and so on----- >=20 > Also there are very unusual (and high) numbers in sysctl=20 dev.cpu.0.freq_levels. Which cpufreq drivers are you using? Can you narrow down your panics (and= =20 weird frequencies in the sysctl) to being caused by a specific cpufreq=20 driver? =2D-=20 John Baldwin