From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 15:15:27 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 E9CA61065677 for ; Tue, 12 Aug 2008 15:15:27 +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 671758FC20 for ; Tue, 12 Aug 2008 15:15:27 +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 m7CFFIbG079614; Tue, 12 Aug 2008 11:15:20 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: pluknet Date: Tue, 12 Aug 2008 11:11:36 -0400 User-Agent: KMail/1.9.7 References: <20080730113449.GD407@cdnetworks.co.kr> <200808111315.23879.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: <200808121111.37427.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Tue, 12 Aug 2008 11:15:20 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8018/Tue Aug 12 04:36:31 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,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: Tue, 12 Aug 2008 15:15:28 -0000 On Tuesday 12 August 2008 04:36:29 am pluknet wrote: > 2008/8/11 John Baldwin : > > 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=20 my > >> >> laptop. It didn't before, so it could cause no trouble. > >> >> > >> >> With ichss loaded, the kernel will panic 1-3 minutes after powerd h= as > >> >> 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? > >> > > >> > >> ehm,. I am not Ulrich Spoerlein, but I can help with this issue. > >> > >> my crashdump from kgdb and some debug info. > >> (ouch, I forgot to include it in my prev. mail > >>=20 http://lists.freebsd.org/pipermail/freebsd-stable/2008-August/044182.html ) > >> > >> wbr, > >> pluknet > >> > >> Unread portion of the kernel message buffer: > >> > >> > >> 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 > >> > >> #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_comma= nd.c:516 > >> #2 0xc045953a in db_command (last_cmdp=3D0xc07dcf14, cmd_table=3D0x0, > > dopager=3D1) > >> at /media/src-7/sys/ddb/db_command.c:413 > >> #3 0xc0459655 in db_command_loop () > > 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 ()=20 at /media/src-7/sys/i386/i386/exception.s:139 > >> #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=3D0xc3b= c7c00, > >> 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, > > namelen=3D4, > >> old=3D0x0, oldlenp=3D0x0, inkernel=3D0, new=3D0xbfbfe7c4, newlen= =3D4, > >> retval=3D0xe6592c10, flags=3D0)=20 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=20 drivers. > > */ > >> 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,= spec =3D {0, 0,=20 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 > > {0, > >> 0, 0, 0}}, {freq =3D 0, volts =3D 0, power =3D 0, lat =3D 0, dev= =3D 0x0,=20 spec =3D > > { > >> 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 0x7= fffffff, spec=20 =3D > > { > >> ----- and so on----- > >> > >> Also there are very unusual (and high) numbers in sysctl > > dev.cpu.0.freq_levels. > > > > Which cpufreq drivers are you using? Can you narrow down your panics (= and > > weird frequencies in the sysctl) to being caused by a specific cpufreq > > driver? >=20 > They are est/p4tcc/ichss. > hint.ichss.0.disbled=3D"1" helped me to avoid panics and those weired > freqs in dev.cpu. > Now it shows: > cpu0: on acpi0 > est0: on cpu0 > p4tcc0: on cpu0 > and dev.cpu.0.freq_levels are as expected (and as it was earlier > before this problem): > 1600/-1 1400/-1 1225/-1 1200/-1 1050/-1 1000/-1 875/-1 800/-1 700/-1 > 600/-1 525/-1 450/-1 375/-1 300/-1 225/-1 150/-1 75/-1 Try http://www.freebsd.org/~jhb/patches/cpufreq_order.patch ichss0 is only= =20 supposed to be used if you don't have est0, and this patch fixes that. I'm= =20 curious if you get panics if you have disable est0 and leave ichss0 enabled= =20 or if that works ok? =2D-=20 John Baldwin