sorry, I'm late. the -current has the same problem. here is coredump capoor-daemon dumped core - see /var/crash/vmcore.2 Thu Nov 24 15:46:46 CST 2011 FreeBSD capoor-daemon 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r+8692e3b-dirty: Thu Nov 24 15:34:53 CST 2011 root_at_capoor-daemon:/usr/obj/usr/src/sys/MYKERNEL amd64 panic: 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 "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: <118>Nov 24 15:44:10 capoor-daemon syslogd: exiting on signal 15 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop...Syncing disks, vnodes remaining...6 3 1 1 1 0 0 done All buffers synced. Uptime: 50s Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0xffffffff8075e19b stack pointer = 0x28:0xffffff811c0e29b0 frame pointer = 0x28:0xffffff811c0e29c0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1555 (reboot) Reading symbols from /boot/kernel/uplcom.ko...Reading symbols from /boot/kernel/uplcom.ko.symbols...done. done. Loaded symbols for /boot/kernel/uplcom.ko Reading symbols from /boot/kernel/ucom.ko...Reading symbols from /boot/kernel/ucom.ko.symbols...done. done. Loaded symbols for /boot/kernel/ucom.ko #0 doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:261 261 if (textdump && textdump_pending) { (kgdb) #0 doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:261 #1 0xffffffff802d0fd0 in db_dump (dummy=Variable "dummy" is not available. ) at /usr/src/sys/ddb/db_command.c:537 #2 0xffffffff802d0901 in db_command (last_cmdp=0xffffffff80b08340, cmd_table=Variable "cmd_table" is not available. ) at /usr/src/sys/ddb/db_command.c:448 #3 0xffffffff802d0b50 in db_command_loop () at /usr/src/sys/ddb/db_command.c:501 #4 0xffffffff802d2c84 in db_trap (type=Variable "type" is not available. #5 0xffffffff804e4fb1 in kdb_trap (type=9, code=0, tf=0xffffff811c0e2900) at /usr/src/sys/kern/subr_kdb.c:625 #6 0xffffffff80744072 in trap_fatal (frame=0xffffff811c0e2900, eva=0) at /usr/src/sys/amd64/amd64/trap.c:814 #7 0xffffffff8074467b in trap (frame=0xffffff811c0e2900) at /usr/src/sys/amd64/amd64/trap.c:617 #8 0xffffffff8072e7d3 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:228 #9 0xffffffff8075e19b in uncore_pcpu_fini (md=0xfffffe0004b03c00, cpu=Variable "cpu" is not available. ) at cpufunc.h:353 #10 0xffffffff802fc5ea in load (module=Variable "module" is not available. ) at /usr/src/sys/dev/hwpmc/hwpmc_mod.c:4885 #11 0xffffffff804b803a in syscall_module_handler (mod=0xfffffe00017b9b00, what=Variable "what" is not available. ) at /usr/src/sys/kern/kern_syscalls.c:185 #12 0xffffffff8049b30f in module_shutdown (arg1=Variable "arg1" is not available. ) at /usr/src/sys/kern/kern_module.c:104 #13 0xffffffff804adc36 in kern_reboot (howto=0) at /usr/src/sys/kern/kern_shutdown.c:446 #14 0xffffffff804ae3dc in sys_reboot (td=0xfffffe00b219b460, uap=0xffffff811c0e2bc0) at /usr/src/sys/kern/kern_shutdown.c:188 #15 0xffffffff80743887 in amd64_syscall (td=0xfffffe00b219b460, traced=0) at subr_syscall.c:131 #16 0xffffffff8072eab7 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:387 #17 0x0000000800882bbc in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) 在 2011年11月18日 上午2:52，Davide Italiano <davide.italiano_at_gmail.com> 写道： > On Tue, Nov 15, 2011 at 3:44 AM, Paul Ambrose <ambrosehua_at_gmail.com> wrote: >> hi, I apply your patch on this >> [root_at_capoor-daemon /usr/src]# git show >> commit 4ec1d958bad5e78bcd3cc61a0da6b5a1302f8ec2 >> Author: kensmith <kensmith_at_FreeBSD.org> >> Date: Mon Nov 14 00:45:25 2011 +0000 >> >> The releng/9.0 release branch has been created so convert stable/9 over >> to our standard "Politically Correct" name for the balance of the >> 9.0-RELEASE >> release cycle. >> >> Approved by: re (implicit) >> >> when my machine shutdown in my absence yesterday evening, I find a >> kernel oops this morning,(sorry, just printf, I can not get a kernel >> dump) >> the kernel says it is at uncore_pcpu_fini+0x5b >> I check the source, and it is at >> static int >> uncore_pcpu_fini(struct pmc_mdep *md, int cpu) >> { >> ..... >> for (n = 0; n < npmc; n++) >> wrmsr(UCP_EVSEL0 + n, 0); //here >> ..... >> here is my cpu type, and build hwpmc into kernel >> >> Copyright (c) 1992-2011 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >> The Regents of the University of California. All rights reserved. >> FreeBSD is a registered trademark of The FreeBSD Foundation. >> FreeBSD 9.0-PRERELEASE #0 r+4ec1d95-dirty: Mon Nov 14 15:31:45 CST 2011 >> root_at_capoor-daemon:/usr/obj/usr/src/sys/MYKERNEL amd64 >> CPU: Intel(R) Core(TM) i5-2300 CPU _at_ 2.80GHz (2793.02-MHz K8-class CPU) >> >> I will try to apply this to current to see if this is reproduced. >> >> 2011/11/14 Attilio Rao <attilio_at_freebsd.org>: >>> 2011/11/13 Davide Italiano <davide.italiano_at_gmail.com>: >>>> On Sun, Nov 13, 2011 at 9:52 PM, Davide Italiano >>>> <davide.italiano_at_gmail.com> wrote: >>>>> Good evening folks. >>>>> During last days I've written a patch to add sandy bridge support to >>>>> hwpmc. Until now, the most recent Intel processor microarchitecture >>>>> supported was Westmere. >>>>> Testing is appreciated, in order to see if there's something that have >>>>> to be fixed. >>>>> You can find the diff here: http://davit.altervista.rg/hwpmc_sandy_bridge.diff >>>>> >>>>> I'd like to thanks a lot attilio_at_ that helped me to fix a bug and gnn_at_ >>>>> and fabient_at_ for the useful suggestions. >>>>> >>>>> Best >>>>> >>>>> Davide >>>>> >>>> >>>> Sorry, bad link. It should be: >>>> http://davit.altervista.org/hwpmc_sandy_bridge.diff >>> >>> I can perform some small cleanups and likely test it too. >>> >>> If Fabien or George can review it I'm fine with committing as long as >>> all that is settled. >>>+ >>> Attilio >>> >>> >>> -- >>> Peace can only be achieved by understanding - A. Einstein >>> _______________________________________________ >>> freebsd-current_at_freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" >>> >> > > Have you tried on -current? If yes, what are the results? > Can you provide a kernel dump and/or the instruction to reproduce this bug? > > Best > > Davide >Received on Thu Nov 24 2011 - 07:03:50 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:21 UTC