Date: Mon, 11 Aug 2008 13:15:23 -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: <200808111315.23879.jhb@freebsd.org> In-Reply-To: <a31046fc0808110935s5f84afd1x5d82c739b9accf58@mail.gmail.com> References: <20080730113449.GD407@cdnetworks.co.kr> <200808111128.50840.jhb@freebsd.org> <a31046fc0808110935s5f84afd1x5d82c739b9accf58@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 = 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 <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,=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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200808111315.23879.jhb>