Hello Jeff, Sunday, July 22, 2007, 11:42:56 AM, you wrote: > On Sun, 22 Jul 2007, Chris Dionissopoulos wrote: >> Hello Jeff, >> >> Sunday, July 22, 2007, 3:55:08 AM, you wrote: >> >>> I have a patch available at: >> >>> http://people.freebsd.org/~jeff/ulehtt.diff >> >>> This resolves issues in the code that handles HTT enabled processors and >>> also adds some ULE information to bootverbose on SMP systems. Peter Wemm >>> has a seperate patch that fixes a bug where some amd64 cpus were still >>> being misidentified as HTT. Those of you with invalid loads either have >>> Hyper-threading CPUs or misidentified amd cores. You should expect >>> slightly poorer performance as long as your cores are misidentified but >>> the bad loads should be fixed. >> >>> I also believe that the buildkernel/world times are now significantly >>> improved. If this is not the case for you please send a mail. Any other >>> performance data is appreciated. >> >>> Thanks, >>> Jeff >> >> Load numbers seem correct, but, when enabling powerd(8) for power >> management I get kernel panic! In detail: > Hi Chris, > Can you tell me is there a panic message or is it a trap? Can you run > with INVARIANTS and WITNESS without WITNESS_SKIPSPIN? I appreciate the > detailed problem matrix. > Thanks, > Jeff ok, this panic is created from powerd(8) using "/etc/rc.d/powerd start" command: mail# kgdb kernel.debug /var/crash/vmcore.13 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: panic: critical_exit: td_critnest == 0 cpuid = 0 Uptime: 1m34s Physical memory: 2013 MB Dumping 172 MB: 157 141 125 109 93 77 61 45 29 13 #0 doadump () at pcpu.h:195 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc06469fe in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc0646cbb in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc0663224 in critical_exit () at kern_switch.c:185 #4 0xc083a2c0 in spinlock_exit () at /usr/src/sys/i386/i386/machdep.c:2348 #5 0xc063a2bd in _mtx_unlock_spin_flags (m=0xc0947000, opts=0, file=0xc08af6a3 "/usr/src/sys/kern/kern_cpu.c", line=303) at /usr/src/sys/kern/kern_mutex.c:246 #6 0xc061ad2a in cf_set_method (dev=0xc4d87e80, level=0xc55813b4, priority=100) at /usr/src/sys/kern/kern_cpu.c:303 #7 0xc06198d7 in cpufreq_curr_sysctl (oidp=0xc4d8b640, arg1=0xc4d8f400, arg2=0, req=0xe54b8ba4) at cpufreq_if.h:32 #8 0xc06504f7 in sysctl_root (oidp=Variable "oidp" is not available. ) at /usr/src/sys/kern/kern_sysctl.c:1306 #9 0xc0650625 in userland_sysctl (td=0xc4ef1660, name=0xe54b8c14, namelen=4, old=0x0, oldlenp=0x0, inkernel=0, new=0xbfbfe7a4, newlen=4, retval=0xe54b8c10, flags=0) at /usr/src/sys/kern/kern_sysctl.c:1401 #10 0xc0650a6c in __sysctl (td=0xc4ef1660, uap=0xe54b8cfc) at /usr/src/sys/kern/kern_sysctl.c:1336 #11 0xc0847673 in syscall (frame=0xe54b8d38) at /usr/src/sys/i386/i386/trap.c:1006 #12 0xc082ec90 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:196 #13 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) list *0xc0663224 0xc0663224 is in critical_exit (kern_switch.c:188). 183 184 td = curthread; 185 KASSERT(td->td_critnest != 0, 186 ("critical_exit: td_critnest == 0")); 187 #ifdef PREEMPTION 188 if (td->td_critnest == 1) { 189 td->td_critnest = 0; 190 if (td->td_owepreempt) { 191 td->td_critnest = 1; 192 thread_lock(td); (kgdb) list *0xc083a2c0 0xc083a2c0 is in spinlock_exit (/usr/src/sys/i386/i386/machdep.c:2349). 2344 { 2345 struct thread *td; 2346 2347 td = curthread; 2348 critical_exit(); 2349 td->td_md.md_spinlock_count--; 2350 if (td->td_md.md_spinlock_count == 0) 2351 intr_restore(td->td_md.md_saved_flags); 2352 } 2353 (kgdb) list *0xc063a2bd 0xc063a2bd is in _mtx_unlock_spin_flags (/usr/src/sys/kern/kern_mutex.c:247). 242 LOCK_LOG_LOCK("UNLOCK", &m->lock_object, opts, m->mtx_recurse, file, 243 line); 244 mtx_assert(m, MA_OWNED); 245 246 _rel_spin_lock(m); 247 } 248 249 /* 250 * The important part of mtx_trylock{,_flags}() 251 * Tries to acquire lock `m.' If this function is called on a mutex that (kgdb) list *0xc061ad2a 0xc061ad2a is in cf_set_method (/usr/src/sys/kern/kern_cpu.c:305). 300 if (cpu_id != pc->pc_cpuid) { 301 thread_lock(curthread); 302 sched_bind(curthread, pc->pc_cpuid); 303 thread_unlock(curthread); 304 } 305 CF_DEBUG("setting abs freq %d on %s (cpu %d)\n", set->freq, 306 device_get_nameunit(set->dev), PCPU_GET(cpuid)); 307 error = CPUFREQ_DRV_SET(set->dev, set); 308 if (cpu_id != pc->pc_cpuid) { 309 thread_lock(curthread); (kgdb) list *0xc06198d7 0xc06198d7 is in cpufreq_curr_sysctl (cpufreq_if.h:32). 27 static __inline int CPUFREQ_SET(device_t dev, const struct cf_level *level, 28 int priority) 29 { 30 kobjop_t _m; 31 KOBJOPLOOKUP(((kobj_t)dev)->ops,cpufreq_set); 32 return ((cpufreq_set_t *) _m)(dev, level, priority); 33 } 34 35 /** _at_brief Unique descriptor for the CPUFREQ_GET() method */ 36 extern struct kobjop_desc cpufreq_get_desc; (kgdb) But looking more carefully I found that I can reproduce PANIC anytime using command: mail# sysctl dev.cpu.0.freq=1596 -- where 1596 is valid Hz option as shown in: dev.cpu.0.freq: 1862 dev.cpu.0.freq_levels: 1862/89000 1629/77875 1596/63546 1396/55602 1197/47659 997/39716 798/31773 598/23829 399/15886 199/7943 I don't know if it helps much.. -- Best regards, Chris mailto:dionch_at_freemail.grReceived on Sun Jul 22 2007 - 08:44:06 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:15 UTC