Date: Wed, 13 Aug 2008 11:33:45 +0400 From: pluknet <pluknet@gmail.com> To: "John Baldwin" <jhb@freebsd.org> 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: <a31046fc0808130033n204b8a91ld6aa1a45987a5234@mail.gmail.com> In-Reply-To: <200808121111.37427.jhb@freebsd.org> References: <20080730113449.GD407@cdnetworks.co.kr> <200808111315.23879.jhb@freebsd.org> <a31046fc0808120136n7f892e79p57147635d40222d8@mail.gmail.com> <200808121111.37427.jhb@freebsd.org>
index | next in thread | previous in thread | raw e-mail
2008/8/12 John Baldwin <jhb@freebsd.org>: > 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 > 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="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 >> >> > 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 = 0x38 >> >> fault code = supervisor read, page not present >> >> instruction pointer = 0x20:0xc056cf46 >> >> stack pointer = 0x28:0xe6592ac8 >> >> frame pointer = 0x28:0xe6592ac8 >> >> code segment = base 0x0, limit 0xfffff, type 0x1b >> >> = DPL 0, pres 1, def32 1, gran 1 >> >> processor eflags = interrupt enabled, resume, IOPL = 0 >> >> current process = 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=-1010027648, dummy2=0, dummy3=0, >> >> dummy4=0xe6592860 "0،تأ") at /media/src-7/sys/ddb/db_command.c:516 >> >> #2 0xc045953a in db_command (last_cmdp=0xc07dcf14, cmd_table=0x0, >> > dopager=1) >> >> 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=12, code=0) >> >> at /media/src-7/sys/ddb/db_main.c:228 >> >> #5 0xc0575023 in kdb_trap (type=12, code=0, tf=0xe6592a88) >> >> at /media/src-7/sys/kern/subr_kdb.c:524 >> >> #6 0xc07460bf in trap_fatal (frame=0xe6592a88, eva=56) >> >> at /media/src-7/sys/i386/i386/trap.c:890 >> >> #7 0xc074636b in trap_pfault (frame=0xe6592a88, usermode=0, eva=56) >> >> at /media/src-7/sys/i386/i386/trap.c:812 >> >> #8 0xc0746d36 in trap (frame=0xe6592a88) >> >> at /media/src-7/sys/i386/i386/trap.c:490 >> >> #9 0xc072fd4b in calltrap () > at /media/src-7/sys/i386/i386/exception.s:139 >> >> #10 0xc056cf46 in device_is_attached (dev=0x0) >> >> at /media/src-7/sys/kern/subr_bus.c:2228 >> >> #11 0xc0512de7 in cf_set_method (dev=0xc3c9c880, level=0xc4525ef4, >> >> priority=100) at /media/src-7/sys/kern/kern_cpu.c:332 >> >> #12 0xc0511452 in cpufreq_curr_sysctl (oidp=0xc3c8bac0, arg1=0xc3bc7c00, >> >> arg2=0, req=0xe6592ba4) at cpufreq_if.h:32 >> >> ---Type <return> to continue, or q <return> to quit--- >> >> #13 0xc0554b67 in sysctl_root (oidp=Variable "oidp" is not available. >> >> ) >> >> at /media/src-7/sys/kern/kern_sysctl.c:1306 >> >> #14 0xc0554cd1 in userland_sysctl (td=0xc4245440, name=0xe6592c14, >> > namelen=4, >> >> old=0x0, oldlenp=0x0, inkernel=0, new=0xbfbfe7c4, newlen=4, >> >> retval=0xe6592c10, flags=0) > at /media/src-7/sys/kern/kern_sysctl.c:1401 >> >> #15 0xc0555a7c in __sysctl (td=0xc4245440, uap=0xe6592cfc) >> >> at /media/src-7/sys/kern/kern_sysctl.c:1336 >> >> #16 0xc07466d5 in syscall (frame=0xe6592d38) >> >> 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=0xc3c9c880, level=0xc4525ef4, >> >> priority=100) 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 > drivers. >> > */ >> >> 330 for (i = 0; i < level->rel_count; i++) { >> >> 331 set = &level->rel_set[i]; >> >> 332 if (!device_is_attached(set->dev)) { >> >> 333 error = ENXIO; >> >> 334 goto out; >> >> 335 } >> >> 336 >> >> (kgdb) p level.rel_count >> >> $1 = 1986356271 >> >> (kgdb) p i >> >> $2 = 0 >> >> (kgdb) p level.rel_set >> >> $3 = {{freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0, spec = {0, 0, > 0, >> >> 0}}, {freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0, spec = > {0, >> > 0, >> >> 0, 0}}, {freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0, spec = >> > {0, >> >> 0, 0, 0}}, {freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0, > spec = >> > { >> >> 0, 0, 0, 0}}, {freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0, >> >> spec = {0, 0, 0, 0}}, {freq = 0, volts = 0, power = 0, lat = 0, >> >> dev = 0x656e7552, spec = {828858701, 1162760014, 0, 134632492}}, { >> >> freq = 0, volts = 53, power = -1024, lat = -1, dev = 0x7fffffff, spec > = >> > { >> >> ----- 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? >> >> They are est/p4tcc/ichss. >> hint.ichss.0.disbled="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 [sorry, was far afk] > > Try http://www.freebsd.org/~jhb/patches/cpufreq_order.patch ichss0 is only > supposed to be used if you don't have est0, and this patch fixes that. I'm Works now as it should (i.e. ichss0 does not attach). > curious if you get panics if you have disable est0 and leave ichss0 enabled > or if that works ok? Yes, it works ok with hint.est.0.disabled="1" (with somewhat different freq's (and subjectively a bit slower even with max freq)): cpu0: <ACPI CPU> on acpi0 ichss0: <SpeedStep ICH> on cpu0 ichss0: enabling SpeedStep support p4tcc0: <CPU Frequency Thermal Control> on cpu0 acpi_acad0: <AC Adapter> on acpi0 $ sysctl dev.cpu dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 795 dev.cpu.0.freq_levels: 1590/-1 1391/-1 1192/-1 993/-1 795/-1 596/-1 397/-1 198/-1 dev.cpu.0.cx_supported: C1/1 C2/1 C3/85 C4/185 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% 0.00% Thanks, pluknethelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a31046fc0808130033n204b8a91ld6aa1a45987a5234>