Date: Tue, 12 Aug 2008 11:11:36 -0400 From: John Baldwin <jhb@freebsd.org> To: pluknet <pluknet@gmail.com> Cc: freebsd-stable@freebsd.org, Ulrich Spoerlein <uspoerlein@gmail.com> Subject: Re: cpufreq(4) panic on RELENG_7 (was: Re: Call for bfe(4) testers.) Message-ID: <200808121111.37427.jhb@freebsd.org> In-Reply-To: <a31046fc0808120136n7f892e79p57147635d40222d8@mail.gmail.com> References: <20080730113449.GD407@cdnetworks.co.kr> <200808111315.23879.jhb@freebsd.org> <a31046fc0808120136n7f892e79p57147635d40222d8@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 12 August 2008 04:36:29 am pluknet wrote: > 2008/8/11 John Baldwin <jhb@freebsd.org>: > > On Monday 11 August 2008 12:35:17 pm pluknet wrote: > >> 2008/8/11 John Baldwin <jhb@freebsd.org>: > >> > 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 <return> to continue, or q <return> 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: <ACPI CPU> on acpi0 > est0: <Enhanced SpeedStep Frequency Control> on cpu0 > p4tcc0: <CPU Frequency Thermal Control> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200808121111.37427.jhb>