From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 29 13:22:57 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8AED816A418 for ; Sun, 29 Jul 2007 13:22:57 +0000 (UTC) (envelope-from ytriffy@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by mx1.freebsd.org (Postfix) with ESMTP id DB8D813C45B for ; Sun, 29 Jul 2007 13:22:56 +0000 (UTC) (envelope-from ytriffy@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so1053075uge for ; Sun, 29 Jul 2007 06:22:55 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; b=Vdlckk+RESs/ZIAGf54Uf/CWr50Pkkw1q/vYVwmNJFLcZcefR820Es/nMFxaHj5BzMqwyPTM68zovikwojdIssePXQD8K000isG4CQYPna+SE9nK76FX5mX1Qk0J+xDpbL7Akaf8dD/oR7TpkQNEx+fgfNktV/BuBc9YhQmKDxY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; b=pSuGc7mpxBBcnRL8mONJoxLXver1Vrbdifh/JmPXYE1jvmxx9pnuPLZKp+JwdvD/ulXb4FPyh0WY3DiK+zCTeBHaByyD51aRjt5xy99auujdtYO9GeQgggd4CpMLa68ANr3nqAE5+yuPtp3vTc8S0j5xye+qgJP5draWA3qO1U8= Received: by 10.66.219.11 with SMTP id r11mr4438796ugg.1185713659117; Sun, 29 Jul 2007 05:54:19 -0700 (PDT) Received: from freelanc.dubki.ru ( [80.86.254.135]) by mx.google.com with ESMTPS id c25sm3722780ika.2007.07.29.05.54.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 29 Jul 2007 05:54:18 -0700 (PDT) Message-ID: <46AC8DEE.4010509@gmail.com> Date: Sun, 29 Jul 2007 16:54:06 +0400 From: Slava Gonahchan User-Agent: Thunderbird 2.0.0.0 (X11/20070722) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Sun, 29 Jul 2007 14:28:40 +0000 Cc: Subject: Fatal trap 12: page fault while in kernel mode.Need help. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2007 13:22:57 -0000 Hello. Trap 12 occured when I rebooted PC. Sending you backtrace. My system: amd64 3200+ Venice, MB ECS nForce4 A939,Samsung 250GB and WD 250 GB, 2 memory banks 512MB each, videocard: Geforce 6600gt 128MB, NIC on realtek chip, sound card cirrus logic cs4281. It's very unstable, crashes happen every day, so I'm hoping you would say why(any hints what hardware may cause it). How to repeat it? I don't know. It happened once during reboot process. [root@freelanc /var]# uname -a FreeBSD freelanc.dubki.ru 6.2-STABLE-200706 FreeBSD 6.2-STABLE-200706 #1: Mon Jul 23 13:34:27 MSD 2007 root@freelanc.dubki.ru:/usr/obj/usr/src/sys/DEBUGGERKERN i386 [root@freelanc /usr/obj/usr/src/sys/DEBUGGERKERN]# kgdb kernel.debug /var/crash/vmcore.3 kgdb: kvm_nlist(_stopped_cpus): kgdb: kvm_nlist(_stoppcbs): [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: <118>Jul 25 14:06:32 freelanc syslogd: exiting on signal 15 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...6 5 3 1 0 0 done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done All buffers synced. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x4 fault code = supervisor read, page not present instruction pointer = 0x20:0xc058a4e0 stack pointer = 0x28:0xe9455c48 frame pointer = 0x28:0xe9455c58 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 = 44922 (reboot) panic: from debugger Uptime: 2h45m36s Dumping 1022 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 1022MB (261600 pages) 1006 990 974 958 942 926 910 894 878 862 846 830 814 798 782 766 750 734 718 702 686 670 654 638 622 606 590 574 558 542 526 510 494 478 462 446 430 414 398 382 366 350 334 318 302 286 270 254 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14 #0 doadump () at pcpu.h:165 165 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc053d916 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc053dbdc in panic (fmt=0xc06f5278 "from debugger") at /usr/src/sys/kern/kern_shutdown.c:565 #3 0xc045361d in db_panic (addr=-1067932448, have_addr=0, count=-1, modif=0xe9455a74 "") at /usr/src/sys/ddb/db_command.c:438 #4 0xc04535b4 in db_command (last_cmdp=0xc0766784, cmd_table=0x0, aux_cmd_tablep=0xc0728e90, aux_cmd_tablep_end=0xc0728e94) at /usr/src/sys/ddb/db_command.c:350 #5 0xc045367c in db_command_loop () at /usr/src/sys/ddb/db_command.c:458 #6 0xc0455291 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:222 #7 0xc0556a2b in kdb_trap (type=12, code=0, tf=0xe9455c08) at /usr/src/sys/kern/subr_kdb.c:473 #8 0xc06cba6c in trap_fatal (frame=0xe9455c08, eva=4) at /usr/src/sys/i386/i386/trap.c:828 #9 0xc06cb7d7 in trap_pfault (frame=0xe9455c08, usermode=0, eva=4) at /usr/src/sys/i386/i386/trap.c:745 #10 0xc06cb3f1 in trap (frame= {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -381330360, tf_esi = -993547624, tf_ebp = -381330344, tf_isp = -381330380, tf_ebx = 0, tf_edx = -992513384, tf_ecx = 4, tf_eax = -950651024, tf_trapno = 12, tf_err = 0, tf_eip = -1067932448, tf_cs = 32, tf_eflags = 590338, tf_esp = 0, tf_ss = -992305712}) at /usr/src/sys/i386/i386/trap.c:435 #11 0xc06b8b1a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #12 0xc058a4e0 in cache_purgevfs (mp=0xc4d77298) at /usr/src/sys/kern/vfs_cache.c:622 #13 0xc0591f29 in dounmount (mp=0xc4d77298, flags=524288, td=0xc62ce300) at /usr/src/sys/kern/vfs_mount.c:1214 #14 0xc0597d0a in vfs_unmountall () at /usr/src/sys/kern/vfs_subr.c:2837 #15 0xc053d807 in boot (howto=0) at /usr/src/sys/kern/kern_shutdown.c:391 #16 0xc053d2a2 in reboot (td=0xc62ce300, uap=0xc7563770) at /usr/src/sys/kern/kern_shutdown.c:169 #17 0xc06cbdbb in syscall (frame= {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 2, tf_esi = 18, tf_ebp = -1077941304, tf_isp = -381330076, tf_ebx = 0, tf_edx = -1, tf_ecx = 672491264, tf_eax = 55, tf_trapno = 12, tf_err = 2, tf_eip = 671802263, tf_cs = 51, tf_eflags = 662, tf_esp = -1077941380, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:983 #18 0xc06b8b6f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200 #19 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) up 19 #19 0x00000033 in ?? () (kgdb) down 1 #18 0xc06b8b6f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200 200 call syscall Current language: auto; currently asm (kgdb) down 1 #17 0xc06cbdbb in syscall (frame= {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 2, tf_esi = 18, tf_ebp = -1077941304, tf_isp = -381330076, tf_ebx = 0, tf_edx = -1, tf_ecx = 672491264, tf_eax = 55, tf_trapno = 12, tf_err = 2, tf_eip = 671802263, tf_cs = 51, tf_eflags = 662, tf_esp = -1077941380, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:983 983 error = (*callp->sy_call)(td, args); Current language: auto; currently c (kgdb) p *callp $1 = {sy_narg = 65537, sy_call = 0xc053d258 , sy_auevent = 20} (kgdb) p *callp->sy_call $2 = {int (struct thread *, void *)} 0xc053d258 (kgdb) p td $3 = (struct thread *) 0xc62ce300 (kgdb) p args $4 = {0, 9, -994250272, -1077941388, 0, 0, 3, 0} (kgdb) down 1 #16 0xc053d2a2 in reboot (td=0xc62ce300, uap=0xc7563770) at /usr/src/sys/kern/kern_shutdown.c:169 169 boot(uap->opt); (kgdb) p uap $5 = (struct reboot_args *) 0xc7563770 (kgdb) p uap->opt $6 = 2 (kgdb) down 1 #15 0xc053d807 in boot (howto=0) at /usr/src/sys/kern/kern_shutdown.c:391 391 vfs_unmountall(); (kgdb) down 1 #14 0xc0597d0a in vfs_unmountall () at /usr/src/sys/kern/vfs_subr.c:2837 2837 error = dounmount(mp, MNT_FORCE, td); (kgdb) p mp $7 = (struct mount *) 0xc4d77298 (kgdb) p td $8 = (struct thread *) 0xc62ce300 (kgdb) down 1 #13 0xc0591f29 in dounmount (mp=0xc4d77298, flags=524288, td=0xc62ce300) at /usr/src/sys/kern/vfs_mount.c:1214 1214 cache_purgevfs(mp); /* remove cache entries for this file sys */ (kgdb) down 1 #12 0xc058a4e0 in cache_purgevfs (mp=0xc4d77298) at /usr/src/sys/kern/vfs_cache.c:622 622 for (ncp = LIST_FIRST(ncpp); ncp != 0; ncp = nnp) { (kgdb) p ncp $9 = (struct namecache *) 0x4 (kgdb) p ncpp $10 = (struct nchashhead *) 0xc4c7aa98 (kgdb) down 1 #11 0xc06b8b1a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 139 call trap Current language: auto; currently asm (kgdb) down 1 #10 0xc06cb3f1 in trap (frame= {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -381330360, tf_esi = -993547624, tf_ebp = -381330344, tf_isp = -381330380, tf_ebx = 0, tf_edx = -992513384, tf_ecx = 4, tf_eax = -950651024, tf_trapno = 12, tf_err = 0, tf_eip = -1067932448, tf_cs = 32, tf_eflags = 590338, tf_esp = 0, tf_ss = -992305712}) at /usr/src/sys/i386/i386/trap.c:435 435 (void) trap_pfault(&frame, FALSE, eva); Current language: auto; currently c (kgdb) p frame $11 = {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -381330360, tf_esi = -993547624, tf_ebp = -381330344, tf_isp = -381330380, tf_ebx = 0, tf_edx = -992513384, tf_ecx = 4, tf_eax = -950651024, tf_trapno = 12, tf_err = 0, tf_eip = -1067932448, tf_cs = 32, tf_eflags = 590338, tf_esp = 0, tf_ss = -992305712} (kgdb) p eva $12 = 4 (kgdb) down 1 #9 0xc06cb7d7 in trap_pfault (frame=0xe9455c08, usermode=0, eva=4) at /usr/src/sys/i386/i386/trap.c:745 745 trap_fatal(frame, eva); (kgdb) down 1 #8 0xc06cba6c in trap_fatal (frame=0xe9455c08, eva=4) at /usr/src/sys/i386/i386/trap.c:828 828 if (kdb_trap(type, 0, frame)) { (kgdb) p type $13 = 12 (kgdb) down 1 #7 0xc0556a2b in kdb_trap (type=12, code=0, tf=0xe9455c08) at /usr/src/sys/kern/subr_kdb.c:473 473 handled = kdb_dbbe->dbbe_trap(type, code); (kgdb) p kdb_dbbe $14 = (struct kdb_dbbe *) 0xc072f0e0 (kgdb) p kdb_dbbe->dbbe_trap $15 = (dbbe_trap_f *) 0xc04551ac (kgdb) p type $16 = 12 (kgdb) p code $17 = 0 (kgdb) down 1 #6 0xc0455291 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:222 222 db_command_loop(); (kgdb) down 1 #5 0xc045367c in db_command_loop () at /usr/src/sys/ddb/db_command.c:458 458 db_command(&db_last_command, db_command_table, (kgdb) p &db_last_command $18 = (struct command **) 0xc0766784 (kgdb) p db_command_table $19 = {{name = 0xc0726d8d "print", fcn = 0xc0453e44 , flag = 0, more = 0x0}, {name = 0xc0707446 "p", fcn = 0xc0453e44 , flag = 0, more = 0x0}, {name = 0xc06f521d "examine", fcn = 0xc0453b74 , flag = 256, more = 0x0}, { name = 0xc06f3248 "x", fcn = 0xc0453b74 , flag = 256, more = 0x0}, {name = 0xc06f5225 "search", fcn = 0xc0453f44 , flag = 257, more = 0x0}, { name = 0xc06fc7c7 "set", fcn = 0xc0456d98 , flag = 1, more = 0x0}, {name = 0xc071c1dc "write", fcn = 0xc045714c , flag = 258, more = 0x0}, {name = 0xc070470c "w", fcn = 0xc045714c , flag = 258, more = 0x0}, { name = 0xc0711df9 "delete", fcn = 0xc045312c , flag = 0, more = 0x0}, {name = 0xc06f3296 "d", fcn = 0xc045312c , flag = 0, more = 0x0}, {name = 0xc06f522c "break", fcn = 0xc0453144 , flag = 0, more = 0x0}, { name = 0xc06f5232 "dwatch", fcn = 0xc0457014 , flag = 0, more = 0x0}, {name = 0xc06f5233 "watch", fcn = 0xc045702c , flag = 2, more = 0x0}, { name = 0xc06f5239 "dhwatch", fcn = 0xc04570e4 , flag = 0, more = 0x0}, {name = 0xc06f523a "hwatch", fcn = 0xc0457118 , flag = 0, more = 0x0}, { name = 0xc0721ca0 "step", fcn = 0xc0456438 , flag = 0, more = 0x0}, {name = 0xc06f55e4 "s", fcn = 0xc0456438 , flag = 0, more = 0x0}, { name = 0xc06f5241 "continue", fcn = 0xc045653c , flag = 0, more = 0x0}, {name = 0xc0713305 "c", fcn = 0xc045653c , flag = 0, more = 0x0}, { name = 0xc06f524a "until", fcn = 0xc04564a0 , flag = 0, more = 0x0}, {name = 0xc06f5250 "next", fcn = 0xc04564e8 , flag = 0, more = 0x0}, { name = 0xc070d7da "match", fcn = 0xc04564e8 , flag = 0, more = 0x0}, {name = 0xc070882b "trace", fcn = 0xc0453a4c , flag = 1, more = 0x0}, { name = 0xc06f5255 "alltrace", fcn = 0xc0453b20 , flag = 0, more = 0x0}, {name = 0xc07249cf "where", fcn = 0xc0453a4c , flag = 1, more = 0x0}, { name = 0xc06f525e "bt", fcn = 0xc0453a4c , flag = 1, more = 0x0}, {name = 0xc071aa99 "call", fcn = 0xc04536b0 , flag = 1, more = 0x0}, {name = 0xc06f5261 "show", fcn = 0, flag = 0, more = 0xc072edc0}, {name = 0xc07126a2 "ps", fcn = 0xc0455784 , flag = 0, more = 0x0}, {name = 0xc06f5266 "gdb", fcn = 0xc0453a18 , flag = 0, more = 0x0}, { name = 0xc06fc600 "reset", fcn = 0xc0453920 , flag = 0, more = 0x0}, {name = 0xc06f526a "kill", fcn = 0xc04537d8 , flag = 1, more = 0x0}, {name = 0xc06f526f "watchdog", fcn = 0xc045392c , flag = 0, more = 0x0}, { name = 0xc070887d "thread", fcn = 0xc0456a10 , flag = 1, more = 0x0}, {name = 0x0, fcn = 0, flag = 0, more = 0x0}} (kgdb) down 1 #4 0xc04535b4 in db_command (last_cmdp=0xc0766784, cmd_table=0x0, aux_cmd_tablep=0xc0728e90, aux_cmd_tablep_end=0xc0728e94) at /usr/src/sys/ddb/db_command.c:350 350 (*cmd->fcn)(addr, have_addr, count, modif); (kgdb) p addr $20 = -1067932448 (kgdb) p have_addr $21 = 0 (kgdb) p count $22 = -1 (kgdb) p modif $23 = "\000ZEИDыjю\214ZEИ\220ZEИ\211\a\000\000═ZEИ\"LJю\000\000\000\000\000╤╙д\2005yю\r\000\000\000\2005yю\r\000\000\000\001\000\000\000лZEИ\213рjюлZEИ╓рjю\000@Ёд@\036wюx\000\000\000\200pvю\f\000\000\000ЛZEИ Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB50216A420 for ; Mon, 30 Jul 2007 08:24:48 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.freebsd.org (Postfix) with ESMTP id 7067913C468 for ; Mon, 30 Jul 2007 08:24:48 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: by ug-out-1314.google.com with SMTP id o4so1173759uge for ; Mon, 30 Jul 2007 01:24:47 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=googlemail.com; s=beta; h=domainkey-signature:received:received:subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer; b=b9NRlVGKE7ilF1FcaAIvg758Kker9aOWYMnbCpW48nCdX3evXoo8WDTDPdvImVN+U83mZ4fjOm3BM/G/PFqSe9a83beAPDWWiOjTCguZxCOPRoHl1M3PNSTT4zJ7BbmedFSiH6KGNwvqrtTMljg5LMFvTVkqrsNANPPNtvbOGQI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=beta; h=received:subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer; b=UI1JmHT4H98NMZdVMiKyQP+JzT/htUd2bD6J0yew8gFIvM/me1IU4Ow4pQXZSiUsSUb8uYa4QLuE3YKTvK+ZFSZMxuSy1OvvkFYoMhkcDXqnUpCmXUG/FGWUz1ZFeXaS2JU8z7Oow0IR4iUhyXMSO06uMNiOfCeVqPioaYJnWWY= Received: by 10.82.182.1 with SMTP id e1mr3822040buf.1185783886813; Mon, 30 Jul 2007 01:24:46 -0700 (PDT) Received: from ?127.0.0.1? ( [217.206.187.79]) by mx.google.com with ESMTPS id h6sm11596175nfh.2007.07.30.01.24.45 (version=SSLv3 cipher=RC4-MD5); Mon, 30 Jul 2007 01:24:45 -0700 (PDT) From: Tom Evans To: Peter Jeremy In-Reply-To: <20070728075553.GW1152@turion.vk2pj.dyndns.org> References: <200707271513.48639.sharadc@niksun.com> <20070727102027.GH1152@turion.vk2pj.dyndns.org> <1185553955.1457.8.camel@localhost> <20070728075553.GW1152@turion.vk2pj.dyndns.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-lyV5EA5D10ilnKybwVv1" Date: Mon, 30 Jul 2007 09:24:43 +0100 Message-Id: <1185783883.1444.3.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.2 FreeBSD GNOME Team Port Cc: FreeBSD Hackers Subject: Re: gcc -m32 option on amd64. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2007 08:24:48 -0000 --=-lyV5EA5D10ilnKybwVv1 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2007-07-28 at 17:55 +1000, Peter Jeremy wrote: > On 2007-Jul-27 17:32:35 +0100, Tom Evans wrote= : > >gcc on amd64 is capable of generating i386 code, but ld on amd64 is > >incapable of linking i386 code together without serious amounts of work. >=20 > Can you elaborate on what you mean by "incapable of linking i386 code"? > The stock ld can definitely link i386 code: > turion% ld -V > GNU ld version 2.15 [FreeBSD] 2004-05-23 > Supported emulations: > elf_i386_fbsd > elf_x86_64_fbsd > turion%=20 >=20 > There is a problem that the 32-bit pathnames on FreeBSD/amd64 are > different to the 32-bit pathnames on FreeBSD/i386 (ie an i386 > executable built on amd64 will point to /libexec/ld-elf32.so.1, rather > than /libexec/ld-elf.so.1) so the result won't execute on a > FreeBSD/i386 box - but I don't see that as a problem with ld, rather > the configuration. >=20 Sure. By 'incapable of linking i386 code' I mean that the default toolchain of gcc invoking ld to assemble libraries and object files into executables is incapable of doing so when compiling i386 code. I say without serious amounts of work because, as you point out, it is possible to do. Any other english sentences you need explaining? --=-lyV5EA5D10ilnKybwVv1 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQBGraBIlcRvFfyds/cRAjv5AJ9rHZKoMvjXYD1eiJMiY6B2LHDKAACgu6p8 fVuRuIgN28qibHLyhGK69YQ= =2Bor -----END PGP SIGNATURE----- --=-lyV5EA5D10ilnKybwVv1-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 30 09:28:46 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2EC416A418 for ; Mon, 30 Jul 2007 09:28:46 +0000 (UTC) (envelope-from gahr@gahr.ch) Received: from cpanel03.rubas-s03.net (cpanel03.rubas-s03.net [195.182.222.73]) by mx1.freebsd.org (Postfix) with ESMTP id 79FEF13C483 for ; Mon, 30 Jul 2007 09:28:46 +0000 (UTC) (envelope-from gahr@gahr.ch) Received: from 85-218-3-50.dclient.lsne.ch ([85.218.3.50] helo=gahrtop.localhost) by cpanel03.rubas-s03.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1IFRYT-0004rx-0T; Mon, 30 Jul 2007 11:28:45 +0200 Message-ID: <46ADAF5B.6050602@gahr.ch> Date: Mon, 30 Jul 2007 11:28:59 +0200 From: Pietro Cerutti User-Agent: Thunderbird 2.0.0.5 (X11/20070723) MIME-Version: 1.0 To: Hajimu UMEMOTO , freebsd-hackers@freebsd.org References: <46AA0491.5000203@gahr.ch> In-Reply-To: X-Enigmail-Version: 0.95.2 OpenPGP: id=9571F78E; url=http://www.gahr.ch/pgp Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigA52109AB0461A0E96C1061A2" X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel03.rubas-s03.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gahr.ch X-Source: X-Source-Args: X-Source-Dir: Cc: Subject: Re: [patch] enhance powerd(8) to handle max temperature X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2007 09:28:47 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA52109AB0461A0E96C1061A2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hajimu UMEMOTO wrote: > Hi, >=20 >>>>>> On Fri, 27 Jul 2007 16:43:29 +0200 >>>>>> Pietro Cerutti said: >=20 > gahr> Hi list, > gahr> here is a patch to allow powerd(8) accept a "-t tval" option to s= et a > gahr> temperature limit above which performance should be decreased. > gahr> It's a first draft, and I identified the following problems: >=20 > gahr> - the CPU temperature takes some time to decrease, so powerd keep= s > gahr> decreasing the CPU frequency until the temperature is below the l= imit. > gahr> The effect is a "increase to maximum, decrease to minimum, increa= se to > gahr> maximum, decrease to minimum, ...." which may not be desirable. >=20 > gahr> - the temperature is retrieved by the hw.acpi.thermal.tz0.tempera= ture > gahr> sysctl MIB. Support for other methods would be desirable. >=20 > gahr> The patches to powerd.c and powerd.8 are here: > gahr> http://www.gahr.ch/FreeBSD/patches/powerd.c.diff > gahr> http://www.gahr.ch/FreeBSD/patches/powerd.8.diff >=20 > gahr> Any comment is welcome! >=20 > We have a passive cooling mechanism already in our kernel. It runs > according to an ACPI specification. You are right, but the passive colling mechanism could not be available on some systems where thermal is available, and I'm still waiting for answers about acpi_thermal not sending notifies. See my previous post: http://lists.freebsd.org/pipermail/freebsd-hackers/2007-July/021361.html What's wrong with including this feature directly in powerd? >=20 > Sincerely, >=20 > -- > Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan > ume@mahoroba.org ume@{,jp.}FreeBSD.org > http://www.imasy.org/~ume/ > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" --=20 Pietro Cerutti PGP Public Key: http://gahr.ch/pgp --------------enigA52109AB0461A0E96C1061A2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGra9gwMJqmJVx944RCgwCAJsEhkOnovm97lelLtAk2wK77Q2PYwCgpheR HRsiQLzHA63xU+K2gQgpMwU= =5FsM -----END PGP SIGNATURE----- --------------enigA52109AB0461A0E96C1061A2-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 30 17:57:02 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A483516A419 for ; Mon, 30 Jul 2007 17:57:02 +0000 (UTC) (envelope-from jonathan+freebsd-hackers@hst.org.za) Received: from hermes.hst.org.za (onix.hst.org.za [209.203.2.133]) by mx1.freebsd.org (Postfix) with ESMTP id E214E13C504 for ; Mon, 30 Jul 2007 17:57:01 +0000 (UTC) (envelope-from jonathan+freebsd-hackers@hst.org.za) Received: from [10.1.11.1] ([10.1.11.1]) (authenticated bits=0) by hermes.hst.org.za (8.13.8/8.13.8) with ESMTP id l6UHEaDu094461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 30 Jul 2007 19:14:37 +0200 (SAST) (envelope-from jonathan+freebsd-hackers@hst.org.za) From: Jonathan McKeown To: freebsd-hackers@freebsd.org Date: Mon, 30 Jul 2007 19:18:27 +0200 User-Agent: KMail/1.9.4 Organization: Health Systems Trust MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707301918.27372.jonathan+freebsd-hackers@hst.org.za> X-Spam-Score: -3.977 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.61 on 209.203.2.133 Subject: passwd(1) and PAM X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2007 17:57:02 -0000 This seems to be almost a FAQ judging by the number of open/suspended PRs over several years, and the enquiry on this list back in March 2007 - but I haven't been able to find an answer yet. Looking at /usr/src/usr.bin/passwd/passwd.c, it seems that passwd(1) was rewritten four years ago to use the PAM infrastructure (with options -l, -o and -y not actually doing anything any more). It seems to be prevented from using, eg, pam_ldap, by the switch statement which uses constants defined in pam.h but commented there to be ``bogus''. 1. Is there any reason not to patch passwd.c locally, replacing the switch statement with printf and a single message? 2. When is this likely to make it into the official sources? I'm in a mixed environment and looking at using LDAP for account information with pam_pgina for Windows users. Oh, and if the answer is ``send a patch'', just let me know where! Jonathan From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 30 18:03:56 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0513216A419; Mon, 30 Jul 2007 18:03:56 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id E8AFC13C459; Mon, 30 Jul 2007 18:03:55 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from rot26.obsecurity.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 435E61A4D81; Mon, 30 Jul 2007 11:03:37 -0700 (PDT) Received: by rot26.obsecurity.org (Postfix, from userid 1001) id 3A8F1BA21; Mon, 30 Jul 2007 14:03:55 -0400 (EDT) Date: Mon, 30 Jul 2007 14:03:55 -0400 From: Kris Kennaway To: Pietro Cerutti Message-ID: <20070730180355.GA7355@rot26.obsecurity.org> References: <46AA0491.5000203@gahr.ch> <46ADAF5B.6050602@gahr.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46ADAF5B.6050602@gahr.ch> User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@freebsd.org, Hajimu UMEMOTO Subject: Re: [patch] enhance powerd(8) to handle max temperature X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2007 18:03:56 -0000 On Mon, Jul 30, 2007 at 11:28:59AM +0200, Pietro Cerutti wrote: > Hajimu UMEMOTO wrote: > > Hi, > > > >>>>>> On Fri, 27 Jul 2007 16:43:29 +0200 > >>>>>> Pietro Cerutti said: > > > > gahr> Hi list, > > gahr> here is a patch to allow powerd(8) accept a "-t tval" option to set a > > gahr> temperature limit above which performance should be decreased. > > gahr> It's a first draft, and I identified the following problems: > > > > gahr> - the CPU temperature takes some time to decrease, so powerd keeps > > gahr> decreasing the CPU frequency until the temperature is below the limit. > > gahr> The effect is a "increase to maximum, decrease to minimum, increase to > > gahr> maximum, decrease to minimum, ...." which may not be desirable. > > > > gahr> - the temperature is retrieved by the hw.acpi.thermal.tz0.temperature > > gahr> sysctl MIB. Support for other methods would be desirable. > > > > gahr> The patches to powerd.c and powerd.8 are here: > > gahr> http://www.gahr.ch/FreeBSD/patches/powerd.c.diff > > gahr> http://www.gahr.ch/FreeBSD/patches/powerd.8.diff > > > > gahr> Any comment is welcome! > > > > We have a passive cooling mechanism already in our kernel. It runs > > according to an ACPI specification. > > You are right, but the passive colling mechanism could not be available > on some systems where thermal is available, and I'm still waiting for > answers about acpi_thermal not sending notifies. > See my previous post: > http://lists.freebsd.org/pipermail/freebsd-hackers/2007-July/021361.html > > What's wrong with including this feature directly in powerd? In general duplication is undesirable. You should focus on trying to solve the problems with using the ACPI method. For example, the acpi passive cooling probably uses a better algorithm than your patches, e.g. including appropriate hysteresis. Kris From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 30 18:10:59 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6380116A468 for ; Mon, 30 Jul 2007 18:10:59 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id ABC3C13C474 for ; Mon, 30 Jul 2007 18:10:58 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (vader.bytemobile.ondsl.gr [83.235.244.135]) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-3) with ESMTP id l6UHt7Z2022379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 30 Jul 2007 20:55:16 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.1/8.14.1) with ESMTP id l6UHsoDY040245; Mon, 30 Jul 2007 20:55:06 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.1/8.14.1/Submit) id l6UHsn0F040243; Mon, 30 Jul 2007 20:54:49 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Mon, 30 Jul 2007 20:54:48 +0300 From: Giorgos Keramidas To: Tom Evans Message-ID: <20070730175448.GA40191@kobe.laptop> References: <200707271513.48639.sharadc@niksun.com> <20070727102027.GH1152@turion.vk2pj.dyndns.org> <1185553955.1457.8.camel@localhost> <20070728075553.GW1152@turion.vk2pj.dyndns.org> <1185783883.1444.3.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1185783883.1444.3.camel@localhost> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.894, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.51, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: FreeBSD Hackers Subject: Re: gcc -m32 option on amd64. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2007 18:10:59 -0000 On 2007-07-30 09:24, Tom Evans wrote: >On Sat, 2007-07-28 at 17:55 +1000, Peter Jeremy wrote: >> On 2007-Jul-27 17:32:35 +0100, Tom Evans wrote: >> >gcc on amd64 is capable of generating i386 code, but ld on amd64 is >> >incapable of linking i386 code together without serious amounts of work. >> >> Can you elaborate on what you mean by "incapable of linking i386 code"? >> The stock ld can definitely link i386 code: >> turion% ld -V >> GNU ld version 2.15 [FreeBSD] 2004-05-23 >> Supported emulations: >> elf_i386_fbsd >> elf_x86_64_fbsd >> turion% >> >> There is a problem that the 32-bit pathnames on FreeBSD/amd64 are >> different to the 32-bit pathnames on FreeBSD/i386 (ie an i386 >> executable built on amd64 will point to /libexec/ld-elf32.so.1, >> rather than /libexec/ld-elf.so.1) so the result won't execute on a >> FreeBSD/i386 box - but I don't see that as a problem with ld, rather >> the configuration. > > Sure. By 'incapable of linking i386 code' I mean that the default > toolchain of gcc invoking ld to assemble libraries and object files > into executables is incapable of doing so when compiling i386 code. I > say without serious amounts of work because, as you point out, it is > possible to do. The default toolchain can link 32-bit code with -B /usr/lib32 path options. This should work fine for the base system binaries. I expect ports compiled without -B will not cooperate very 'smoothly' with 32-bit port builds, but that's a different thing from being completely incapable, I guess. > Any other english sentences you need explaining? That's a bit too harsh. The FreeBSD people are known for their civilized manners, so can we tone things down a bit everyone? :-) From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 30 21:31:21 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C486A16A41A for ; Mon, 30 Jul 2007 21:31:21 +0000 (UTC) (envelope-from gahr@gahr.ch) Received: from cpanel03.rubas-s03.net (cpanel03.rubas-s03.net [195.182.222.73]) by mx1.freebsd.org (Postfix) with ESMTP id 5FA3913C459 for ; Mon, 30 Jul 2007 21:31:21 +0000 (UTC) (envelope-from gahr@gahr.ch) Received: from 80-218-187-205.dclient.hispeed.ch ([80.218.187.205] helo=gahrtop.localhost) by cpanel03.rubas-s03.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1IFcpj-0000Z3-Ix; Mon, 30 Jul 2007 23:31:19 +0200 Message-ID: <46AE58B5.3080506@gahr.ch> Date: Mon, 30 Jul 2007 23:31:33 +0200 From: Pietro Cerutti User-Agent: Thunderbird 2.0.0.5 (X11/20070723) MIME-Version: 1.0 To: Kris Kennaway , freebsd-hackers@freebsd.org References: <46AA0491.5000203@gahr.ch> <46ADAF5B.6050602@gahr.ch> <20070730180355.GA7355@rot26.obsecurity.org> In-Reply-To: <20070730180355.GA7355@rot26.obsecurity.org> X-Enigmail-Version: 0.95.2 OpenPGP: id=9571F78E; url=http://www.gahr.ch/pgp Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig30F02C0579D2AF348E0B65D4" X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel03.rubas-s03.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gahr.ch X-Source: X-Source-Args: X-Source-Dir: Cc: Subject: Re: [patch] enhance powerd(8) to handle max temperature X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2007 21:31:21 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig30F02C0579D2AF348E0B65D4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Kris Kennaway wrote: > On Mon, Jul 30, 2007 at 11:28:59AM +0200, Pietro Cerutti wrote: >> Hajimu UMEMOTO wrote: >>> Hi, >>> >>>>>>>> On Fri, 27 Jul 2007 16:43:29 +0200 >>>>>>>> Pietro Cerutti said: >>> gahr> Hi list, >>> gahr> here is a patch to allow powerd(8) accept a "-t tval" option to= set a >>> gahr> temperature limit above which performance should be decreased. >>> gahr> It's a first draft, and I identified the following problems: >>> >>> gahr> - the CPU temperature takes some time to decrease, so powerd ke= eps >>> gahr> decreasing the CPU frequency until the temperature is below the= limit. >>> gahr> The effect is a "increase to maximum, decrease to minimum, incr= ease to >>> gahr> maximum, decrease to minimum, ...." which may not be desirable.= >>> >>> gahr> - the temperature is retrieved by the hw.acpi.thermal.tz0.tempe= rature >>> gahr> sysctl MIB. Support for other methods would be desirable. >>> >>> gahr> The patches to powerd.c and powerd.8 are here: >>> gahr> http://www.gahr.ch/FreeBSD/patches/powerd.c.diff >>> gahr> http://www.gahr.ch/FreeBSD/patches/powerd.8.diff >>> >>> gahr> Any comment is welcome! >>> >>> We have a passive cooling mechanism already in our kernel. It runs >>> according to an ACPI specification. >> You are right, but the passive colling mechanism could not be availabl= e >> on some systems where thermal is available, and I'm still waiting for >> answers about acpi_thermal not sending notifies. >> See my previous post: >> http://lists.freebsd.org/pipermail/freebsd-hackers/2007-July/021361.ht= ml >> >> What's wrong with including this feature directly in powerd? >=20 > In general duplication is undesirable. You should focus on trying to > solve the problems with using the ACPI method. For example, the acpi > passive cooling probably uses a better algorithm than your patches, > e.g. including appropriate hysteresis. Hi Kris, I agree with you in that duplication is undesirable. But isn't having both powerd and passive cooling dealing with CPU frequency control already a form of duplication? I can't test it, since I can't use passive cooling, but how do not these two systems interfere with each other wrt setting the CPU frequency? What if, for example, my CPU temperature rises above _PSV but the CPU usage drops below 65%? In this case, the CPU frequency should be increased according to powerd's algorithm and should be decreased according to passive cooling's algorithm. Wouldn't it be better to have one subsystem deal with both usage and temperature in order to decide which is the best next frequency to be set= ? My patch is really just a first draft that I wrote in order to have feedbacks on the general idea to implement a temperature controlling system inside powerd, and doesn't implement hysteresis as you noted, and your feedback is that it's not a good idea, which I respect. Given the above, would you like to elaborate? Thank you for your time! >=20 > Kris > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" --=20 Pietro Cerutti PGP Public Key: http://gahr.ch/pgp --------------enig30F02C0579D2AF348E0B65D4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGrli5wMJqmJVx944RCvkKAJ9FpmnLLiooL9Lb4npx+UtQ5yjxTwCgor4B o7IpOjrInyW4MnLowA03aNg= =F5LC -----END PGP SIGNATURE----- --------------enig30F02C0579D2AF348E0B65D4-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 30 21:20:24 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E85516A41F for ; Mon, 30 Jul 2007 21:20:24 +0000 (UTC) (envelope-from ytriffy@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.freebsd.org (Postfix) with ESMTP id AFE1C13C48E for ; Mon, 30 Jul 2007 21:20:23 +0000 (UTC) (envelope-from ytriffy@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so179977nfb for ; Mon, 30 Jul 2007 14:20:22 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; b=b8yRvA2xitMukl5eh3t+gq9xk3hbVpvRTvH4ap48qkGfKHeako9hQNbXkdlqWGwM/cCiRF42cL6fi5Ueuh0VVOXfQu4yRAjmfktKfD0z7iIHDRbL2g4BuI5RR0tW6SrBoORj81wi+PCcFuL93DjxaC0ExwzlrhaHRfoWVvjsWeU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; b=COnn09PMLjFc1fRajcpiYGim23WQlin9M7XH5W7io8DWRtJRh9DYMTBWDl2lEGmY8zAvPnpQEL5e8tbmOor8Y3SbyKhcRty1t0AbhGx0jjJnw+XzjTmJ+cHRYyz919nzEd40ciCuYWAi2qiFfQiVGfFydh4xGPreYJIqq1TpDmY= Received: by 10.86.79.19 with SMTP id c19mr4190197fgb.1185830418298; Mon, 30 Jul 2007 14:20:18 -0700 (PDT) Received: from ?192.168.0.179? ( [80.86.254.135]) by mx.google.com with ESMTPS id j12sm1343947fkf.2007.07.30.14.20.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 30 Jul 2007 14:20:17 -0700 (PDT) Message-ID: <46AE55EC.2020503@gmail.com> Date: Tue, 31 Jul 2007 01:19:40 +0400 From: ytriffy User-Agent: Thunderbird 2.0.0.5 (X11/20070720) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 30 Jul 2007 22:09:40 +0000 Cc: Subject: [panic]page fault while in kernel mode X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2007 21:20:24 -0000 Hello. Trap 12 occured when I rebooted PC. Sending you backtrace. My system: amd64 3200+ Venice, MB ECS nForce4 A939,Samsung 250GB and WD 250 GB, 2 memory banks 512MB each, videocard: Geforce 6600gt 128MB, NIC on realtek chip, sound card cirrus logic cs4281. It's very unstable, crashes happen every day, so I'm hoping you would say why(any hints what hardware may cause it). How to repeat it? I don't know. It happened once during reboot process. [root@freelanc /var]# uname -a FreeBSD freelanc.dubki.ru 6.2-STABLE-200706 FreeBSD 6.2-STABLE-200706 #1: Mon Jul 23 13:34:27 MSD 2007 root@freelanc.dubki.ru:/usr/obj/usr/src/sys/DEBUGGER KERN i386 [root@freelanc /usr/obj/usr/src/sys/DEBUGGERKERN]# kgdb kernel.debug /var/crash/vmcore.3 kgdb: kvm_nlist(_stopped_cpus): kgdb: kvm_nlist(_stoppcbs): [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: <118>Jul 25 14:06:32 freelanc syslogd: exiting on signal 15 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...6 5 3 1 0 0 done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done All buffers synced. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x4 fault code = supervisor read, page not present instruction pointer = 0x20:0xc058a4e0 stack pointer = 0x28:0xe9455c48 frame pointer = 0x28:0xe9455c58 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 = 44922 (reboot) panic: from debugger Uptime: 2h45m36s Dumping 1022 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 1022MB (261600 pages) 1006 990 974 958 942 926 910 894 878 862 846 830 814 798 782 766 750 734 718 702 686 670 654 638 622 606 590 574 558 542 526 510 494 478 462 446 430 414 398 382 366 350 334 318 302 286 270 254 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14 #0 doadump () at pcpu.h:165 165 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc053d916 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc053dbdc in panic (fmt=0xc06f5278 "from debugger") at /usr/src/sys/kern/kern_shutdown.c:565 #3 0xc045361d in db_panic (addr=-1067932448, have_addr=0, count=-1, modif=0xe9455a74 "") at /usr/src/sys/ddb/db_command.c:438 #4 0xc04535b4 in db_command (last_cmdp=0xc0766784, cmd_table=0x0, aux_cmd_tablep=0xc0728e90, aux_cmd_tablep_end=0xc0728e94) at /usr/src/sys/ddb/db_command.c:350 #5 0xc045367c in db_command_loop () at /usr/src/sys/ddb/db_command.c:458 #6 0xc0455291 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:222 #7 0xc0556a2b in kdb_trap (type=12, code=0, tf=0xe9455c08) at /usr/src/sys/kern/subr_kdb.c:473 #8 0xc06cba6c in trap_fatal (frame=0xe9455c08, eva=4) at /usr/src/sys/i386/i386/trap.c:828 #9 0xc06cb7d7 in trap_pfault (frame=0xe9455c08, usermode=0, eva=4) at /usr/src/sys/i386/i386/trap.c:745 #10 0xc06cb3f1 in trap (frame= {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -381330360, tf_esi = -993547624, tf_ebp = -381330344, tf_isp = -381330380, tf_ebx = 0, tf_edx = -992513384, tf_ecx = 4, tf_eax = -950651024, tf_trapno = 12, tf_err = 0, tf_eip = -1067932448, tf_cs = 32, tf_eflags = 590338, tf_esp = 0, tf_ss = -992305712}) at /usr/src/sys/i386/i386/trap.c:435 #11 0xc06b8b1a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #12 0xc058a4e0 in cache_purgevfs (mp=0xc4d77298) at /usr/src/sys/kern/vfs_cache.c:622 #13 0xc0591f29 in dounmount (mp=0xc4d77298, flags=524288, td=0xc62ce300) at /usr/src/sys/kern/vfs_mount.c:1214 #14 0xc0597d0a in vfs_unmountall () at /usr/src/sys/kern/vfs_subr.c:2837 #15 0xc053d807 in boot (howto=0) at /usr/src/sys/kern/kern_shutdown.c:391 #16 0xc053d2a2 in reboot (td=0xc62ce300, uap=0xc7563770) at /usr/src/sys/kern/kern_shutdown.c:169 #17 0xc06cbdbb in syscall (frame= {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 2, tf_esi = 18, tf_ebp = -1077941304, tf_isp = -381330076, tf_ebx = 0, tf_edx = -1, tf_ecx = 672491264, tf_eax = 55, tf_trapno = 12, tf_err = 2, tf_eip = 671802263, tf_cs = 51, tf_eflags = 662, tf_esp = -1077941380, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:983 #18 0xc06b8b6f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200 #19 0x00000033 in ?? () Any info is appreciated. with regards, Slava Gonahchan. From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 30 22:49:55 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0886716A417 for ; Mon, 30 Jul 2007 22:49:55 +0000 (UTC) (envelope-from karol.kwiat@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.188]) by mx1.freebsd.org (Postfix) with ESMTP id 89CA113C45D for ; Mon, 30 Jul 2007 22:49:54 +0000 (UTC) (envelope-from karol.kwiat@gmail.com) Received: by mu-out-0910.google.com with SMTP id w9so1812596mue for ; Mon, 30 Jul 2007 15:49:53 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:openpgp:content-type; b=CEbs18YIduPAjsfqRG/6lNfFbkCqNNZo5QH2TzbrKq+2C+q3b80NEizSG2xXkvOumQ6lwSL99hpAEJJhxo5maYy8it1yZwT55CGVGKQDdnIByvX9urz4N4bBsD0fylDEIrj6ic6vDzTf3c5mgH6Gq9cOwOgRV+/oNaupqauvIzE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:openpgp:content-type; b=DZOXfVPzizHqAERPWhO/apo3xiKnvB9C1IWabPQkBK6FPdipTWAUuqeDveIYS/dADhlOLv6xRBhrP0ArBWlIm0FFYLs0FWR0dA5arJD57XlklxFEsz68373+1slUHUxXU8R94JVEJySLBwOBbpVC9nXM4Vh1Pm0cRWTGE07BaoQ= Received: by 10.86.73.17 with SMTP id v17mr4258210fga.1185834325992; Mon, 30 Jul 2007 15:25:25 -0700 (PDT) Received: from persephone.orchid.homeunix.org ( [84.10.173.180]) by mx.google.com with ESMTPS id g28sm1449290fkg.2007.07.30.15.25.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 30 Jul 2007 15:25:14 -0700 (PDT) Message-ID: <46AE6542.1080400@gmail.com> Date: Tue, 31 Jul 2007 00:25:06 +0200 From: Karol Kwiatkowski User-Agent: Thunderbird 2.0.0.5 (X11/20070723) MIME-Version: 1.0 To: Michael S References: <367849.74200.qm@web88315.mail.re4.yahoo.com> In-Reply-To: <367849.74200.qm@web88315.mail.re4.yahoo.com> X-Enigmail-Version: 0.95.2 OpenPGP: id=06E09309; url=http://www.orchid.homeunix.org/carlos/gpg/0x06E09309.asc Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig1E2EBD816CB363A780C02A4A" Cc: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org Subject: Re: network/multithreaded programming on FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: karol.kwiat@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2007 22:49:55 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1E2EBD816CB363A780C02A4A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Michael S wrote: > Good day all, >=20 > I am not sure this is the correct list for my > question, I am still going to ask though.=20 > I am a 3rd year computer science student and in the > fall I am going to be taking courses in network and > system programming (with pthread). As a lot of > universities do, mine also teaches these courses on > Linux. I was wondering if there was a lot of > difference in socket and multi-threaded programming > between Linux and FreeBSD? >=20 > Thanks in advance, > Michael Hi Michael, I think @hackers might be better place to ask programming questions (added to CC). Cheers and good luck with your course! Karol --=20 Karol Kwiatkowski OpenPGP 0x06E09309 --------------enig1E2EBD816CB363A780C02A4A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBRq5lQghgT0HIecD5AQjxPQf+J4ZRppzkzmdNhPaGcagM9XzTLKE9OIhr uH7OMQBx8BtM13d+p+54t8/WegM5d2nnPYMd1sdyGxzuNVf2wcmeQxbIqUTLFqcF /BlhvMXjVwsR3xZsEg0yvm6a5DBJvavQb6bwYMGM/0wAOTO+mpVYxcj+/LXHEsHe LAW5gqTPPoui9CrBEq96dMuh2Uzutg1StKN5J9IOg5PuZMQr/lvdwrDoUb063TI8 qrVZQPpi8WIzsJsWQr63EXkYh26vC2D2H9IlPP0u3pDp2r5uzaNzl5Cd0AJl0G1T sN1TZ8qX8icIZGDv7efT82hiIGAPPA1KaroWzL2hcKYXjBBITX9sjw== =gpKv -----END PGP SIGNATURE----- --------------enig1E2EBD816CB363A780C02A4A-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 30 23:15:39 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2ECAA16A418 for ; Mon, 30 Jul 2007 23:15:39 +0000 (UTC) (envelope-from gahr@gahr.ch) Received: from cpanel03.rubas-s03.net (cpanel03.rubas-s03.net [195.182.222.73]) by mx1.freebsd.org (Postfix) with ESMTP id C0F1213C468 for ; Mon, 30 Jul 2007 23:15:38 +0000 (UTC) (envelope-from gahr@gahr.ch) Received: from 80-218-187-205.dclient.hispeed.ch ([80.218.187.205] helo=gahrtop.localhost) by cpanel03.rubas-s03.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1IFeSe-00033R-R1; Tue, 31 Jul 2007 01:15:37 +0200 Message-ID: <46AE7126.3070500@gahr.ch> Date: Tue, 31 Jul 2007 01:15:50 +0200 From: Pietro Cerutti User-Agent: Thunderbird 2.0.0.5 (X11/20070723) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, msherman77@yahoo.com References: <367849.74200.qm@web88315.mail.re4.yahoo.com> <46AE6542.1080400@gmail.com> In-Reply-To: <46AE6542.1080400@gmail.com> X-Enigmail-Version: 0.95.2 OpenPGP: id=9571F78E; url=http://www.gahr.ch/pgp Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigEAF3F56298D8AE122A6D14CE" X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel03.rubas-s03.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gahr.ch X-Source: X-Source-Args: X-Source-Dir: Cc: Subject: Re: network/multithreaded programming on FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2007 23:15:39 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEAF3F56298D8AE122A6D14CE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Karol Kwiatkowski wrote: > Michael S wrote: >> Good day all, >> >> I am not sure this is the correct list for my >> question, I am still going to ask though.=20 >> I am a 3rd year computer science student and in the >> fall I am going to be taking courses in network and >> system programming (with pthread). As a lot of >> universities do, mine also teaches these courses on >> Linux. I was wondering if there was a lot of >> difference in socket and multi-threaded programming >> between Linux and FreeBSD? Hi Michael, the system calls you'll need for networking socket programming and pthreads are POSIX compliant on both linux and freebsd. Thus, you'll be able to port your programs between the two systems. I suggest to refer to the POSIX pages on threads: http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_09.htm= l and sockets: http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_10.htm= l and to read the wonderful Beej's guite to network programming: http://www.beej.us/guide/bgnet/ >> Thanks in advance, I hope this helps, >> Michael --=20 Pietro Cerutti PGP Public Key: http://gahr.ch/pgp --------------enigEAF3F56298D8AE122A6D14CE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGrnEqwMJqmJVx944RCjIeAJ9xXNvNUCNbS58zz0OvDa9NBF+1lQCdFCIe JT4z9dezOpsWpE0YkRquHoU= =NDVu -----END PGP SIGNATURE----- --------------enigEAF3F56298D8AE122A6D14CE-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 30 23:25:47 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA74A16A419 for ; Mon, 30 Jul 2007 23:25:47 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: from mired.org (vpn.mired.org [66.92.153.74]) by mx1.freebsd.org (Postfix) with SMTP id 99C6C13C469 for ; Mon, 30 Jul 2007 23:25:47 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: (qmail 34682 invoked by uid 1001); 30 Jul 2007 23:23:43 -0000 Received: from bhuda.mired.org (localhost.localdomain [127.0.0.1]) by bhuda.mired.org (tmda-ofmipd) with ESMTP; Mon, 30 Jul 2007 19:23:43 -0400 Date: Mon, 30 Jul 2007 19:23:42 -0400 To: freebsd-hackers@freebsd.org Message-ID: <20070730192342.7e057aad@bhuda.mired.org> In-Reply-To: <46AE6542.1080400@gmail.com> References: <367849.74200.qm@web88315.mail.re4.yahoo.com> <46AE6542.1080400@gmail.com> Organization: Meyer Consulting X-Mailer: Claws Mail 2.9.1 (GTK+ 2.10.12; amd64-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Delivery-Agent: TMDA/1.1.11 (Ladyburn) From: Mike Meyer Cc: Michael S , freebsd-questions@freebsd.org, karol.kwiat@gmail.com Subject: Re: network/multithreaded programming on FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2007 23:25:48 -0000 On Tue, 31 Jul 2007 00:25:06 +0200 Karol Kwiatkowski wrote: > Michael S wrote: > > Good day all, > > > > I am not sure this is the correct list for my > > question, I am still going to ask though. > > I am a 3rd year computer science student and in the > > fall I am going to be taking courses in network and > > system programming (with pthread). As a lot of > > universities do, mine also teaches these courses on > > Linux. I was wondering if there was a lot of > > difference in socket and multi-threaded programming > > between Linux and FreeBSD? > > > > Thanks in advance, > > Michael > > Hi Michael, > > I think @hackers might be better place to ask programming questions > (added to CC). It certainly liable to get a better answer, because it has a higher density of programmers hanging out there. I'm not sure it's a better place to ask programming questions, as it's meant for discussing the development of FreeBSD, as opposed to development on FreeBSD. On the other hand, there doesn't seem to be a list for the latter on the list of freebsd mail lists..... The answer depends on what your goal is. If you want to write portable code, both strive to be Posix systems, so if you follow the Posix guidelines, you'll be ok. Since I develop on several different Unix platforms including FreeBSD for clients running GNU/Linux (among other things), that's what I do, and it generally works. However, if you start straying outside Posix, you'll find differences. My experience is that Linux tends to be missing features, but more lenient about transgressions of the standard, than FreeBSD. On the other hand, my sample set is sufficiently small that this may not be a good indication of what it's like for others. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 31 01:21:36 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6753416A41F; Tue, 31 Jul 2007 01:21:36 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from ameno.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2AC3D13C494; Tue, 31 Jul 2007 01:21:36 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from localhost (IDENT:Rj5/VaKa3xTe9rXavv+HMHAffYHAeeMNXv6uO7M5nKRLb1DCakDgE5mTh6GZlmWd@localhost [IPv6:::1]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.8/8.13.8) with ESMTP/inet6 id l6V1LOKj077311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Jul 2007 10:21:28 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Tue, 31 Jul 2007 10:21:24 +0900 Message-ID: From: Hajimu UMEMOTO To: Pietro Cerutti In-Reply-To: <46AE58B5.3080506@gahr.ch> References: <46AA0491.5000203@gahr.ch> <46ADAF5B.6050602@gahr.ch> <20070730180355.GA7355@rot26.obsecurity.org> <46AE58B5.3080506@gahr.ch> User-Agent: xcite1.57> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.1 (i386-pc-freebsd) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 6.2-RELEASE-p4 X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (ameno.mahoroba.org [IPv6:::1]); Tue, 31 Jul 2007 10:21:28 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00, DKIM_POLICY_SIGNSOME,DK_POLICY_SIGNSOME,HELO_LOCALHOST autolearn=no version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on ameno.mahoroba.org Cc: acpi@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: [patch] enhance powerd(8) to handle max temperature X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2007 01:21:36 -0000 Hi, >>>>> On Mon, 30 Jul 2007 23:31:33 +0200 >>>>> Pietro Cerutti said: gahr> I can't test it, since I can't use passive cooling, but how do not these gahr> two systems interfere with each other wrt setting the CPU frequency? gahr> What if, for example, my CPU temperature rises above _PSV but the CPU gahr> usage drops below 65%? Do you mean that your hw.acpi.thermal.tz0._PSV has reasonable value? If so, perhaps, your ACPI BIOS is broken, and _TC1, _TC2 and _TSP are not defined correctly. Please show me the output of `sysctl hw.acpi' and `acpidump -dt'. gahr> In this case, the CPU frequency should be increased according to gahr> powerd's algorithm and should be decreased according to passive gahr> cooling's algorithm. gahr> Wouldn't it be better to have one subsystem deal with both usage and gahr> temperature in order to decide which is the best next frequency to be set? No, we have a priority to control a cpufreq in our kernel, to deal with conflict between kernel and userland. Controlling cpufreq within our kernel is considered as high proirity. So, during our kernel is controlling a cpufreq, we cannot change cpufreq from userland. And, our kernel releasing the control, a cpufreq is back to the value before our kernel changed it. gahr> My patch is really just a first draft that I wrote in order to have gahr> feedbacks on the general idea to implement a temperature controlling gahr> system inside powerd, and doesn't implement hysteresis as you noted, and gahr> your feedback is that it's not a good idea, which I respect. It is rather backward, IMHO. I did implement a passive cooling feature as an enhancement of powerd(8) like you did, during initial phases. Then, I implemented it in our kernel as a result. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 31 01:52:00 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3B9216A420 for ; Tue, 31 Jul 2007 01:52:00 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 899EA13C45D for ; Tue, 31 Jul 2007 01:52:00 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 22231 invoked from network); 31 Jul 2007 01:25:20 -0000 Received: from ppp-71-139-42-13.dsl.snfc21.pacbell.net (HELO ?10.0.0.15?) (nate-mail@71.139.42.13) by root.org with ESMTPA; 31 Jul 2007 01:25:20 -0000 Message-ID: <46AE8F78.1060203@root.org> Date: Mon, 30 Jul 2007 18:25:12 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.4 (X11/20070620) MIME-Version: 1.0 To: Hajimu UMEMOTO References: <46AA0491.5000203@gahr.ch> <46ADAF5B.6050602@gahr.ch> <20070730180355.GA7355@rot26.obsecurity.org> <46AE58B5.3080506@gahr.ch> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 31 Jul 2007 01:56:32 +0000 Cc: acpi@freebsd.org, freebsd-hackers@freebsd.org, Pietro Cerutti Subject: Re: [patch] enhance powerd(8) to handle max temperature X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2007 01:52:00 -0000 Hajimu UMEMOTO wrote: >>>>>> On Mon, 30 Jul 2007 23:31:33 +0200 >>>>>> Pietro Cerutti said: > gahr> My patch is really just a first draft that I wrote in order to have > gahr> feedbacks on the general idea to implement a temperature controlling > gahr> system inside powerd, and doesn't implement hysteresis as you noted, and > gahr> your feedback is that it's not a good idea, which I respect. > > It is rather backward, IMHO. I did implement a passive cooling > feature as an enhancement of powerd(8) like you did, during initial > phases. Then, I implemented it in our kernel as a result. I'll take a look at your patch. Umemoto-san is right in that you really want the kernel to control cooling. What happens if powerd dies/hangs and your system burns up? Passive cooling is often a last resort to keep the system from overheating. -Nate From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 31 05:36:41 2007 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0CD716A417 for ; Tue, 31 Jul 2007 05:36:41 +0000 (UTC) (envelope-from jonny@jonny.eng.br) Received: from coe.ufrj.br (roma.coe.ufrj.br [146.164.53.65]) by mx1.freebsd.org (Postfix) with ESMTP id 9A38613C45B for ; Tue, 31 Jul 2007 05:36:41 +0000 (UTC) (envelope-from jonny@jonny.eng.br) Received: from localhost (localhost [127.0.0.1]) by coe.ufrj.br (Postfix) with ESMTP id 66B871256C0 for ; Tue, 31 Jul 2007 02:08:08 -0300 (BRT) X-Virus-Scanned: amavisd-new at coe.ufrj.br Received: from coe.ufrj.br ([146.164.53.65]) by localhost (roma.coe.ufrj.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJqgss3O7fyR for ; Tue, 31 Jul 2007 02:08:04 -0300 (BRT) Received-SPF: none (coe.ufrj.br: 201.19.142.94 is neither permitted nor denied by domain of jonny.eng.br) client-ip=201.19.142.94; envelope-from=jonny@jonny.eng.br; helo=[201.19.142.94]; Received: from [201.19.142.94] (unknown [201.19.142.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by coe.ufrj.br (Postfix) with ESMTP id 057CE1256BE for ; Tue, 31 Jul 2007 02:08:03 -0300 (BRT) Message-ID: <46AEC3BF.4080309@jonny.eng.br> Date: Tue, 31 Jul 2007 02:08:15 -0300 From: =?ISO-8859-1?Q?Jo=E3o_Carlos_Mendes_Lu=EDs?= User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: Problems with rpc.statd and PAE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2007 05:36:42 -0000 Hi, Sent this to -questions, but got no answer. Now I'll try -hackers... I've just configured my first server with 4G RAM. To use it, I had to select PAE in kernel config. I was a little bit troubled by it's advice not to use modules (is it that critical?), but got it running. But when it is running on PAE, NFS statd refuses to run: # /etc/rc.d/nfslocking start Starting statd. rpc.statd: unable to mmap() status file: Cannot allocate memory Segmentation fault # Using strace I found it was trying to mmap the status file, at /var/db/statd.status: open("/var/db/statd.status", O_RDWR) = 10 mmap(0, 268435456, PROT_READ|PROT_WRITE, MAP_SHARED, 10, 0) = -1 ENOMEM (Cannot allocate memory) It's really strange to have mmap len = 256M, specially because the file is always small. But it works without PAE, and do not work with PAE. And it is described in the handbook: http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/book.html#STATD-MEM-LEAK Also, I tought PAE was only needed when we had MORE than 4G. But without PAE the system shows only 3.5G: - Without PAE: Jul 25 16:34:41 zeus kernel: real memory = 3757965312 (3583 MB) Jul 25 16:34:41 zeus kernel: avail memory = 3678429184 (3508 MB) - With PAE: Jul 25 17:09:01 zeus kernel: real memory = 4831838208 (4608 MB) Jul 25 17:09:01 zeus kernel: avail memory = 4193112064 (3998 MB) If I could use the whole 4G, or at least lose less than 512M, I'd prefer to stay off PAE. Any help you could give me? TIA, Jonny PS: sources fully updated to 6-RELENG from last week. -- Joo Carlos Mendes Lus - Networking Engineer - jonny@jonny.eng.br From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 31 05:54:13 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09CE016A417; Tue, 31 Jul 2007 05:54:13 +0000 (UTC) (envelope-from gahr@gahr.ch) Received: from cpanel03.rubas-s03.net (cpanel03.rubas-s03.net [195.182.222.73]) by mx1.freebsd.org (Postfix) with ESMTP id 92D9813C481; Tue, 31 Jul 2007 05:54:11 +0000 (UTC) (envelope-from gahr@gahr.ch) Received: from 80-218-187-205.dclient.hispeed.ch ([80.218.187.205] helo=gahrtop.localhost) by cpanel03.rubas-s03.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1IFkgK-0006Yg-4k; Tue, 31 Jul 2007 07:54:10 +0200 Message-ID: <46AECE8C.8000500@gahr.ch> Date: Tue, 31 Jul 2007 07:54:20 +0200 From: Pietro Cerutti User-Agent: Thunderbird 2.0.0.5 (X11/20070723) MIME-Version: 1.0 To: Hajimu UMEMOTO References: <46AA0491.5000203@gahr.ch> <46ADAF5B.6050602@gahr.ch> <20070730180355.GA7355@rot26.obsecurity.org> <46AE58B5.3080506@gahr.ch> In-Reply-To: X-Enigmail-Version: 0.95.2 OpenPGP: id=9571F78E; url=http://www.gahr.ch/pgp Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig4CA6C2FBD4CDF6A051529EB3" X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel03.rubas-s03.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gahr.ch X-Source: X-Source-Args: X-Source-Dir: Cc: acpi@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: [patch] enhance powerd(8) to handle max temperature X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2007 05:54:13 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4CA6C2FBD4CDF6A051529EB3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hajimu UMEMOTO wrote: > Hi, >=20 >>>>>> On Mon, 30 Jul 2007 23:31:33 +0200 >>>>>> Pietro Cerutti said: >=20 > gahr> I can't test it, since I can't use passive cooling, but how do no= t these > gahr> two systems interfere with each other wrt setting the CPU frequen= cy? > gahr> What if, for example, my CPU temperature rises above _PSV but the= CPU > gahr> usage drops below 65%? >=20 > Do you mean that your hw.acpi.thermal.tz0._PSV has reasonable value? > If so, perhaps, your ACPI BIOS is broken, and _TC1, _TC2 and _TSP are > not defined correctly. Please show me the output of `sysctl hw.acpi' > and `acpidump -dt'. Thanks for your help! > sysctl hw.acpi hw.acpi.supported_sleep_state: S1 S3 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S1 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 1 hw.acpi.disable_on_reboot: 0 hw.acpi.handle_reboot: 0 hw.acpi.reset_video: 0 hw.acpi.cpu.cx_lowest: C1 hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 1 hw.acpi.thermal.tz0.temperature: 59.8C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 0 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 80.0C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 99.8C hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.acline: 1 hw.acpi.battery.life: 97 hw.acpi.battery.time: -1 hw.acpi.battery.state: 0 hw.acpi.battery.units: 1 hw.acpi.battery.info_expire: 5 > sudo acpidump -dt /* RSD PTR: OEM=3DMSI, ACPI_Rev=3D1.0x (0) RSDT=3D0x7f7c0000, cksum=3D157 */ /* RSDT: Length=3D60, Revision=3D1, Checksum=3D212, OEMID=3DMSI_NB, OEM Table ID=3DMEGABOOK, OEM Revision=3D0x3262007, Creator ID=3DMSFT, Creator Revision=3D0x97 Entries=3D{ 0x7f7c0200, 0x7f7c0390, 0x7f7c03f0, 0x7f7c0430, 0x7f7ce040, 0x7f7c4670 } */ /* FACP: Length=3D132, Revision=3D2, Checksum=3D98, OEMID=3DMSI, OEM Table ID=3D1034, OEM Revision=3D0x3262007, Creator ID=3DMSFT, Creator Revision=3D0x97 FACS=3D0x7f7ce000, DSDT=3D0x7f7c05b0 INT_MODEL=3DAPIC Preferred_PM_Profile=3DUnspecified (0) SCI_INT=3D9 SMI_CMD=3D0xb2, ACPI_ENABLE=3D0xe1, ACPI_DISABLE=3D0x1e, S4BIOS_REQ=3D0x0= PSTATE_CNT=3D0xe2 PM1a_EVT_BLK=3D0x800-0x803 PM1a_CNT_BLK=3D0x804-0x805 PM2_CNT_BLK=3D0x820-0x81f PM_TMR_BLK=3D0x808-0x80b GPE0_BLK=3D0x828-0x82f CST_CNT=3D0xe3 P_LVL2_LAT=3D1 us, P_LVL3_LAT=3D85 us FLUSH_SIZE=3D1024, FLUSH_STRIDE=3D16 DUTY_OFFSET=3D1, DUTY_WIDTH=3D0 DAY_ALRM=3D13, MON_ALRM=3D0, CENTURY=3D0 IAPC_BOOT_ARCH=3D{8042} Flags=3D{WBINVD,PROC_C1,SLP_BUTTON,RTC_S4} */ /* FACS:Length=3D64, HwSig=3D0x00000000, Firm_Wake_Vec=3D0x00000000 Global_Lock=3D Flags=3D Version=3D1 */ /* DSDT: Length=3D16571, Revision=3D1, Checksum=3D254, OEMID=3DMSI_NB, OEM Table ID=3DMEGABOOK, OEM Revision=3D0x3262007, Creator ID=3DINTL, Creator Revision=3D0x20051117 */ /* APIC: Length=3D92, Revision=3D1, Checksum=3D3, OEMID=3DMSI, OEM Table ID=3DOEMAPIC, OEM Revision=3D0x3262007, Creator ID=3DMSFT, Creator Revision=3D0x97 Local APIC ADDR=3D0xfee00000 Flags=3D{PC-AT} Type=3DLocal APIC ACPI CPU=3D1 Flags=3D{ENABLED} APIC ID=3D0 Type=3DLocal APIC ACPI CPU=3D2 Flags=3D{ENABLED} APIC ID=3D1 Type=3DIO APIC APIC ID=3D2 INT BASE=3D0 ADDR=3D0x00000000fec00000 Type=3DINT Override BUS=3D0 IRQ=3D0 INTR=3D2 Flags=3D{Polarity=3Dconforming, Trigger=3Dconforming} Type=3DINT Override BUS=3D0 IRQ=3D9 INTR=3D9 Flags=3D{Polarity=3Dactive-hi, Trigger=3Dlevel} */ /* MCFG: Length=3D60, Revision=3D1, Checksum=3D63, OEMID=3DMSI, OEM Table ID=3DOEMMCFG, OEM Revision=3D0x3262007, Creator ID=3DMSFT, Creator Revision=3D0x97 Base Address=3D 0x00000000e0000000 Segment Group=3D 0x0000 Start Bus=3D 0 End Bus=3D 255 */ /* SLIC: Length=3D374, Revision=3D1, Checksum=3D213, OEMID=3DMSI_NB, OEM Table ID=3DMEGABOOK, OEM Revision=3D0x3262007, Creator ID=3DMSFT, Creator Revision=3D0x97 */ acpidump: RSDT entry 4 (sig OEMB) is corrupt /* HPET: Length=3D56, Revision=3D1, Checksum=3D3, OEMID=3DMSI, OEM Table ID=3DOEMHPET, OEM Revision=3D0x3262007, Creator ID=3DMSFT, Creator Revision=3D0x97 HPET Number=3D0 ADDR=3D0xfed00000:0[8] (Memory) HW Rev=3D0xff Comparitors=3D31 Counter Size=3D1 Legacy IRQ routing capable=3D{TRUE} PCI Vendor ID=3D0xffff Minimal Tick=3D14318 */ /* * Intel ACPI Component Architecture * AML Disassembler version 20041119 * * Disassembly of /tmp/acpidump.l8hiOT, Tue Jul 31 07:50:26 2007 */ DefinitionBlock ("DSDT.aml", "DSDT", 1, "MSI_NB", "MEGABOOK", 52830215) { Scope (_PR) { Processor (CPU1, 0x01, 0x00000810, 0x06) { OperationRegion (STBL, SystemMemory, 0x7F7CE0C0, 0x06CA) Name (NCPU, 0x02) Name (TYPE, 0x80000000) Name (HNDL, 0x80000000) Name (CFGD, 0x010061F1) Name (TBLD, 0x80) Method (_PDC, 1, NotSerialized) { CreateDWordField (Arg0, Zero, REVS) CreateDWordField (Arg0, 0x04, SIZE) Store (SizeOf (Arg0), Local0) Store (Subtract (Local0, 0x08), Local1) CreateField (Arg0, 0x40, Multiply (Local1, 0x08), TEMP) Name (STS0, Buffer (0x04) { 0x00, 0x00, 0x00, 0x00 }) Concatenate (STS0, TEMP, Local2) _OSC (Buffer (0x10) { 0x16, 0xA6, 0x77, 0x40, 0x0C, 0x29, 0xBE, 0x47, 0x9E, 0xBD, 0xD8, 0x70, 0x58, 0x71, 0x39, 0x53 }, REVS, SIZE, Local2) } Method (_OSC, 4, NotSerialized) { CreateDWordField (Arg3, Zero, STS0) CreateDWordField (Arg3, 0x04, CAP0) CreateDWordField (Arg0, Zero, IID0) CreateDWordField (Arg0, 0x04, IID1) CreateDWordField (Arg0, 0x08, IID2) CreateDWordField (Arg0, 0x0C, IID3) Name (UID0, Buffer (0x10) { 0x16, 0xA6, 0x77, 0x40, 0x0C, 0x29, 0xBE, 0x47, 0x9E, 0xBD, 0xD8, 0x70, 0x58, 0x71, 0x39, 0x53 }) CreateDWordField (UID0, Zero, EID0) CreateDWordField (UID0, 0x04, EID1) CreateDWordField (UID0, 0x08, EID2) CreateDWordField (UID0, 0x0C, EID3) If (LNot (LAnd (LAnd (LEqual (IID0, EID0), LEqual (IID1, EID1)), LAnd (LEqual (IID2, EID2), LEqual (IID3, EID3))))) { Store (0x06, STS0) Return (Arg3) } If (LNot (LEqual (Arg1, One))) { Store (0x0A, STS0) Return (Arg3) } Or (And (TYPE, 0x7FFFFFFF), CAP0, TYPE) If (And (CFGD, One)) { If (LAnd (LEqual (And (TYPE, 0x09), 0x09), LNot (And (TBLD, One)))) { Or (TBLD, One, TBLD) Load (STBL, HNDL) } } If (And (CFGD, 0xF0)) { If (LAnd (LAnd (And (CFGD, 0x01000000), And (TYPE, 0x18)), LNot (And (TBLD, 0x02)))) { Or (TBLD, 0x02, TBLD) } } Return (Arg3) } } } Scope (_PR) { Processor (CPU2, 0x02, 0x00000810, 0x06) { OperationRegion (STBL, SystemMemory, 0x7F7CE790, 0x0120) Name (NCPU, 0x02) Name (TYPE, 0x80000000) Name (HNDL, 0x80000000) Name (CFGD, 0x010061F1) Name (TBLD, 0x80) Method (_PDC, 1, NotSerialized) { CreateDWordField (Arg0, Zero, REVS) CreateDWordField (Arg0, 0x04, SIZE) Store (SizeOf (Arg0), Local0) Store (Subtract (Local0, 0x08), Local1) CreateField (Arg0, 0x40, Multiply (Local1, 0x08), TEMP) Name (STS0, Buffer (0x04) { 0x00, 0x00, 0x00, 0x00 }) Concatenate (STS0, TEMP, Local2) _OSC (Buffer (0x10) { 0x16, 0xA6, 0x77, 0x40, 0x0C, 0x29, 0xBE, 0x47, 0x9E, 0xBD, 0xD8, 0x70, 0x58, 0x71, 0x39, 0x53 }, REVS, SIZE, Local2) } Method (_OSC, 4, NotSerialized) { CreateDWordField (Arg3, Zero, STS0) CreateDWordField (Arg3, 0x04, CAP0) CreateDWordField (Arg0, Zero, IID0) CreateDWordField (Arg0, 0x04, IID1) CreateDWordField (Arg0, 0x08, IID2) CreateDWordField (Arg0, 0x0C, IID3) Name (UID0, Buffer (0x10) { 0x16, 0xA6, 0x77, 0x40, 0x0C, 0x29, 0xBE, 0x47, 0x9E, 0xBD, 0xD8, 0x70, 0x58, 0x71, 0x39, 0x53 }) CreateDWordField (UID0, Zero, EID0) CreateDWordField (UID0, 0x04, EID1) CreateDWordField (UID0, 0x08, EID2) CreateDWordField (UID0, 0x0C, EID3) If (LNot (LAnd (LAnd (LEqual (IID0, EID0), LEqual (IID1, EID1)), LAnd (LEqual (IID2, EID2), LEqual (IID3, EID3))))) { Store (0x06, STS0) Return (Arg3) } If (LNot (LEqual (Arg1, One))) { Store (0x0A, STS0) Return (Arg3) } Or (And (TYPE, 0x7FFFFFFF), CAP0, TYPE) If (And (CFGD, One)) { If (LAnd (LAnd (And (CFGD, 0x01000000), LEqual (And (TYPE, 0x09), 0x09)), LNot (And (TBLD, One)))) { Or (TBLD, One, TBLD) Load (STBL, HNDL) } } If (And (CFGD, 0xF0)) { If (LAnd (LAnd (And (CFGD, 0x01000000), And (TYPE, 0x18)), LNot (And (TBLD, 0x02)))) { Or (TBLD, 0x02, TBLD) } } Return (Arg3) } } } Name (DP80, 0x80) Name (DP90, 0x90) Name (APIC, One) Name (PMBS, 0x0800) Name (PMLN, 0x80) Name (GPBS, 0x0480) Name (GPLN, 0x40) Name (SMBS, Zero) Name (SMBL, Zero) Name (PM30, 0x0830) Name (SUSW, 0xFF) Name (SMIR, 0xB2) Name (TPBA, 0xFED40000) Name (TPBL, Zero) Name (SMIP, 0xB2) Name (PCIB, 0xE0000000) Name (PCIL, 0x04000000) OperationRegion (BIOS, SystemMemory, 0x7F7CE064, 0xFF) Field (BIOS, ByteAcc, NoLock, Preserve) { SS1, 1, SS2, 1, SS3, 1, SS4, 1, Offset (0x01), IOST, 16, TOPM, 32, ROMS, 32, MG1B, 32, MG1L, 32, MG2B, 32, MG2L, 32, SPEE, 8, DMAX, 8, HPTA, 32, CPB0, 32, CPB1, 32, CPB2, 32, CPB3, 32, ASSB, 8, AOTB, 8, AAXB, 32, DTSF, 8, DTSE, 8, DTS1, 8, DTS2, 8, MPEN, 8, TPMF, 8, MG3B, 32, MG3L, 32, MH1B, 32, MH1L, 32 } Method (RRIO, 4, NotSerialized) { Store ("RRIO", Debug) } Method (RDMA, 3, NotSerialized) { Store ("rDMA", Debug) } Name (PICM, Zero) Method (_PIC, 1, NotSerialized) { If (Arg0) { Store (0xAA, DBG8) } Else { Store (0xAC, DBG8) } Store (Arg0, PICM) } Name (OSVR, Ones) Method (OSFL, 0, NotSerialized) { If (LNot (LEqual (OSVR, Ones))) { Return (OSVR) } If (LEqual (PICM, Zero)) { Store (0xAC, DBG8) } Store (One, OSVR) If (CondRefOf (_OSI, Local1)) { If (_OSI ("Windows 2000")) { Store (0x04, OSVR) } If (_OSI ("Windows 2001")) { Store (Zero, OSVR) } If (_OSI ("Windows 2001 SP1")) { Store (Zero, OSVR) } If (_OSI ("Windows 2001 SP2")) { Store (Zero, OSVR) } If (_OSI ("Windows 2001.1")) { Store (Zero, OSVR) } If (_OSI ("Windows 2001.1 SP1")) { Store (Zero, OSVR) } If (_OSI ("Windows 2006")) { Store (Zero, OSVR) } } Else { If (MCTH (_OS, "Microsoft Windows NT")) { Store (0x04, OSVR) } Else { If (MCTH (_OS, "Microsoft WindowsME: Millennium Edition")= ) { Store (0x02, OSVR) } If (MCTH (_OS, "Linux")) { Store (0x03, OSVR) } } } Return (OSVR) } Method (MCTH, 2, NotSerialized) { If (LLess (SizeOf (Arg0), SizeOf (Arg1))) { Return (Zero) } Add (SizeOf (Arg0), One, Local0) Name (BUF0, Buffer (Local0) {}) Name (BUF1, Buffer (Local0) {}) Store (Arg0, BUF0) Store (Arg1, BUF1) While (Local0) { Decrement (Local0) If (LNot (LEqual (DerefOf (Index (BUF0, Local0)), DerefOf (Index (BUF1, Local0))))) { Return (Zero) } } Return (One) } Name (PRWP, Package (0x02) { Zero, Zero }) Method (GPRW, 2, NotSerialized) { Store (Arg0, Index (PRWP, Zero)) Store (ShiftLeft (SS1, One), Local0) Or (Local0, ShiftLeft (SS2, 0x02), Local0) Or (Local0, ShiftLeft (SS3, 0x03), Local0) Or (Local0, ShiftLeft (SS4, 0x04), Local0) If (And (ShiftLeft (One, Arg1), Local0)) { Store (Arg1, Index (PRWP, One)) } Else { ShiftRight (Local0, One, Local0) If (LOr (LEqual (OSFL (), One), LEqual (OSFL (), 0x02))) { FindSetLeftBit (Local0, Index (PRWP, One)) } Else { FindSetRightBit (Local0, Index (PRWP, One)) } } Return (PRWP) } Name (WAKP, Package (0x02) { Zero, Zero }) OperationRegion (DEB0, SystemIO, DP80, One) Field (DEB0, ByteAcc, NoLock, Preserve) { DBG8, 8 } OperationRegion (DEB1, SystemIO, DP90, 0x02) Field (DEB1, WordAcc, NoLock, Preserve) { DBG9, 16 } Scope (_SB) { Name (PR00, Package (0x12) { Package (0x04) { 0x0001FFFF, Zero, LNKA, Zero }, Package (0x04) { 0x0001FFFF, One, LNKB, Zero }, Package (0x04) { 0x0001FFFF, 0x02, LNKC, Zero }, Package (0x04) { 0x0001FFFF, 0x03, LNKD, Zero }, Package (0x04) { 0x001FFFFF, Zero, LNKC, Zero }, Package (0x04) { 0x001FFFFF, One, LNKD, Zero }, Package (0x04) { 0x001DFFFF, Zero, LNKH, Zero }, Package (0x04) { 0x001DFFFF, One, LNKD, Zero }, Package (0x04) { 0x001DFFFF, 0x02, LNKC, Zero }, Package (0x04) { 0x001DFFFF, 0x03, LNKA, Zero }, Package (0x04) { 0x001EFFFF, Zero, LNKB, Zero }, Package (0x04) { 0x001EFFFF, One, LNKE, Zero }, Package (0x04) { 0x001BFFFF, Zero, LNKA, Zero }, Package (0x04) { 0x001CFFFF, Zero, LNKA, Zero }, Package (0x04) { 0x001CFFFF, One, LNKB, Zero }, Package (0x04) { 0x001CFFFF, 0x02, LNKC, Zero }, Package (0x04) { 0x001CFFFF, 0x03, LNKD, Zero }, Package (0x04) { 0x0002FFFF, Zero, LNKA, Zero } }) Name (AR00, Package (0x12) { Package (0x04) { 0x0001FFFF, Zero, Zero, 0x10 }, Package (0x04) { 0x0001FFFF, One, Zero, 0x11 }, Package (0x04) { 0x0001FFFF, 0x02, Zero, 0x12 }, Package (0x04) { 0x0001FFFF, 0x03, Zero, 0x13 }, Package (0x04) { 0x001FFFFF, Zero, Zero, 0x12 }, Package (0x04) { 0x001FFFFF, One, Zero, 0x13 }, Package (0x04) { 0x001DFFFF, Zero, Zero, 0x17 }, Package (0x04) { 0x001DFFFF, One, Zero, 0x13 }, Package (0x04) { 0x001DFFFF, 0x02, Zero, 0x12 }, Package (0x04) { 0x001DFFFF, 0x03, Zero, 0x10 }, Package (0x04) { 0x001EFFFF, Zero, Zero, 0x11 }, Package (0x04) { 0x001EFFFF, One, Zero, 0x14 }, Package (0x04) { 0x001BFFFF, Zero, Zero, 0x10 }, Package (0x04) { 0x001CFFFF, Zero, Zero, 0x10 }, Package (0x04) { 0x001CFFFF, One, Zero, 0x11 }, Package (0x04) { 0x001CFFFF, 0x02, Zero, 0x12 }, Package (0x04) { 0x001CFFFF, 0x03, Zero, 0x13 }, Package (0x04) { 0x0002FFFF, Zero, Zero, 0x10 } }) Name (PR04, Package (0x01) { Package (0x04) { 0x0004FFFF, Zero, LNKA, Zero } }) Name (AR04, Package (0x01) { Package (0x04) { 0x0004FFFF, Zero, Zero, 0x10 } }) Name (PR02, Package (0x04) { Package (0x04) { 0xFFFF, Zero, LNKB, Zero }, Package (0x04) { 0xFFFF, One, LNKC, Zero }, Package (0x04) { 0xFFFF, 0x02, LNKD, Zero }, Package (0x04) { 0xFFFF, 0x03, LNKA, Zero } }) Name (AR02, Package (0x04) { Package (0x04) { 0xFFFF, Zero, Zero, 0x11 }, Package (0x04) { 0xFFFF, One, Zero, 0x12 }, Package (0x04) { 0xFFFF, 0x02, Zero, 0x13 }, Package (0x04) { 0xFFFF, 0x03, Zero, 0x10 } }) Name (PR03, Package (0x04) { Package (0x04) { 0xFFFF, Zero, LNKC, Zero }, Package (0x04) { 0xFFFF, One, LNKD, Zero }, Package (0x04) { 0xFFFF, 0x02, LNKA, Zero }, Package (0x04) { 0xFFFF, 0x03, LNKB, Zero } }) Name (AR03, Package (0x04) { Package (0x04) { 0xFFFF, Zero, Zero, 0x12 }, Package (0x04) { 0xFFFF, One, Zero, 0x13 }, Package (0x04) { 0xFFFF, 0x02, Zero, 0x10 }, Package (0x04) { 0xFFFF, 0x03, Zero, 0x11 } }) Name (PR07, Package (0x04) { Package (0x04) { 0xFFFF, Zero, LNKD, Zero }, Package (0x04) { 0xFFFF, One, LNKA, Zero }, Package (0x04) { 0xFFFF, 0x02, LNKB, Zero }, Package (0x04) { 0xFFFF, 0x03, LNKC, Zero } }) Name (AR07, Package (0x04) { Package (0x04) { 0xFFFF, Zero, Zero, 0x13 }, Package (0x04) { 0xFFFF, One, Zero, 0x10 }, Package (0x04) { 0xFFFF, 0x02, Zero, 0x11 }, Package (0x04) { 0xFFFF, 0x03, Zero, 0x12 } }) Name (PR08, Package (0x04) { Package (0x04) { 0xFFFF, Zero, LNKA, Zero }, Package (0x04) { 0xFFFF, One, LNKB, Zero }, Package (0x04) { 0xFFFF, 0x02, LNKC, Zero }, Package (0x04) { 0xFFFF, 0x03, LNKD, Zero } }) Name (AR08, Package (0x04) { Package (0x04) { 0xFFFF, Zero, Zero, 0x10 }, Package (0x04) { 0xFFFF, One, Zero, 0x11 }, Package (0x04) { 0xFFFF, 0x02, Zero, 0x12 }, Package (0x04) { 0xFFFF, 0x03, Zero, 0x13 } }) Name (PR09, Package (0x04) { Package (0x04) { 0xFFFF, Zero, LNKB, Zero }, Package (0x04) { 0xFFFF, One, LNKC, Zero }, Package (0x04) { 0xFFFF, 0x02, LNKD, Zero }, Package (0x04) { 0xFFFF, 0x03, LNKA, Zero } }) Name (AR09, Package (0x04) { Package (0x04) { 0xFFFF, Zero, Zero, 0x11 }, Package (0x04) { 0xFFFF, One, Zero, 0x12 }, Package (0x04) { 0xFFFF, 0x02, Zero, 0x13 }, Package (0x04) { 0xFFFF, 0x03, Zero, 0x10 } }) Name (PRSA, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {3,4,5,6,7,10,11,12,14,15} }) Alias (PRSA, PRSB) Alias (PRSA, PRSC) Alias (PRSA, PRSD) Alias (PRSA, PRSE) Alias (PRSA, PRSF) Alias (PRSA, PRSG) Alias (PRSA, PRSH) Device (PCI0) { Name (_HID, EisaId ("PNP0A08")) Name (_ADR, Zero) Method (^BN00, 0, NotSerialized) { Return (Zero) } Method (_BBN, 0, NotSerialized) { Return (BN00 ()) } Name (_UID, Zero) Method (_PRT, 0, NotSerialized) { If (PICM) { Return (AR00) } Return (PR00) } Method (_S3D, 0, NotSerialized) { If (LOr (LEqual (OSFL (), One), LEqual (OSFL (), 0x02))) { Return (0x02) } Else { Return (0x03) } } Name (_CID, 0x030AD041) Device (MCH) { Name (_HID, EisaId ("PNP0C01")) Name (_UID, 0x0A) Name (_CRS, ResourceTemplate () { Memory32Fixed (ReadWrite, 0xFED13000, 0x00007000) }) } Method (NPTS, 1, NotSerialized) { } Method (NWAK, 1, NotSerialized) { } Device (P0PC) { Name (_ADR, 0x00010000) Method (_PRW, 0, NotSerialized) { Return (GPRW (0x09, 0x04)) } } Device (P0P4) { Name (_ADR, 0x001E0000) Method (_PRW, 0, NotSerialized) { Return (GPRW (0x0B, 0x04)) } Method (_PRT, 0, NotSerialized) { If (PICM) { Return (AR04) } Return (PR04) } Device (CBC0) { Name (_ADR, 0x00040000) OperationRegion (CBR0, PCI_Config, Zero, 0xE4) Field (CBR0, DWordAcc, NoLock, Preserve) { Offset (0x44), C044, 32, Offset (0x91), C091, 8, Offset (0xA4), C0A4, 8, C0A5, 8, Offset (0xE0), C0E0, 8, C0E1, 8 } Method (_STA, 0, NotSerialized) { Return (0x0F) } Method (_S3D, 0, NotSerialized) { Return (0x03) } Method (_INI, 0, NotSerialized) { Or (C0A5, 0x81, C0A5) And (C091, 0x7F, C091) Store (Zero, C0A4) } Method (CEV0, 0, NotSerialized) { And (C0A5, 0x80, Local0) Store (0xCB, DBG8) If (Local0) { Notify (CBC0, 0x02) Sleep (0x0BB8) And (C0A5, 0xFE, Local1) Store (Local1, C0A5) Or (Local1, One, Local1) Store (Local1, C0A5) } } Method (_PRW, 0, NotSerialized) { Return (GPRW (0x0B, 0x03)) } } Device (CBC2) { Name (_ADR, 0x00040002) } Device (CBC3) { Name (_ADR, 0x00040003) } Device (CBC4) { Name (_ADR, 0x00040004) } } Device (SBRG) { Name (_ADR, 0x001F0000) Device (IELK) { Name (_HID, "AWY0001") OperationRegion (RXA0, PCI_Config, 0xA0, 0x20) Field (RXA0, ByteAcc, NoLock, Preserve) { , 9, PBLV, 1, Offset (0x10), , 1, PBMS, 1, , 1, PMCS, 1, ECNS, 1, Offset (0x11), ECT1, 16, ELEN, 1, Offset (0x14) } Method (\_GPE._L0A, 0, NotSerialized) { Notify (\_SB.PCI0.SBRG.IELK, 0x81) Store (One, \_SB.PCI0.SBRG.IELK.PMCS) } Method (_STA, 0, NotSerialized) { If (ELEN) { Return (0x0F) } Else { Return (Zero) } } Method (SMOD, 1, NotSerialized) { } Method (GPBS, 0, NotSerialized) { Return (XOr (PBLV, One)) } } Method (SPTS, 1, NotSerialized) { Store (One, PS1S) Store (One, PS1E) Store (One, SLPS) } Method (SWAK, 1, NotSerialized) { Store (Zero, SLPS) Store (Zero, PS1E) If (BRTC) {} Else { Notify (PWRB, 0x02) } } OperationRegion (APMP, SystemIO, SMIR, 0x02) Field (APMP, ByteAcc, NoLock, Preserve) { APMC, 8, APMS, 8 } Field (APMP, ByteAcc, NoLock, Preserve) { Offset (0x01), , 1, BRTC, 1 } OperationRegion (PMS0, SystemIO, PMBS, 0x04) Field (PMS0, ByteAcc, NoLock, Preserve) { , 10, RTCS, 1, , 4, WAKS, 1, Offset (0x03), PWBT, 1, Offset (0x04) } OperationRegion (SMIE, SystemIO, PM30, 0x08) Field (SMIE, ByteAcc, NoLock, Preserve) { , 4, PS1E, 1, , 31, PS1S, 1, Offset (0x08) } Scope (\_SB) { } Device (PIC) { Name (_HID, EisaId ("PNP0000")) Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0020, 0x0020, 0x00, 0x02) IO (Decode16, 0x00A0, 0x00A0, 0x00, 0x02) IRQNoFlags () {2} }) } Device (DMAD) { Name (_HID, EisaId ("PNP0200")) Name (_CRS, ResourceTemplate () { DMA (Compatibility, BusMaster, Transfer8) {4} IO (Decode16, 0x0000, 0x0000, 0x00, 0x10) IO (Decode16, 0x0081, 0x0081, 0x00, 0x03) IO (Decode16, 0x0087, 0x0087, 0x00, 0x01) IO (Decode16, 0x0089, 0x0089, 0x00, 0x03) IO (Decode16, 0x008F, 0x008F, 0x00, 0x01) IO (Decode16, 0x00C0, 0x00C0, 0x00, 0x20) }) } Device (TMR) { Name (_HID, EisaId ("PNP0100")) Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0040, 0x0040, 0x00, 0x04) IRQNoFlags () {0} }) } Device (RTC0) { Name (_HID, EisaId ("PNP0B00")) Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0070, 0x0070, 0x00, 0x02) IRQNoFlags () {8} }) } Device (PS2K) { Name (_HID, EisaId ("PNP0303")) Name (_CID, 0x0B03D041) Method (_STA, 0, NotSerialized) { ShiftLeft (One, 0x0A, Local0) If (And (IOST, Local0)) { Return (0x0F) } Return (Zero) } Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0060, 0x0060, 0x00, 0x01) IO (Decode16, 0x0064, 0x0064, 0x00, 0x01) IRQNoFlags () {1} }) } Device (PS2M) { Name (_HID, EisaId ("PNP0F03")) Name (_CID, 0x130FD041) Method (_STA, 0, NotSerialized) { ShiftLeft (One, 0x0C, Local0) If (And (IOST, Local0)) { Return (0x0F) } Return (Zero) } Name (_CRS, ResourceTemplate () { IRQNoFlags () {12} }) } Device (SPKR) { Name (_HID, EisaId ("PNP0800")) Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0061, 0x0061, 0x00, 0x01) }) } Device (COPR) { Name (_HID, EisaId ("PNP0C04")) Name (_CRS, ResourceTemplate () { IO (Decode16, 0x00F0, 0x00F0, 0x00, 0x10) IRQNoFlags () {13} }) } Device (RMSC) { Name (_HID, EisaId ("PNP0C02")) Name (_UID, 0x10) Name (CRS, ResourceTemplate () { IO (Decode16, 0x0010, 0x0010, 0x00, 0x10) IO (Decode16, 0x0022, 0x0022, 0x00, 0x1E) IO (Decode16, 0x0044, 0x0044, 0x00, 0x1C) IO (Decode16, 0x0063, 0x0063, 0x00, 0x01) IO (Decode16, 0x0065, 0x0065, 0x00, 0x01) IO (Decode16, 0x0067, 0x0067, 0x00, 0x09) IO (Decode16, 0x0072, 0x0072, 0x00, 0x0E) IO (Decode16, 0x0080, 0x0080, 0x00, 0x01) IO (Decode16, 0x0084, 0x0084, 0x00, 0x03) IO (Decode16, 0x0088, 0x0088, 0x00, 0x01) IO (Decode16, 0x008C, 0x008C, 0x00, 0x03) IO (Decode16, 0x0090, 0x0090, 0x00, 0x10) IO (Decode16, 0x00A2, 0x00A2, 0x00, 0x1E) IO (Decode16, 0x00E0, 0x00E0, 0x00, 0x10) IO (Decode16, 0x04D0, 0x04D0, 0x00, 0x02) IO (Decode16, 0x0000, 0x0000, 0x00, 0x00) IO (Decode16, 0x0000, 0x0000, 0x00, 0x00) IO (Decode16, 0x0000, 0x0000, 0x00, 0x00) Memory32Fixed (ReadOnly, 0xFFF80000, 0x00080000) Memory32Fixed (ReadOnly, 0xFFB80000, 0x0017D000) Memory32Fixed (ReadWrite, 0xFED1C000, 0x00004000)= Memory32Fixed (ReadWrite, 0xFED20000, 0x00070000)= Memory32Fixed (ReadOnly, 0xFFF80000, 0x00080000) }) Method (_CRS, 0, NotSerialized) { CreateWordField (CRS, 0x7A, GP00) CreateWordField (CRS, 0x7C, GP01) CreateByteField (CRS, 0x7F, GP0L) Store (PMBS, GP00) Store (PMBS, GP01) Store (PMLN, GP0L) If (SMBS) { CreateWordField (CRS, 0x82, GP10) CreateWordField (CRS, 0x84, GP11) CreateByteField (CRS, 0x87, GP1L) Store (SMBS, GP10) Store (SMBS, GP11) Store (SMBL, GP1L) } If (GPBS) { CreateWordField (CRS, 0x8A, GP20) CreateWordField (CRS, 0x8C, GP21) CreateByteField (CRS, 0x8F, GP2L) Store (GPBS, GP20) Store (GPBS, GP21) Store (GPLN, GP2L) } Return (CRS) } } Device (HPET) { Name (_HID, EisaId ("PNP0103")) Name (CRS, ResourceTemplate () { Memory32Fixed (ReadOnly, 0xFED00000, 0x00000400) }) OperationRegion (^LPCR, SystemMemory, 0xFED1F404, 0x0= 4) Field (LPCR, AnyAcc, NoLock, Preserve) { HPTS, 2, , 5, HPTE, 1, Offset (0x04) } Method (_STA, 0, NotSerialized) { If (LEqual (OSFL (), Zero)) { If (HPTE) { Return (0x0F) } } Else { If (HPTE) { Return (0x0B) } } Return (Zero) } Method (_CRS, 0, NotSerialized) { CreateDWordField (CRS, 0x04, HPT) Multiply (HPTS, 0x1000, Local0) Add (Local0, 0xFED00000, HPT) Return (CRS) } } OperationRegion (RX80, PCI_Config, Zero, 0xFF) Field (RX80, ByteAcc, NoLock, Preserve) { Offset (0x80), LPCD, 16, LPCE, 16 } Name (DBPT, Package (0x04) { Package (0x08) { 0x03F8, 0x02F8, 0x0220, 0x0228, 0x0238, 0x02E8, 0x0338, 0x03E8 }, Package (0x08) { 0x03F8, 0x02F8, 0x0220, 0x0228, 0x0238, 0x02E8, 0x0338, 0x03E8 }, Package (0x03) { 0x0378, 0x0278, 0x03BC }, Package (0x02) { 0x03F0, 0x0370 } }) Name (DDLT, Package (0x04) { Package (0x02) { Zero, 0xFFF8 }, Package (0x02) { 0x04, 0xFF8F }, Package (0x02) { 0x08, 0xFCFF }, Package (0x02) { 0x0C, 0xEFFF } }) Method (RRIO, 4, NotSerialized) { If (LAnd (LNot (LGreater (Arg0, 0x03)), LNot (LLess (Arg0, Zero)))) { Store (Match (DerefOf (Index (DBPT, Arg0)), MEQ, Arg2, MTR, Zero, Zero), Local0) If (LNot (LEqual (Local0, Ones))) { Store (DerefOf (Index (DerefOf (Index (DDLT, Arg0)), Zero)), Local1) Store (DerefOf (Index (DerefOf (Index (DDLT, Arg0)), One)), Local2) ShiftLeft (Local0, Local1, Local0) And (LPCD, Local2, LPCD) Or (LPCD, Local0, LPCD) WX82 (Arg0, Arg1) } } If (LEqual (Arg0, 0x08)) { If (LEqual (Arg2, 0x0200)) { WX82 (0x08, Arg0) } Else { If (LEqual (Arg2, 0x0208)) { WX82 (0x09, Arg0) } } } If (LAnd (LNot (LGreater (Arg0, 0x0D)), LNot (LLess (Arg0, 0x0A)))) { WX82 (Arg0, Arg1) } } Method (WX82, 2, NotSerialized) { ShiftLeft (One, Arg0, Local0) If (Arg1) { Or (LPCE, Local0, LPCE) } Else { Not (Local0, Local0) And (LPCE, Local0, LPCE) } } Method (RDMA, 3, NotSerialized) { } Scope (\) { Field (BIOS, ByteAcc, NoLock, Preserve) { Offset (0x22), OSYS, 16, SMIF, 8, BLID, 8, ACPR, 32, CADL, 16, PADL, 16, IGDS, 8, CSTE, 16, NSTE, 16, SSTE, 16, CTID, 8 } } Device (EC) { Name (_HID, EisaId ("PNP0C09")) Name (_GPE, 0x19) Name (MYEC, Zero) Name (CTSD, Zero) Name (\PPCL, Zero) Method (_REG, 2, NotSerialized) { If (LEqual (Arg0, 0x03)) { Store (Arg1, MYEC) } Store (Zero, CTSD) Store (Zero, PPCL) } Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0062, 0x0062, 0x00, 0x01) IO (Decode16, 0x0066, 0x0066, 0x00, 0x01) }) OperationRegion (EC, EmbeddedControl, Zero, 0xFF) Field (EC, ByteAcc, NoLock, Preserve) { SMPR, 8, SMST, 8, SMAD, 8, SMCM, 8, SMD0, 264, SMAA, 8, Offset (0x30), POWS, 1, LIDS, 1, KBCS, 1, Offset (0x31), MBTS, 1, MBCS, 1, MBDS, 1, MBFS, 1, MBWS, 1, MBLS, 1, MBCL, 1, MBFL, 1, Offset (0x38), MDCL, 8, MDCH, 8, MDVL, 8, MDVH, 8, MCAL, 8, MCAH, 8, MSTL, 8, MSTH, 8, MCCL, 8, MCCH, 8, MPOL, 8, MPOH, 8, MFCL, 8, MFCH, 8, MCUL, 8, MCUH, 8, MRCL, 8, MRCH, 8, MVOL, 8, MVOH, 8, MTEL, 8, MTEH, 8, RSV1, 8, RSV2, 8, SDCL, 8, SDCH, 8, SDVL, 8, SDVH, 8, SCAL, 8, SCAH, 8, SSTL, 8, SSTH, 8, SCCL, 8, SCCH, 8, SPOL, 8, SPOH, 8, SFCL, 8, SFCH, 8, SCUL, 8, SCUH, 8, SRCL, 8, SRCH, 8, SVOL, 8, SVOH, 8, STEL, 8, STEH, 8, Offset (0x68), CPUT, 8, Offset (0x7E), RES1, 3, CHET, 1, RES2, 4, Offset (0x80), SYST, 8 } OperationRegion (APMP, SystemIO, 0xB2, 0x02) Field (APMP, ByteAcc, NoLock, Preserve) { APMC, 8, APMS, 8 } Device (ADP1) { Name (_HID, "ACPI0003") Name (BFLG, One) Name (ACP, One) Name (INIT, One) Method (_PSR, 0, NotSerialized) { If (ACP) { Return (One) } Else { Return (Zero) } } Method (_STA, 0, NotSerialized) { If (MYEC) { If (INIT) { Store (MBTS, Local0) If (LEqual (Local0, One)) { Store (One, BFLG) } Else { Store (Zero, BFLG) } Store (POWS, Local0) If (LEqual (Local0, One)) { Store (One, ACP) } Else { Store (Zero, ACP) } } Store (Zero, INIT) } Return (0x0F) } Name (_PCL, Package (0x01) { _SB }) } Name (BIF0, Package (0x0D) { One, 0x1130, 0x1130, One, 0x39D0, Zero, Zero, One, One, "BAT1", "1234", "LION", "MSI Corp." }) Name (STAT, Package (0x04) { 0x02, 0x0500, 0x0800, 0x03E8 }) Device (BAT1) { Name (_HID, EisaId ("PNP0C0A")) Name (_UID, One) Name (_PCL, Package (0x01) { _SB }) Method (_STA, 0, NotSerialized) { If (^^ADP1.BFLG) { Return (0x1F) } Else { Return (0x0F) } } Method (_BIF, 0, NotSerialized) { If (MYEC) { UPBI () } Else { IVBI () Store (0x99, DBG8) Sleep (0x03E8) } Return (BIF0) } Method (_BST, 0, NotSerialized) { If (MYEC) { UPBS () } Else { IVBS () } Return (STAT) } Method (IVBI, 0, NotSerialized) { Store (Ones, Index (BIF0, One)) Store (Ones, Index (BIF0, 0x02)) Store (Ones, Index (BIF0, 0x04)) Store ("Wrong", Index (BIF0, 0x09)) Store (" ", Index (BIF0, 0x0A)) Store ("Wrong", Index (BIF0, 0x0B)) Store ("Wrong", Index (BIF0, 0x0C)) } Method (IVBS, 0, NotSerialized) { Store (Zero, Index (STAT, Zero)) Store (Ones, Index (STAT, One)) Store (Ones, Index (STAT, 0x02)) Store (0x2710, Index (STAT, 0x03)) } Method (UPBI, 0, NotSerialized) { Store (Zero, Local0) Store (Zero, Local1) Store (Zero, Local2) Store (Zero, Local3) Store (MDCH, Local0) Store (MDCL, Local1) ShiftLeft (Local0, 0x08, Local0) Or (Local0, Local1, Local0) Store (Local0, Index (BIF0, One)) Store (MFCH, Local0) Store (MFCL, Local1) ShiftLeft (Local0, 0x08, Local0) Or (Local0, Local1, Local1) Store (Local1, Index (BIF0, 0x02)) Store (MDVH, Local0) Store (MDVL, Local2) ShiftLeft (Local0, 0x08, Local0) Or (Local0, Local2, Local2) Store (Local2, Index (BIF0, 0x04)) If (LEqual (CTID, One)) { Store (CTID, DBG8) Sleep (0x0BB8) Store (" LG ", Index (BIF0, 0x0C)) } } Method (UPBS, 0, NotSerialized) { Store (Zero, Local0) Store (Zero, Local1) Store (Zero, Local2) Store (Zero, Local3) Store (Zero, Local4) Store (Zero, Local7) Store (MBTS, Local0) If (LEqual (Local0, One)) { Store (POWS, Local0) If (LEqual (Local0, One)) { Store (MBCS, Local1) If (LEqual (Local1, One)) { Or (Local4, 0x02, Local4) } } Else { Or (Local4, One, Local4) Store (MBLS, Local0) If (LEqual (Local0, One)) { Or (Local4, 0x04, Local4) } } Store (POWS, Local0) If (LEqual (Local0, One)) { Store (MBCS, Local0) If (LEqual (Local0, One)) { Store (MCUH, Local0) Store (MCUL, Local1) ShiftLeft (Local0, 0x08, Local0) Or (Local0, Local1, Local1) If (LEqual (Local1, 0xFFFF)) { Store (Ones, Local1) } Store (Local1, Index (STAT, One))= } Else { Store (Zero, Index (STAT, One)) } } Else { Store (MCUH, Local0) Store (MCUL, Local1) ShiftLeft (Local0, 0x08, Local0) Or (Local0, Local1, Local1) XOr (Local1, 0xFFFF, Local1) If (LEqual (Local1, Zero)) { Store (Ones, Local1) } Store (Local1, Index (STAT, One)) } Store (MRCH, Local0) Store (MRCL, Local2) ShiftLeft (Local0, 0x08, Local0) Or (Local0, Local2, Local2) Store (Local2, Index (STAT, 0x02)) Store (MVOH, Local0) Store (MVOL, Local3) ShiftLeft (Local0, 0x08, Local0) Or (Local0, Local3, Local3) Store (Local3, Index (STAT, 0x03)) Store (Local4, Index (STAT, Zero)) Sleep (0x64) } Else { IVBS () } } } Method (_Q80, 0, NotSerialized) { Store (0x80, DBG8) } Method (_Q81, 0, NotSerialized) { If (LEqual (SPEE, Zero)) { Store (0x68, DBG8) Store (0x68, APMC) } Else { Store (0x81, DBG8) Or (One, PPCL, PPCL) Notify (\_PR.CPU1, 0x80) Notify (\_PR.CPU2, 0x80) } Store (One, CHET) } Method (_Q82, 0, NotSerialized) { If (LEqual (SPEE, Zero)) { Store (0x69, DBG8) Store (0x69, APMC) } Else { Store (0x82, DBG8) And (0xFE, PPCL, PPCL) Notify (\_PR.CPU1, 0x80) Notify (\_PR.CPU2, 0x80) } Store (One, CHET) } Method (_Q83, 0, NotSerialized) { Store (0x83, DBG8) Store (Zero, Local0) Store (POWS, Local0) If (LEqual (Local0, One)) { Store (One, ^ADP1.ACP) } Else { Store (Zero, ^ADP1.ACP) } Notify (ADP1, 0x80) } Method (_Q84, 0, NotSerialized) { Store (0x84, DBG8) Notify (LID0, 0x80) } Method (_Q85, 0, NotSerialized) { Store (0x85, DBG8) Store (One, CTSD) Notify (\_TZ.THRM, 0x80) } Method (_Q86, 0, NotSerialized) { Store (0x86, DBG8) } Method (_Q87, 0, NotSerialized) { Store (0x87, DBG8) Store (Zero, Local0) Store (MBTS, Local0) If (LEqual (Local0, One)) { Store (One, ^ADP1.BFLG) Notify (BAT1, 0x80) } Else { Store (Zero, ^ADP1.BFLG) Notify (ADP1, 0x80) Sleep (0x19) Notify (BAT1, 0x81) } Notify (ADP1, 0x80) } Method (_Q88, 0, NotSerialized) { Store (0x88, DBG8) } Method (_Q89, 0, NotSerialized) { Store (0x89, DBG8) } Method (_Q8A, 0, NotSerialized) { Store (0x8A, DBG8) Store (One, CTSD) Notify (\_TZ.THRM, 0x80) } Method (_Q8B, 0, NotSerialized) { Store (0x8B, DBG8) } Method (_Q8C, 0, NotSerialized) { Store (0x8C, DBG8) } Method (_Q90, 0, NotSerialized) { Store (0x90, DBG8) } Method (_QB4, 0, NotSerialized) { Store (0xB4, DBG8) If (LEqual (DSEN, Zero)) { Store (0x10, SMIF) Store (0x70, APMC) If (LEqual (SMIF, Zero)) { Store (CADL, PADL) If (LEqual (OSFL (), Zero)) { Notify (PCI0, Zero) } Else { Notify (IGFX, Zero) } Sleep (0x02EE) Notify (IGFX, 0x80) } } If (LEqual (DSEN, One)) { Store (0x11, SMIF) Store (0x70, APMC) If (LEqual (SMIF, Zero)) { Notify (IGFX, 0x81) } } } Method (_QB5, 0, NotSerialized) { Store (0xB5, DBG8) } Method (_QB6, 0, NotSerialized) { Store (0xB6, DBG8) } Method (_QB7, 0, NotSerialized) { Store (0xB7, DBG8) } Method (_QB8, 0, NotSerialized) { Store (0xB8, DBG8) } Method (_QB9, 0, NotSerialized) { Store (0xB9, DBG8) } Scope (\_SB) { Name (SLPS, Zero) Device (SLPB) { Name (_HID, EisaId ("PNP0C0E")) } Device (LID0) { Name (_HID, EisaId ("PNP0C0D")) Method (_LID, 0, NotSerialized) { If (^^PCI0.SBRG.EC.MYEC) { Store (^^PCI0.SBRG.EC.LIDS, Local0) } Else { Store (One, Local0) } Return (Local0) } } } Scope (\_GPE) { Method (_L01, 0, NotSerialized) { Sleep (0xC8) Store (One, \_SB.PCI0.WAWA.PDC1) Store (One, \_SB.PCI0.WAWA.HPCS) } } Scope (^^^PCI0) { Device (WAWA) { Name (_ADR, 0x001C0000) OperationRegion (P1CS, PCI_Config, 0x40, 0x01= 00) Field (P1CS, AnyAcc, NoLock, WriteAsZeros) { Offset (0x1A), ABP1, 1, , 2, PDC1, 1, , 2, PDS1, 1, Offset (0x20), Offset (0x22), PSP1, 1, Offset (0x9C), , 30, HPCS, 1, PMCS, 1 } Device (PECA) { Name (_ADR, Zero) Method (_RMV, 0, NotSerialized) { Return (One) } } } } } Scope (^^PCI0) { Device (IGFX) { Name (\DSEN, One) Name (_ADR, 0x00020000) OperationRegion (APMP, SystemIO, 0xB2, 0x02) Field (APMP, ByteAcc, NoLock, Preserve) { APMC, 8, APMS, 8 } Method (_DOS, 1, NotSerialized) { Store (And (Arg0, 0x03), DSEN) } Method (_DOD, 0, NotSerialized) { Return (Package (0x03) { 0x00010100, 0x00010240, 0x00010410 }) } Device (CRT) { Name (_ADR, 0x0100) Method (_DCS, 0, NotSerialized) { Store (One, SMIF) Store (0x68, APMC) If (And (CSTE, 0x0101)) { Return (0x1F) } Return (0x1D) } Method (_DGS, 0, NotSerialized) { If (And (NSTE, 0x0101)) { Return (One) } Return (Zero) } Method (_DSS, 1, NotSerialized) { If (LEqual (And (Arg0, 0xC0000000), 0xC0000000)) { Store (NSTE, CSTE) } } } Device (DTV1) { Name (_ADR, 0x0240) Method (_DCS, 0, NotSerialized) { Store (One, SMIF) Store (0x68, APMC) If (And (CSTE, 0x0202)) { Return (0x1F) } Return (0x1D) } Method (_DGS, 0, NotSerialized) { If (And (NSTE, 0x0202)) { Return (One) } Return (Zero) } Method (_DSS, 1, NotSerialized) { If (LEqual (And (Arg0, 0xC0000000), 0xC0000000)) { Store (NSTE, CSTE) } } } Device (LCD) { Name (_ADR, 0x0410) Method (_DCS, 0, NotSerialized) { Store (One, SMIF) Store (0x68, APMC) If (And (CSTE, 0x0808)) { Return (0x1F) } Return (0x1D) } Method (_DGS, 0, NotSerialized) { If (And (NSTE, 0x0808)) { Return (One) } Return (Zero) } Method (_DSS, 1, NotSerialized) { If (LEqual (And (Arg0, 0xC0000000), 0xC0000000)) { Store (NSTE, CSTE) } } } } } Device (^PCIE) { Name (_HID, EisaId ("PNP0C02")) Name (_UID, 0x11) Name (CRS, ResourceTemplate () { Memory32Fixed (ReadOnly, 0xE0000000, 0x10000000) }) Method (_CRS, 0, NotSerialized) { CreateDWordField (CRS, 0x04, BAS1) CreateDWordField (CRS, 0x08, LEN1) Store (PCIB, BAS1) Store (PCIL, LEN1) Return (CRS) } } Scope (\_TZ) { ThermalZone (THRM) { Method (KLV, 1, NotSerialized) { Add (Arg0, 0x0111, Local0) Multiply (Local0, 0x0A, Local0) Return (Local0) } Method (_TMP, 0, NotSerialized) { If (\_SB.PCI0.SBRG.EC.MYEC) { If (\_SB.PCI0.SBRG.EC.CTSD) { Store (Zero, \_SB.PCI0.SBRG.EC.CTSD) Return (KLV (0x6E)) } Else { Store (\_SB.PCI0.SBRG.EC.CPUT, Local0= ) Store (Local0, DBG8) Return (KLV (Local0)) } } Else { Return (KLV (0x1E)) } } Method (_CRT, 0, NotSerialized) { Return (KLV (0x64)) } } } Device (OMSC) { Name (_HID, EisaId ("PNP0C02")) Name (_UID, Zero) Name (CRS, ResourceTemplate () { Memory32Fixed (ReadOnly, 0x00000000, 0x00000000) Memory32Fixed (ReadOnly, 0x00000000, 0x00000000) }) Method (_CRS, 0, NotSerialized) { If (APIC) { CreateDWordField (CRS, 0x08, ML01) CreateDWordField (CRS, 0x04, MB01) CreateDWordField (CRS, 0x14, ML02) CreateDWordField (CRS, 0x10, MB02) Store (0xFEC00000, MB01) Store (0x1000, ML01) Store (0xFEE00000, MB02) Store (0x1000, ML02) } Return (CRS) } } Device (^^RMEM) { Name (_HID, EisaId ("PNP0C01")) Name (_UID, One) Name (CRS, ResourceTemplate () { Memory32Fixed (ReadWrite, 0x00000000, 0x000A0000)= Memory32Fixed (ReadOnly, 0x00000000, 0x00000000) Memory32Fixed (ReadOnly, 0x000E0000, 0x00020000) Memory32Fixed (ReadWrite, 0x00100000, 0x00000000)= Memory32Fixed (ReadOnly, 0x00000000, 0x00000000) }) Method (_CRS, 0, NotSerialized) { CreateDWordField (CRS, 0x10, BAS1) CreateDWordField (CRS, 0x14, LEN1) CreateDWordField (CRS, 0x1C, BAS2) CreateDWordField (CRS, 0x20, LEN2) CreateDWordField (CRS, 0x2C, LEN3) CreateDWordField (CRS, 0x34, BAS4) CreateDWordField (CRS, 0x38, LEN4) If (OSFL ()) {} Else { If (MG1B) { If (LGreater (MG1B, 0x000C0000)) { Store (0x000C0000, BAS1) Subtract (MG1B, BAS1, LEN1) } } Else { Store (0x000C0000, BAS1) Store (0x00020000, LEN1) } If (Add (MG1B, MG1L, Local0)) { Store (Local0, BAS2) Subtract (0x00100000, BAS2, LEN2) } } Subtract (MG2B, 0x00100000, LEN3) Store (MH1B, BAS4) Subtract (Zero, BAS4, LEN4) Return (CRS) } } } Device (IDE0) { Name (_ADR, 0x001F0002) Name (^NATA, Package (0x01) { 0x001F0002 }) Name (REGF, One) Method (_REG, 2, NotSerialized) { If (LEqual (Arg0, 0x02)) { Store (Arg1, REGF) } } Name (TIM0, Package (0x08) { Package (0x04) { 0x78, 0xB4, 0xF0, 0x0384 }, Package (0x04) { 0x23, 0x21, 0x10, Zero }, Package (0x04) { 0x0B, 0x09, 0x04, Zero }, Package (0x06) { 0x70, 0x49, 0x36, 0x27, 0x19, 0x0F }, Package (0x06) { Zero, One, 0x02, One, 0x02, One }, Package (0x06) { Zero, Zero, Zero, One, One, One }, Package (0x04) { 0x04, 0x03, 0x02, Zero }, Package (0x04) { 0x02, One, Zero, Zero } }) Name (TMD0, Buffer (0x14) {}) CreateDWordField (TMD0, Zero, PIO0) CreateDWordField (TMD0, 0x04, DMA0) CreateDWordField (TMD0, 0x08, PIO1) CreateDWordField (TMD0, 0x0C, DMA1) CreateDWordField (TMD0, 0x10, CHNF) OperationRegion (CFG2, PCI_Config, 0x40, 0x20) Field (CFG2, DWordAcc, NoLock, Preserve) { PMPT, 4, PSPT, 4, PMRI, 6, Offset (0x02), SMPT, 4, SSPT, 4, SMRI, 6, Offset (0x04), PSRI, 4, SSRI, 4, Offset (0x08), PM3E, 1, PS3E, 1, SM3E, 1, SS3E, 1, Offset (0x0A), PMUT, 2, , 2, PSUT, 2, Offset (0x0B), SMUT, 2, , 2, SSUT, 2, Offset (0x0C), Offset (0x14), PM6E, 1, PS6E, 1, SM6E, 1, SS6E, 1, PMCR, 1, PSCR, 1, SMCR, 1, SSCR, 1, , 4, PMAE, 1, PSAE, 1, SMAE, 1, SSAE, 1 } Name (GMPT, Zero) Name (GMUE, Zero) Name (GMUT, Zero) Name (GMCR, Zero) Name (GSPT, Zero) Name (GSUE, Zero) Name (GSUT, Zero) Name (GSCR, Zero) Device (CHN0) { Name (_ADR, Zero) Method (_GTM, 0, NotSerialized) { ShiftLeft (PSCR, One, Local1) Or (PMCR, Local1, Local0) ShiftLeft (PMAE, 0x02, Local3) ShiftLeft (PM6E, One, Local4) Or (Local3, Local4, Local3) Or (PM3E, Local3, Local1) ShiftLeft (PMPT, 0x04, Local3) Or (Local1, Local3, Local1) ShiftLeft (PSAE, 0x02, Local3) ShiftLeft (PS6E, One, Local4) Or (Local3, Local4, Local3) Or (PS3E, Local3, Local2) ShiftLeft (PSPT, 0x04, Local3) Or (Local2, Local3, Local2) Return (GTM (PMRI, Local1, PMUT, PSRI, Local2, PSUT, Local0)) } Method (_STM, 3, NotSerialized) { Store (Arg0, Debug) Store (Arg0, TMD0) ShiftLeft (PMAE, 0x02, Local3) ShiftLeft (PM6E, One, Local4) Or (Local3, Local4, Local3) Or (PM3E, Local3, Local0) ShiftLeft (PMPT, 0x04, Local3) Or (Local0, Local3, Local0) ShiftLeft (PSAE, 0x02, Local3) ShiftLeft (PS6E, One, Local4) Or (Local3, Local4, Local3) Or (PS3E, Local3, Local1) ShiftLeft (PSPT, 0x04, Local3) Or (Local1, Local3, Local1) Store (PMRI, GMPT) Store (Local0, GMUE) Store (PMUT, GMUT) Store (PMCR, GMCR) Store (PSRI, GSPT) Store (Local1, GSUE) Store (PSUT, GSUT) Store (PSCR, GSCR) STM () Store (GMPT, PMRI) Store (GMUE, Local0) Store (GMUT, PMUT) Store (GMCR, PMCR) Store (GSUE, Local1) Store (GSUT, PSUT) Store (GSCR, PSCR) If (And (Local0, One)) { Store (One, PM3E) } Else { Store (Zero, PM3E) } If (And (Local0, 0x02)) { Store (One, PM6E) } Else { Store (Zero, PM6E) } If (And (Local0, 0x04)) { Store (One, PMAE) } Else { Store (Zero, PMAE) } If (And (Local1, One)) { Store (One, PS3E) } Else { Store (Zero, PS3E) } If (And (Local1, 0x02)) { Store (One, PS6E) } Else { Store (Zero, PS6E) } If (And (Local1, 0x04)) { Store (One, PSAE) } Else { Store (Zero, PSAE) } Store (GTF (Zero, Arg1), ATA0) Store (GTF (One, Arg2), ATA1) } Device (DRV0) { Name (_ADR, Zero) Method (_GTF, 0, NotSerialized) { Return (RATA (ATA0)) } } Device (DRV1) { Name (_ADR, One) Method (_GTF, 0, NotSerialized) { Return (RATA (ATA1)) } } } Device (CHN1) { Name (_ADR, One) Method (_GTM, 0, NotSerialized) { ShiftLeft (SSCR, One, Local1) Or (SMCR, Local1, Local0) ShiftLeft (SMAE, 0x02, Local3) ShiftLeft (SM6E, One, Local4) Or (Local3, Local4, Local3) Or (SM3E, Local3, Local1) ShiftLeft (SMPT, 0x04, Local3) Or (Local1, Local3, Local1) ShiftLeft (SSAE, 0x02, Local3) ShiftLeft (SS6E, One, Local4) Or (Local3, Local4, Local3) Or (SS3E, Local3, Local2) ShiftLeft (SSPT, 0x04, Local3) Or (Local2, Local3, Local2) Return (GTM (SMRI, Local1, SMUT, SSRI, Local2, SSUT, Local0)) } Method (_STM, 3, NotSerialized) { Store (Arg0, Debug) Store (Arg0, TMD0) ShiftLeft (SMAE, 0x02, Local3) ShiftLeft (SM6E, One, Local4) Or (Local3, Local4, Local3) Or (SM3E, Local3, Local0) ShiftLeft (SMPT, 0x04, Local3) Or (Local0, Local3, Local0) ShiftLeft (SSAE, 0x02, Local3) ShiftLeft (SS6E, One, Local4) Or (Local3, Local4, Local3) Or (SS3E, Local3, Local1) ShiftLeft (SSPT, 0x04, Local3) Or (Local1, Local3, Local1) Store (SMRI, GMPT) Store (Local0, GMUE) Store (SMUT, GMUT) Store (SMCR, GMCR) Store (SSRI, GSPT) Store (Local1, GSUE) Store (SSUT, GSUT) Store (SSCR, GSCR) STM () Store (GMPT, SMRI) Store (GMUE, Local0) Store (GMUT, SMUT) Store (GMCR, SMCR) Store (GSUE, Local1) Store (GSUT, SSUT) Store (GSCR, SSCR) If (And (Local0, One)) { Store (One, SM3E) } Else { Store (Zero, SM3E) } If (And (Local0, 0x02)) { Store (One, SM6E) } Else { Store (Zero, SM6E) } If (And (Local0, 0x04)) { Store (One, SMAE) } Else { Store (Zero, SMAE) } If (And (Local1, One)) { Store (One, SS3E) } Else { Store (Zero, SS3E) } If (And (Local1, 0x02)) { Store (One, SS6E) } Else { Store (Zero, SS6E) } If (And (Local1, 0x04)) { Store (One, SSAE) } Else { Store (Zero, SSAE) } Store (GTF (Zero, Arg1), ATA2) Store (GTF (One, Arg2), ATA3) } Device (DRV0) { Name (_ADR, Zero) Method (_GTF, 0, NotSerialized) { Return (RATA (ATA2)) } } Device (DRV1) { Name (_ADR, One) Method (_GTF, 0, NotSerialized) { Return (RATA (ATA3)) } } } Method (GTM, 7, Serialized) { Store (Ones, PIO0) Store (Ones, PIO1) Store (Ones, DMA0) Store (Ones, DMA1) Store (0x10, CHNF) If (REGF) {} Else { Return (TMD0) } If (And (Arg1, 0x20)) { Or (CHNF, 0x02, CHNF) } Store (Match (DerefOf (Index (TIM0, One)), MEQ, Arg0, MTR, Zero, Zero), Local6) Store (DerefOf (Index (DerefOf (Index (TIM0, Zero)), Local6)), Local7) Store (Local7, DMA0) Store (Local7, PIO0) If (And (Arg4, 0x20)) { Or (CHNF, 0x08, CHNF) } Store (Match (DerefOf (Index (TIM0, 0x02)), MEQ, Arg3, MTR, Zero, Zero), Local6) Store (DerefOf (Index (DerefOf (Index (TIM0, Zero)), Local6)), Local7) Store (Local7, DMA1) Store (Local7, PIO1) If (And (Arg1, 0x07)) { Store (Arg2, Local5) If (And (Arg1, 0x02)) { Add (Local5, 0x02, Local5) } If (And (Arg1, 0x04)) { Add (Local5, 0x04, Local5) } Store (DerefOf (Index (DerefOf (Index (TIM0, 0x03)), Local5)), DMA0) Or (CHNF, One, CHNF) } If (And (Arg4, 0x07)) { Store (Arg5, Local5) If (And (Arg4, 0x02)) { Add (Local5, 0x02, Local5) } If (And (Arg4, 0x04)) { Add (Local5, 0x04, Local5) } Store (DerefOf (Index (DerefOf (Index (TIM0, 0x03)), Local5)), DMA1) Or (CHNF, 0x04, CHNF) } Store (TMD0, Debug) Return (TMD0) } Method (STM, 0, Serialized) { If (REGF) {} Else { Store (Zero, GMUE) Store (Zero, GMUT) Store (Zero, GSUE) Store (Zero, GSUT) If (And (CHNF, One)) { Store (Match (DerefOf (Index (TIM0, 0x03)), MLE, DMA0, MTR, Zero, Zero), Local0) If (LGreater (Local0, 0x05)) { Store (0x05, Local0) } Store (DerefOf (Index (DerefOf (Index (TIM0, 0x04)), Local0)), GMUT) Or (GMUE, One, GMUE) If (LGreater (Local0, 0x02)) { Or (GMUE, 0x02, GMUE) } If (LGreater (Local0, 0x04)) { And (GMUE, 0xFD, GMUE) Or (GMUE, 0x04, GMUE) } } Else { If (Or (LEqual (PIO0, Ones), LEqual (PIO0, Zero))) { If (And (LLess (DMA0, Ones), LGreater (DMA0, Zero))) { Store (DMA0, PIO0) Or (GMUE, 0x80, GMUE) } } } If (And (CHNF, 0x04)) { Store (Match (DerefOf (Index (TIM0, 0x03)), MLE, DMA1, MTR, Zero, Zero), Local0) If (LGreater (Local0, 0x05)) { Store (0x05, Local0) } Store (DerefOf (Index (DerefOf (Index (TIM0, 0x04)), Local0)), GSUT) Or (GSUE, One, GSUE) If (LGreater (Local0, 0x02)) { Or (GSUE, 0x02, GSUE) } If (LGreater (Local0, 0x04)) { And (GSUE, 0xFD, GSUE) Or (GSUE, 0x04, GSUE) } } Else { If (Or (LEqual (PIO1, Ones), LEqual (PIO1, Zero))) { If (And (LLess (DMA1, Ones), LGreater (DMA1, Zero))) { Store (DMA1, PIO1) Or (GSUE, 0x80, GSUE) } } } If (And (CHNF, 0x02)) { Or (GMUE, 0x20, GMUE) } If (And (CHNF, 0x08)) { Or (GSUE, 0x20, GSUE) } And (Match (DerefOf (Index (TIM0, Zero)), MGE, PIO0, MTR, Zero, Zero), 0x07, Local0) Store (DerefOf (Index (DerefOf (Index (TIM0, One)), Local0)), Local1) Store (Local1, GMPT) If (LLess (Local0, 0x03)) { Or (GMUE, 0x50, GMUE) } And (Match (DerefOf (Index (TIM0, Zero)), MGE, PIO1, MTR, Zero, Zero), 0x07, Local0) Store (DerefOf (Index (DerefOf (Index (TIM0, 0x02)), Local0)), Local1) Store (Local1, GSPT) If (LLess (Local0, 0x03)) { Or (GSUE, 0x50, GSUE) } } } Name (AT01, Buffer (0x07) { 0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0xEF }) Name (AT02, Buffer (0x07) { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x90 }) Name (AT03, Buffer (0x07) { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xC6 }) Name (AT04, Buffer (0x07) { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x91 }) Name (ATA0, Buffer (0x1D) {}) Name (ATA1, Buffer (0x1D) {}) Name (ATA2, Buffer (0x1D) {}) Name (ATA3, Buffer (0x1D) {}) Name (ATAB, Buffer (0x1D) {}) CreateByteField (ATAB, Zero, CMDC) Method (GTFB, 3, Serialized) { Multiply (CMDC, 0x38, Local0) Add (Local0, 0x08, Local1) CreateField (ATAB, Local1, 0x38, CMDX) Multiply (CMDC, 0x07, Local0) CreateByteField (ATAB, Add (Local0, 0x02), A001) CreateByteField (ATAB, Add (Local0, 0x06), A005) Store (Arg0, CMDX) Store (Arg1, A001) Store (Arg2, A005) Increment (CMDC) } Method (GTF, 2, Serialized) { Store (Arg1, Debug) Store (Zero, CMDC) Name (ID49, 0x0C00) Name (ID59, Zero) Name (ID53, 0x04) Name (ID63, 0x0F00) Name (ID88, 0x0F00) Name (IRDY, One) Name (PIOT, Zero) Name (DMAT, Zero) If (LEqual (SizeOf (Arg1), 0x0200)) { CreateWordField (Arg1, 0x62, IW49) Store (IW49, ID49) CreateWordField (Arg1, 0x6A, IW53) Store (IW53, ID53) CreateWordField (Arg1, 0x7E, IW63) Store (IW63, ID63) CreateWordField (Arg1, 0x76, IW59) Store (IW59, ID59) CreateWordField (Arg1, 0xB0, IW88) Store (IW88, ID88) } Store (0xA0, Local7) If (Arg0) { Store (0xB0, Local7) And (CHNF, 0x08, IRDY) If (And (CHNF, 0x10)) { Store (PIO1, PIOT) } Else { Store (PIO0, PIOT) } If (And (CHNF, 0x04)) { If (And (CHNF, 0x10)) { Store (DMA1, DMAT) } Else { Store (DMA0, DMAT) } } } Else { And (CHNF, 0x02, IRDY) Store (PIO0, PIOT) If (And (CHNF, One)) { Store (DMA0, DMAT) } } If (LAnd (LAnd (And (ID53, 0x04), And (ID88, 0xFF00)), DMAT)) { Store (Match (DerefOf (Index (TIM0, 0x03)), MLE, DMAT, MTR, Zero, Zero), Local1) If (LGreater (Local1, 0x05)) { Store (0x05, Local1) } GTFB (AT01, Or (0x40, Local1), Local7) } Else { If (LAnd (And (ID63, 0xFF00), PIOT)) { And (Match (DerefOf (Index (TIM0, Zero)), MGE, PIOT, MTR, Zero, Zero), 0x03, Local0) Or (0x20, DerefOf (Index (DerefOf (Index (TIM0, 0x07)), Local0)), Local1) GTFB (AT01, Local1, Local7) } } If (IRDY) { And (Match (DerefOf (Index (TIM0, Zero)), MGE, PIOT, MTR, Zero, Zero), 0x07, Local0) Or (0x08, DerefOf (Index (DerefOf (Index (TIM0, 0x06)), Local0)), Local1) GTFB (AT01, Local1, Local7) } Else { If (And (ID49, 0x0400)) { GTFB (AT01, One, Local7) } } If (LAnd (And (ID59, 0x0100), And (ID59, 0xFF))) { GTFB (AT03, And (ID59, 0xFF), Local7) } Store (ATAB, Debug) Return (ATAB) } Method (RATA, 1, NotSerialized) { CreateByteField (Arg0, Zero, CMDN) Multiply (CMDN, 0x38, Local0) CreateField (Arg0, 0x08, Local0, RETB) Store (RETB, Debug) Concatenate (RETB, FZTF, RETB) Return (RETB) } Name (FZTF, Buffer (0x07) { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xF5 }) } Device (IDE1) { Name (_ADR, 0x001F0001) } Device (USB0) { Name (_ADR, 0x001D0000) OperationRegion (BAR0, PCI_Config, 0xC4, One) Field (BAR0, ByteAcc, NoLock, Preserve) { USBW, 2, Offset (0x01) } Method (_S3D, 0, NotSerialized) { If (LOr (LEqual (OSFL (), One), LEqual (OSFL (), 0x02= ))) { Return (0x02) } Else { Return (0x03) } } Method (_PSW, 1, NotSerialized) { If (Arg0) { Store (0x03, USBW) } Else { Store (Zero, USBW) } } Method (_PRW, 0, NotSerialized) { Return (GPRW (0x03, 0x03)) } } Device (USB1) { Name (_ADR, 0x001D0001) OperationRegion (BAR0, PCI_Config, 0xC4, One) Field (BAR0, ByteAcc, NoLock, Preserve) { USBW, 2, Offset (0x01) } Method (_S3D, 0, NotSerialized) { If (LOr (LEqual (OSFL (), One), LEqual (OSFL (), 0x02= ))) { Return (0x02) } Else { Return (0x03) } } Method (_PSW, 1, NotSerialized) { If (Arg0) { Store (0x03, USBW) } Else { Store (Zero, USBW) } } Method (_PRW, 0, NotSerialized) { Return (GPRW (0x04, 0x03)) } } Device (USB2) { Name (_ADR, 0x001D0002) OperationRegion (BAR0, PCI_Config, 0xC4, One) Field (BAR0, ByteAcc, NoLock, Preserve) { USBW, 2, Offset (0x01) } Method (_S3D, 0, NotSerialized) { If (LOr (LEqual (OSFL (), One), LEqual (OSFL (), 0x02= ))) { Return (0x02) } Else { Return (0x03) } } Method (_PSW, 1, NotSerialized) { If (Arg0) { Store (0x03, USBW) } Else { Store (Zero, USBW) } } Method (_PRW, 0, NotSerialized) { Return (GPRW (0x0C, 0x03)) } } Device (USB3) { Name (_ADR, 0x001D0003) OperationRegion (BAR0, PCI_Config, 0xC4, One) Field (BAR0, ByteAcc, NoLock, Preserve) { USBW, 2, Offset (0x01) } Method (_S3D, 0, NotSerialized) { If (LOr (LEqual (OSFL (), One), LEqual (OSFL (), 0x02= ))) { Return (0x02) } Else { Return (0x03) } } Method (_PSW, 1, NotSerialized) { If (Arg0) { Store (0x03, USBW) } Else { Store (Zero, USBW) } } } Device (EUSB) { Name (_ADR, 0x001D0007) Method (_PRW, 0, NotSerialized) { Return (GPRW (0x0D, 0x03)) } } Device (MC97) { Name (_ADR, 0x001E0003) } Device (AZAL) { Name (_ADR, 0x001B0000) Method (_PRW, 0, NotSerialized) { Return (GPRW (0x05, 0x04)) } } Device (P0PD) { Name (_ADR, 0x001C0000) } Device (P0P2) { Name (_ADR, 0x001C0001) Method (_PRW, 0, NotSerialized) { Return (GPRW (0x09, 0x04)) } Method (_PRT, 0, NotSerialized) { If (PICM) { Return (AR02) } Return (PR02) } } Device (P0P3) { Name (_ADR, 0x001C0002) Method (_PRT, 0, NotSerialized) { If (PICM) { Return (AR03) } Return (PR03) } } Device (P0P7) { Name (_ADR, 0x001C0003) Method (_PRT, 0, NotSerialized) { If (PICM) { Return (AR07) } Return (PR07) } } Device (P0P8) { Name (_ADR, 0x001C0004) Method (_PRT, 0, NotSerialized) { If (PICM) { Return (AR08) } Return (PR08) } } Device (P0P9) { Name (_ADR, 0x001C0005) Method (_PRT, 0, NotSerialized) { If (PICM) { Return (AR09) } Return (PR09) } } } Scope (\_GPE) { Method (_L09, 0, NotSerialized) { Notify (\_SB.PCI0.P0PC, 0x02) Notify (\_SB.PCI0.P0P2, 0x02) Notify (\_SB.PWRB, 0x02) } Method (_L0B, 0, NotSerialized) { Notify (\_SB.PCI0.P0P4, 0x02) Notify (\_SB.PCI0.P0P4.CBC0, 0x02) Notify (\_SB.PWRB, 0x02) } Method (_L03, 0, NotSerialized) { Notify (\_SB.PCI0.USB0, 0x02) Notify (\_SB.PWRB, 0x02) } Method (_L04, 0, NotSerialized) { Notify (\_SB.PCI0.USB1, 0x02) Notify (\_SB.PWRB, 0x02) } Method (_L0C, 0, NotSerialized) { Notify (\_SB.PCI0.USB2, 0x02) Notify (\_SB.PWRB, 0x02) } Method (_L0D, 0, NotSerialized) { Notify (\_SB.PCI0.EUSB, 0x02) Notify (\_SB.PWRB, 0x02) } Method (_L05, 0, NotSerialized) { Notify (\_SB.PCI0.AZAL, 0x02) Notify (\_SB.PWRB, 0x02) } } Device (PWRB) { Name (_HID, EisaId ("PNP0C0C")) Name (_UID, 0xAA) Name (_STA, 0x0B) } } OperationRegion (_SB.PCI0.SBRG.PIX0, PCI_Config, 0x60, 0x0C) Field (\_SB.PCI0.SBRG.PIX0, ByteAcc, NoLock, Preserve) { PIRA, 8, PIRB, 8, PIRC, 8, PIRD, 8, Offset (0x08), PIRE, 8, PIRF, 8, PIRG, 8, PIRH, 8 } Scope (_SB) { Name (BUFA, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {15} }) CreateWordField (BUFA, One, IRA0) Device (LNKA) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, One) Method (_STA, 0, NotSerialized) { And (PIRA, 0x80, Local0) If (Local0) { Return (0x09) } Else { Return (0x0B) } } Method (_PRS, 0, NotSerialized) { Return (PRSA) } Method (_DIS, 0, NotSerialized) { Or (PIRA, 0x80, PIRA) } Method (_CRS, 0, NotSerialized) { And (PIRA, 0x0F, Local0) ShiftLeft (One, Local0, IRA0) Return (BUFA) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, One, IRA) FindSetRightBit (IRA, Local0) Decrement (Local0) Store (Local0, PIRA) } } Device (LNKB) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x02) Method (_STA, 0, NotSerialized) { And (PIRB, 0x80, Local0) If (Local0) { Return (0x09) } Else { Return (0x0B) } } Method (_PRS, 0, NotSerialized) { Return (PRSB) } Method (_DIS, 0, NotSerialized) { Or (PIRB, 0x80, PIRB) } Method (_CRS, 0, NotSerialized) { And (PIRB, 0x0F, Local0) ShiftLeft (One, Local0, IRA0) Return (BUFA) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, One, IRA) FindSetRightBit (IRA, Local0) Decrement (Local0) Store (Local0, PIRB) } } Device (LNKC) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x03) Method (_STA, 0, NotSerialized) { And (PIRC, 0x80, Local0) If (Local0) { Return (0x09) } Else { Return (0x0B) } } Method (_PRS, 0, NotSerialized) { Return (PRSC) } Method (_DIS, 0, NotSerialized) { Or (PIRC, 0x80, PIRC) } Method (_CRS, 0, NotSerialized) { And (PIRC, 0x0F, Local0) ShiftLeft (One, Local0, IRA0) Return (BUFA) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, One, IRA) FindSetRightBit (IRA, Local0) Decrement (Local0) Store (Local0, PIRC) } } Device (LNKD) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x04) Method (_STA, 0, NotSerialized) { And (PIRD, 0x80, Local0) If (Local0) { Return (0x09) } Else { Return (0x0B) } } Method (_PRS, 0, NotSerialized) { Return (PRSD) } Method (_DIS, 0, NotSerialized) { Or (PIRD, 0x80, PIRD) } Method (_CRS, 0, NotSerialized) { And (PIRD, 0x0F, Local0) ShiftLeft (One, Local0, IRA0) Return (BUFA) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, One, IRA) FindSetRightBit (IRA, Local0) Decrement (Local0) Store (Local0, PIRD) } } Device (LNKE) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x05) Method (_STA, 0, NotSerialized) { And (PIRE, 0x80, Local0) If (Local0) { Return (0x09) } Else { Return (0x0B) } } Method (_PRS, 0, NotSerialized) { Return (PRSE) } Method (_DIS, 0, NotSerialized) { Or (PIRE, 0x80, PIRE) } Method (_CRS, 0, NotSerialized) { And (PIRE, 0x0F, Local0) ShiftLeft (One, Local0, IRA0) Return (BUFA) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, One, IRA) FindSetRightBit (IRA, Local0) Decrement (Local0) Store (Local0, PIRE) } } Device (LNKF) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x06) Method (_STA, 0, NotSerialized) { And (PIRF, 0x80, Local0) If (Local0) { Return (0x09) } Else { Return (0x0B) } } Method (_PRS, 0, NotSerialized) { Return (PRSF) } Method (_DIS, 0, NotSerialized) { Or (PIRF, 0x80, PIRF) } Method (_CRS, 0, NotSerialized) { And (PIRF, 0x0F, Local0) ShiftLeft (One, Local0, IRA0) Return (BUFA) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, One, IRA) FindSetRightBit (IRA, Local0) Decrement (Local0) Store (Local0, PIRF) } } Device (LNKG) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x07) Method (_STA, 0, NotSerialized) { And (PIRG, 0x80, Local0) If (Local0) { Return (0x09) } Else { Return (0x0B) } } Method (_PRS, 0, NotSerialized) { Return (PRSG) } Method (_DIS, 0, NotSerialized) { Or (PIRG, 0x80, PIRG) } Method (_CRS, 0, NotSerialized) { And (PIRG, 0x0F, Local0) ShiftLeft (One, Local0, IRA0) Return (BUFA) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, One, IRA) FindSetRightBit (IRA, Local0) Decrement (Local0) Store (Local0, PIRG) } } Device (LNKH) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x08) Method (_STA, 0, NotSerialized) { And (PIRH, 0x80, Local0) If (Local0) { Return (0x09) } Else { Return (0x0B) } } Method (_PRS, 0, NotSerialized) { Return (PRSH) } Method (_DIS, 0, NotSerialized) { Or (PIRH, 0x80, PIRH) } Method (_CRS, 0, NotSerialized) { And (PIRH, 0x0F, Local0) ShiftLeft (One, Local0, IRA0) Return (BUFA) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, One, IRA) FindSetRightBit (IRA, Local0) Decrement (Local0) Store (Local0, PIRH) } } } Scope (_SB) { Name (XCPD, Zero) Name (XNPT, One) Name (XCAP, 0x02) Name (XDCP, 0x04) Name (XDCT, 0x08) Name (XDST, 0x0A) Name (XLCP, 0x0C) Name (XLCT, 0x10) Name (XLST, 0x12) Name (XSCP, 0x14) Name (XSCT, 0x18) Name (XSST, 0x1A) Name (XRCT, 0x1C) Mutex (MUTE, 0x00) Method (RBPE, 1, NotSerialized) { Acquire (MUTE, 0x03E8) Add (Arg0, PCIB, Local0) OperationRegion (PCFG, SystemMemory, Local0, One) Field (PCFG, ByteAcc, NoLock, Preserve) { XCFG, 8 } Release (MUTE) Return (XCFG) } Method (RWPE, 1, NotSerialized) { Acquire (MUTE, 0x03E8) And (Arg0, 0xFFFFFFFE, Arg0) Add (Arg0, PCIB, Local0) OperationRegion (PCFG, SystemMemory, Local0, 0x02) Field (PCFG, WordAcc, NoLock, Preserve) { XCFG, 16 } Release (MUTE) Return (XCFG) } Method (RDPE, 1, NotSerialized) { Acquire (MUTE, 0x03E8) And (Arg0, 0xFFFFFFFC, Arg0) Add (Arg0, PCIB, Local0) OperationRegion (PCFG, SystemMemory, Local0, 0x04) Field (PCFG, DWordAcc, NoLock, Preserve) { XCFG, 32 } Release (MUTE) Return (XCFG) } Method (WBPE, 2, NotSerialized) { Acquire (MUTE, 0x0FFF) Add (Arg0, PCIB, Local0) OperationRegion (PCFG, SystemMemory, Local0, One) Field (PCFG, ByteAcc, NoLock, Preserve) { XCFG, 8 } Store (Arg1, XCFG) Release (MUTE) } Method (WWPE, 2, NotSerialized) { Acquire (MUTE, 0x03E8) And (Arg0, 0xFFFFFFFE, Arg0) Add (Arg0, PCIB, Local0) OperationRegion (PCFG, SystemMemory, Local0, 0x02) Field (PCFG, WordAcc, NoLock, Preserve) { XCFG, 16 } Store (Arg1, XCFG) Release (MUTE) } Method (WDPE, 2, NotSerialized) { Acquire (MUTE, 0x03E8) And (Arg0, 0xFFFFFFFC, Arg0) Add (Arg0, PCIB, Local0) OperationRegion (PCFG, SystemMemory, Local0, 0x04) Field (PCFG, DWordAcc, NoLock, Preserve) { XCFG, 32 } Store (Arg1, XCFG) Release (MUTE) } Method (RWDP, 3, NotSerialized) { Acquire (MUTE, 0x03E8) And (Arg0, 0xFFFFFFFC, Arg0) Add (Arg0, PCIB, Local0) OperationRegion (PCFG, SystemMemory, Local0, 0x04) Field (PCFG, DWordAcc, NoLock, Preserve) { XCFG, 32 } And (XCFG, Arg2, Local1) Or (Local1, Arg1, XCFG) Release (MUTE) } Method (RPME, 1, NotSerialized) { Add (Arg0, 0x84, Local0) Store (RDPE (Local0), Local1) If (LEqual (Local1, Ones)) { Return (Zero) } Else { If (LAnd (Local1, 0x00010000)) { WDPE (Local0, And (Local1, 0x00010000)) Return (One) } Return (Zero) } } } Scope (_SB) { Scope (PCI0) { Name (CRS, ResourceTemplate () { WordBusNumber (ResourceProducer, MinFixed, MaxFixed, PosDecode, 0x0000, 0x0000, 0x00FF, 0x0000, 0x0100) IO (Decode16, 0x0CF8, 0x0CF8, 0x01, 0x08) WordIO (ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange, 0x0000, 0x0000, 0x0CF7, 0x0000, 0x0CF8) WordIO (ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange, 0x0000, 0x0D00, 0xFFFF, 0x0000, 0xF300) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, 0x000A0000, 0x000BFFFF, 0x00000000, 0x00020000) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, 0x000C0000, 0x000DFFFF, 0x00000000, 0x00020000) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000) }) CreateDWordField (CRS, 0x5C, MIN5) CreateDWordField (CRS, 0x60, MAX5) CreateDWordField (CRS, 0x68, LEN5) CreateDWordField (CRS, 0x76, MIN6) CreateDWordField (CRS, 0x7A, MAX6) CreateDWordField (CRS, 0x82, LEN6) CreateDWordField (CRS, 0x90, MIN7) CreateDWordField (CRS, 0x94, MAX7) CreateDWordField (CRS, 0x9C, LEN7) Method (_CRS, 0, NotSerialized) { Store (MG1L, Local0) If (Local0) { Store (MG1B, MIN5) Store (MG1L, LEN5) Add (MIN5, Decrement (Local0), MAX5) } Store (MG2B, MIN6) Store (MG2L, LEN6) Store (MG2L, Local0) Add (MIN6, Decrement (Local0), MAX6) Store (MG3B, MIN7) Store (MG3L, LEN7) Store (MG3L, Local0) Add (MIN7, Decrement (Local0), MAX7) Return (CRS) } } } Name (WOTB, Zero) Name (WSSB, Zero) Name (WAXB, Zero) Method (_PTS, 1, NotSerialized) { Store (Arg0, DBG8) PTS (Arg0) Store (Zero, Index (WAKP, Zero)) Store (Zero, Index (WAKP, One)) If (LAnd (LEqual (Arg0, 0x04), LEqual (OSFL (), 0x02))) { Sleep (0x0BB8) } Store (ASSB, WSSB) Store (AOTB, WOTB) Store (AAXB, WAXB) Store (Arg0, ASSB) Store (OSFL (), AOTB) Store (Zero, AAXB) } Name (SLID, One) Method (_WAK, 1, NotSerialized) { ShiftLeft (Arg0, 0x04, DBG8) Store (One, SLID) WAK (Arg0) If (ASSB) { Store (WSSB, ASSB) Store (WOTB, AOTB) Store (WAXB, AAXB) } If (DerefOf (Index (WAKP, Zero))) { Store (Zero, Index (WAKP, One)) } Else { Store (Arg0, Index (WAKP, One)) } Store (\_SB.PCI0.SBRG.EC.POWS, Local0) If (LEqual (Local0, One)) { Store (One, \_SB.PCI0.SBRG.EC.ADP1.ACP) } Else { Store (Zero, \_SB.PCI0.SBRG.EC.ADP1.ACP) } Store (\_SB.PCI0.SBRG.EC.MBTS, Local0) If (LEqual (Local0, One)) { Store (One, \_SB.PCI0.SBRG.EC.ADP1.BFLG) } Else { Store (Zero, \_SB.PCI0.SBRG.EC.ADP1.BFLG) } Notify (\_SB.PCI0.SBRG.EC.ADP1, Zero) Notify (\_SB.PCI0.SBRG.EC.BAT1, Zero) Store (One, \_SB.PCI0.WAWA.PDC1) Store (One, \_SB.PCI0.WAWA.HPCS) If (MCTH (_OS, "Microsoft Windows")) { If (LEqual (Arg0, 0x04)) { Notify (\_SB.PWRB, 0x02) } } Return (WAKP) } Name (_S0, Package (0x04) { Zero, Zero, Zero, Zero }) If (SS1) { Name (_S1, Package (0x04) { One, Zero, Zero, Zero }) } If (SS3) { Name (_S3, Package (0x04) { 0x05, Zero, Zero, Zero }) } If (SS4) { Name (_S4, Package (0x04) { 0x06, Zero, Zero, Zero }) } Name (_S5, Package (0x04) { 0x07, Zero, Zero, Zero }) Method (PTS, 1, NotSerialized) { If (Arg0) { \_SB.PCI0.NPTS (Arg0) \_SB.PCI0.SBRG.SPTS (Arg0) } } Method (WAK, 1, NotSerialized) { \_SB.PCI0.NWAK (Arg0) \_SB.PCI0.SBRG.SWAK (Arg0) } } >=20 > gahr> In this case, the CPU frequency should be increased according to > gahr> powerd's algorithm and should be decreased according to passive > gahr> cooling's algorithm. >=20 > gahr> Wouldn't it be better to have one subsystem deal with both usage = and > gahr> temperature in order to decide which is the best next frequency t= o be set? >=20 > No, we have a priority to control a cpufreq in our kernel, to deal > with conflict between kernel and userland. Controlling cpufreq within > our kernel is considered as high proirity. So, during our kernel is > controlling a cpufreq, we cannot change cpufreq from userland. And, > our kernel releasing the control, a cpufreq is back to the value > before our kernel changed it. >=20 > gahr> My patch is really just a first draft that I wrote in order to ha= ve > gahr> feedbacks on the general idea to implement a temperature controll= ing > gahr> system inside powerd, and doesn't implement hysteresis as you not= ed, and > gahr> your feedback is that it's not a good idea, which I respect. >=20 > It is rather backward, IMHO. I did implement a passive cooling > feature as an enhancement of powerd(8) like you did, during initial > phases. Then, I implemented it in our kernel as a result. >=20 > Sincerely, >=20 > -- > Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan > ume@mahoroba.org ume@{,jp.}FreeBSD.org > http://www.imasy.org/~ume/ --=20 Pietro Cerutti PGP Public Key: http://gahr.ch/pgp --------------enig4CA6C2FBD4CDF6A051529EB3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGrs6RwMJqmJVx944RCnpaAKDkeS6b0P11uqE9wqgEqRgYXFMh6ACeIGiH fW2BmCjMGANdMUoqvBKArmk= =wl32 -----END PGP SIGNATURE----- --------------enig4CA6C2FBD4CDF6A051529EB3-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 31 06:23:27 2007 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F33216A419 for ; Tue, 31 Jul 2007 06:23:27 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id C3C3E13C458 for ; Tue, 31 Jul 2007 06:23:26 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 015F82089; Tue, 31 Jul 2007 08:23:21 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 6FDEC2085; Tue, 31 Jul 2007 08:23:20 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 499DF84465; Tue, 31 Jul 2007 08:23:20 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: =?utf-8?Q?Jo=C3=A3o?= Carlos Mendes =?utf-8?Q?Lu=C3=ADs?= References: <46AEC3BF.4080309@jonny.eng.br> Date: Tue, 31 Jul 2007 08:23:20 +0200 In-Reply-To: <46AEC3BF.4080309@jonny.eng.br> (=?utf-8?Q?=22Jo=C3=A3o?= Carlos Mendes =?utf-8?Q?Lu=C3=ADs=22's?= message of "Tue\, 31 Jul 2007 02\:08\:15 -0300") Message-ID: <86r6mpnlbb.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org Subject: Re: Problems with rpc.statd and PAE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2007 06:23:27 -0000 Jo=C3=A3o Carlos Mendes Lu=C3=ADs writes: > Also, I tought PAE was only needed when we had MORE than 4G. But > without PAE the system shows only 3.5G. Without PAE, the address space is only 32 bits (4 GB), 512 MB of which are reserved for PCI devices. With PAE, the address space is 36 bits (64 GB) which is more than room enough for your 4 GB of RAM *plus* the PCI configuration and MMIO space. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 31 06:43:22 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1DBE16A41F; Tue, 31 Jul 2007 06:43:22 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from ameno.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id 53FDF13C469; Tue, 31 Jul 2007 06:43:22 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from localhost (IDENT:FZKfqFv3g++qtGkPOqHiavm6VLIN5pwq+vG6LHHbw4ciD+d4aYjVzlnZy/n/vMP/@localhost [IPv6:::1]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.8/8.13.8) with ESMTP/inet6 id l6V6hFWC005744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Jul 2007 15:43:15 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Tue, 31 Jul 2007 15:43:15 +0900 Message-ID: From: Hajimu UMEMOTO To: Pietro Cerutti In-Reply-To: <46AECE8C.8000500@gahr.ch> References: <46AA0491.5000203@gahr.ch> <46ADAF5B.6050602@gahr.ch> <20070730180355.GA7355@rot26.obsecurity.org> <46AE58B5.3080506@gahr.ch> <46AECE8C.8000500@gahr.ch> User-Agent: xcite1.57> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.1 (i386-pc-freebsd) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 6.2-RELEASE-p4 X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (ameno.mahoroba.org [IPv6:::1]); Tue, 31 Jul 2007 15:43:15 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00, DKIM_POLICY_SIGNSOME,DK_POLICY_SIGNSOME,HELO_LOCALHOST autolearn=no version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on ameno.mahoroba.org Cc: acpi@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: [patch] enhance powerd(8) to handle max temperature X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2007 06:43:22 -0000 Hi, >>>>> On Tue, 31 Jul 2007 07:54:20 +0200 >>>>> Pietro Cerutti said: gahr> Thanks for your help! I cannot see _TC1, _TC2 nor _TSP in your `acpidump -dt' output. Further, there is no _PSV definition in anywhere, in the first place. It seems to me that your ACPI BIOS doesn't support passive cooling at all. gahr> hw.acpi.thermal.user_override: 1 gahr> hw.acpi.thermal.tz0._PSV: 80.0C I suspect that you set hw.acpi.thermal.tz0._PSV manually. Of cource, it is insufficient to make passive cooling work with your ACPI BIOS, and you need the definition of _TC1, _TC2 and _TSP as well. If you define apropreate definition of them, passive cooling will work. But, we don't provide overriding the values of them. Perhaps, modifying your ASL (`acpidump -dt' output) to add the definitions of _TC1, _TC2, _TSP and _PSV, and loading it from loader will make passive cooling work. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 31 06:47:28 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AAFAF16A41F; Tue, 31 Jul 2007 06:47:28 +0000 (UTC) (envelope-from gahr@gahr.ch) Received: from cpanel03.rubas-s03.net (cpanel03.rubas-s03.net [195.182.222.73]) by mx1.freebsd.org (Postfix) with ESMTP id 3C45613C457; Tue, 31 Jul 2007 06:47:28 +0000 (UTC) (envelope-from gahr@gahr.ch) Received: from 80-218-187-205.dclient.hispeed.ch ([80.218.187.205] helo=gahrtop.localhost) by cpanel03.rubas-s03.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1IFlVv-0000X6-Bq; Tue, 31 Jul 2007 08:47:27 +0200 Message-ID: <46AEDB0C.6070706@gahr.ch> Date: Tue, 31 Jul 2007 08:47:40 +0200 From: Pietro Cerutti User-Agent: Thunderbird 2.0.0.5 (X11/20070723) MIME-Version: 1.0 To: Hajimu UMEMOTO References: <46AA0491.5000203@gahr.ch> <46ADAF5B.6050602@gahr.ch> <20070730180355.GA7355@rot26.obsecurity.org> <46AE58B5.3080506@gahr.ch> <46AECE8C.8000500@gahr.ch> In-Reply-To: X-Enigmail-Version: 0.95.2 OpenPGP: id=9571F78E; url=http://www.gahr.ch/pgp Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigF419CFEE4ABAC2D2F27EBF18" X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel03.rubas-s03.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gahr.ch X-Source: X-Source-Args: X-Source-Dir: Cc: acpi@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: [patch] enhance powerd(8) to handle max temperature X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2007 06:47:28 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF419CFEE4ABAC2D2F27EBF18 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hajimu UMEMOTO wrote: > Hi, >=20 >>>>>> On Tue, 31 Jul 2007 07:54:20 +0200 >>>>>> Pietro Cerutti said: >=20 > gahr> Thanks for your help! >=20 > I cannot see _TC1, _TC2 nor _TSP in your `acpidump -dt' output. > Further, there is no _PSV definition in anywhere, in the first place. > It seems to me that your ACPI BIOS doesn't support passive cooling at > all. Yep that's what I suspected. >=20 > gahr> hw.acpi.thermal.user_override: 1 > gahr> hw.acpi.thermal.tz0._PSV: 80.0C >=20 > I suspect that you set hw.acpi.thermal.tz0._PSV manually. Yes I did.. > Of cource, it is insufficient to make passive cooling work with your AC= PI BIOS, > and you need the definition of _TC1, _TC2 and _TSP as well. > If you define apropreate definition of them, passive cooling will > work. But, we don't provide overriding the values of them. Perhaps, > modifying your ASL (`acpidump -dt' output) to add the definitions of > _TC1, _TC2, _TSP and _PSV, and loading it from loader will make > passive cooling work. Do you have an example? I'm really far from being familiar with the ASL code... > Sincerely, Thank you >=20 > -- > Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan > ume@mahoroba.org ume@{,jp.}FreeBSD.org > http://www.imasy.org/~ume/ --=20 Pietro Cerutti PGP Public Key: http://gahr.ch/pgp --------------enigF419CFEE4ABAC2D2F27EBF18 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGrtsQwMJqmJVx944RCvDYAJ98sXtowbk7/HRVnBlab8hTkhSNYgCgtn0L 2+dEDcQgi0eFe/FFENws/Go= =cz6e -----END PGP SIGNATURE----- --------------enigF419CFEE4ABAC2D2F27EBF18-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 31 09:02:42 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49F9016A41A for ; Tue, 31 Jul 2007 09:02:42 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id EFD3213C46A for ; Tue, 31 Jul 2007 09:02:41 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 11ABDEB8093; Tue, 31 Jul 2007 17:02:41 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id D1xgHyJZT2b1; Tue, 31 Jul 2007 17:02:35 +0800 (CST) Received: from LI-Xins-MacBook.local (sina152-194.staff.sina.com.cn [61.135.152.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 9CB0CEB2788; Tue, 31 Jul 2007 17:02:35 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:subject:x-enigmail-version:openpgp:content-type; b=TKSkd4p5WkI7DUWCvcFT743V+GiXBufrEiNC08iEsYF52g5bjwryr1hu1n/wUNZ2O pAjWXWh5BTuaMSoNR03+w== Message-ID: <46AEFA96.1070204@delphij.net> Date: Tue, 31 Jul 2007 17:02:14 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.5 (Macintosh/20070716) MIME-Version: 1.0 To: freebsd-hackers X-Enigmail-Version: 0.95.2 OpenPGP: url=http://www.delphij.net/delphij.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig198690BCD6297E983B13761D" Subject: Is it possible to use IPv4 and IPv6 in a same jail? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2007 09:02:42 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig198690BCD6297E983B13761D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Is it possible to use IPv4 and IPv6 in a same jail? Or do I have to write a listening daemon that acts as a "proxy" that runs in the host? Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------enig198690BCD6297E983B13761D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGrvqWOfuToMruuMARCgtaAKCK8VTsVE6NBr87SqXIJCT9rvlhRwCeLwKH nqQGClWZDi+B6kqa8L2Z1og= =IqtL -----END PGP SIGNATURE----- --------------enig198690BCD6297E983B13761D-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 31 09:32:19 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 940D716A417 for ; Tue, 31 Jul 2007 09:32:19 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 4C25213C461 for ; Tue, 31 Jul 2007 09:32:19 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id F16E341C693; Tue, 31 Jul 2007 11:15:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id Ynaebapb6WPS; Tue, 31 Jul 2007 11:15:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id AC4E241C691; Tue, 31 Jul 2007 11:15:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id B54F9444885; Tue, 31 Jul 2007 09:10:23 +0000 (UTC) Date: Tue, 31 Jul 2007 09:10:23 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: d@delphij.net In-Reply-To: <46AEFA96.1070204@delphij.net> Message-ID: <20070731090955.J31116@maildrop.int.zabbadoz.net> References: <46AEFA96.1070204@delphij.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers Subject: Re: Is it possible to use IPv4 and IPv6 in a same jail? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2007 09:32:19 -0000 On Tue, 31 Jul 2007, LI Xin wrote: > Hi, > > Is it possible to use IPv4 and IPv6 in a same jail? Or do I have to > write a listening daemon that acts as a "proxy" that runs in the host? jails do not (yet) support IPv6. I hope to be working on that again by the end of the week. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 31 09:35:10 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9AE116A419 for ; Tue, 31 Jul 2007 09:35:10 +0000 (UTC) (envelope-from frank@pinky.sax.de) Received: from pinky.frank-behrens.de (unknown [IPv6:2a01:170:1023:0:211:2fff:fec9:c52d]) by mx1.freebsd.org (Postfix) with ESMTP id 0359213C459 for ; Tue, 31 Jul 2007 09:35:09 +0000 (UTC) (envelope-from frank@pinky.sax.de) Received: from [192.168.20.32] (sun.behrens [192.168.20.32]) by pinky.frank-behrens.de (8.14.1/8.14.1) with ESMTP-MSA id l6V9YcPe049742 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO); Tue, 31 Jul 2007 11:34:38 +0200 (CEST) (envelope-from frank@pinky.sax.de) Message-Id: <200707310934.l6V9YcPe049742@pinky.frank-behrens.de> From: "Frank Behrens" To: d@delphij.net Date: Tue, 31 Jul 2007 11:34:38 +0200 MIME-Version: 1.0 Priority: normal In-reply-to: <46AEFA96.1070204@delphij.net> X-mailer: Pegasus Mail for Windows (4.31, DE v4.31 R1) Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 8BIT Content-description: Mail message body X-Hashcash: 1:24:070731:freebsd-hackers@freebsd.org::EUxVkLdkYz3jDHI+:000000Kjxi X-Hashcash: 1:24:070731:d@delphij.net::bz/JORmYLGjHKn7j:1Ofny Cc: freebsd-hackers Subject: Re: Is it possible to use IPv4 and IPv6 in a same jail? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2007 09:35:10 -0000 LI Xin wrote on 31 Jul 2007 17:02: > Is it possible to use IPv4 and IPv6 in a same jail? Or do I have to Currently there is no IPv6 support in jails. > write a listening daemon that acts as a "proxy" that runs in the host? IMHO the only possible solution. But there is hope. :-) http://docs.freebsd.org/cgi/mid.cgi?4644773E.60909 Gruß, Frank -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available. From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 31 09:40:23 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C708916A418 for ; Tue, 31 Jul 2007 09:40:23 +0000 (UTC) (envelope-from corecode@fs.ei.tum.de) Received: from stella.fs.ei.tum.de (stella.fs.ei.tum.de [IPv6:2001:4ca0:22ff:10::7]) by mx1.freebsd.org (Postfix) with ESMTP id 0F52813C46C for ; Tue, 31 Jul 2007 09:40:23 +0000 (UTC) (envelope-from corecode@fs.ei.tum.de) Received: from localhost (localhost [127.0.0.1]) by localhost.fs.ei.tum.de (Postfix) with ESMTP id 20DA528090; Tue, 31 Jul 2007 11:40:21 +0200 (CEST) X-Virus-Scanned: by amavisd-new at fs.ei.tum.de Received: from stella.fs.ei.tum.de ([127.0.0.1]) by localhost (stella.fs.ei.tum.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Qk-wlI--kIGE; Tue, 31 Jul 2007 11:40:20 +0200 (CEST) Received: from sweatshorts.home.corecode.ath.cx (85-218-11-202.dclient.lsne.ch [85.218.11.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by stella.fs.ei.tum.de (Postfix) with ESMTP id B955C2808F; Tue, 31 Jul 2007 11:40:20 +0200 (CEST) Message-ID: <46AF0384.4010507@fs.ei.tum.de> Date: Tue, 31 Jul 2007 11:40:20 +0200 From: Simon 'corecode' Schubert User-Agent: Thunderbird 2.0.0.4 (X11/20070627) MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <46AEFA96.1070204@delphij.net> <20070731090955.J31116@maildrop.int.zabbadoz.net> In-Reply-To: <20070731090955.J31116@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-hackers , d@delphij.net Subject: Re: Is it possible to use IPv4 and IPv6 in a same jail? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2007 09:40:23 -0000 Bjoern A. Zeeb wrote: >> Is it possible to use IPv4 and IPv6 in a same jail? Or do I have to >> write a listening daemon that acts as a "proxy" that runs in the host? > > jails do not (yet) support IPv6. I hope to be working on that again by > the end of the week. Did you look at the DragonFly support for ipv6 and multiple IPs in jails? It's kind of intrusive, but not very much more than the common jail code is anyways. cheers simon -- Serve - BSD +++ RENT this banner advert +++ ASCII Ribbon /"\ Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \ From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 31 09:45:20 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1599716A41B for ; Tue, 31 Jul 2007 09:45:20 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id B5F9213C48E for ; Tue, 31 Jul 2007 09:45:19 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id EDD16EB8B36; Tue, 31 Jul 2007 17:45:18 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id n75vx9+sRwhq; Tue, 31 Jul 2007 17:45:14 +0800 (CST) Received: from LI-Xins-MacBook.local (sina152-194.staff.sina.com.cn [61.135.152.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 28E1BEB8AED; Tue, 31 Jul 2007 17:45:13 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type; b=t3U/My8EwvPH2kTuqfhUc53Umfrv9HihnfwgQ+rcUrozn931l+Wdie09oAtw23QmY eMrDsEzp3IrMPwLi/1WXg== Message-ID: <46AF0493.6060602@delphij.net> Date: Tue, 31 Jul 2007 17:44:51 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.5 (Macintosh/20070716) MIME-Version: 1.0 To: Simon 'corecode' Schubert References: <46AEFA96.1070204@delphij.net> <20070731090955.J31116@maildrop.int.zabbadoz.net> <46AF0384.4010507@fs.ei.tum.de> In-Reply-To: <46AF0384.4010507@fs.ei.tum.de> X-Enigmail-Version: 0.95.2 OpenPGP: url=http://www.delphij.net/delphij.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigF99AEB690DC7D51F2FEF2B63" Cc: "Bjoern A. Zeeb" , d@delphij.net, freebsd-hackers Subject: Re: Is it possible to use IPv4 and IPv6 in a same jail? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2007 09:45:20 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF99AEB690DC7D51F2FEF2B63 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Simon 'corecode' Schubert wrote: > Bjoern A. Zeeb wrote: >>> Is it possible to use IPv4 and IPv6 in a same jail? Or do I have to >>> write a listening daemon that acts as a "proxy" that runs in the host= ? >> >> jails do not (yet) support IPv6. I hope to be working on that again by= >> the end of the week. >=20 > Did you look at the DragonFly support for ipv6 and multiple IPs in > jails? It's kind of intrusive, but not very much more than the common > jail code is anyways. Thanks for the hint. Will look at it right after I have done my work this week... Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------enigF99AEB690DC7D51F2FEF2B63 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGrwSTOfuToMruuMARClX9AJ44mPGYbZFEWHUgdRr6pBsRVGR3uACdFpVS nazh1HZtSi/Xw+iHLTrv39Y= =py8Q -----END PGP SIGNATURE----- --------------enigF99AEB690DC7D51F2FEF2B63-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 31 10:43:59 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 231FE16A417; Tue, 31 Jul 2007 10:43:59 +0000 (UTC) (envelope-from gahr@gahr.ch) Received: from cpanel03.rubas-s03.net (cpanel03.rubas-s03.net [195.182.222.73]) by mx1.freebsd.org (Postfix) with ESMTP id 9E11F13C459; Tue, 31 Jul 2007 10:43:58 +0000 (UTC) (envelope-from gahr@gahr.ch) Received: from gahrtop.bfh.ch ([147.87.108.141] helo=gahrtop.localhost) by cpanel03.rubas-s03.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1IFpCm-0007Hm-2g; Tue, 31 Jul 2007 12:43:56 +0200 Message-ID: <46AF1276.8070808@gahr.ch> Date: Tue, 31 Jul 2007 12:44:06 +0200 From: Pietro Cerutti User-Agent: Thunderbird 2.0.0.5 (X11/20070723) MIME-Version: 1.0 To: Hajimu UMEMOTO , freebsd-hackers@freebsd.org, freebsd-acpi@freebsd.org References: <46AA0491.5000203@gahr.ch> <46ADAF5B.6050602@gahr.ch> <20070730180355.GA7355@rot26.obsecurity.org> <46AE58B5.3080506@gahr.ch> <46AECE8C.8000500@gahr.ch> <46AEDB0C.6070706@gahr.ch> In-Reply-To: <46AEDB0C.6070706@gahr.ch> X-Enigmail-Version: 0.95.2 OpenPGP: id=9571F78E; url=http://www.gahr.ch/pgp Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigDD61C1913061BBF31FCF3179" X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel03.rubas-s03.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gahr.ch X-Source: X-Source-Args: X-Source-Dir: Cc: Subject: [SOLVED] Re: [patch] enhance powerd(8) to handle max temperature X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2007 10:43:59 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDD61C1913061BBF31FCF3179 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pietro Cerutti wrote: > Hajimu UMEMOTO wrote: >> Hi, >> >>>>>>> On Tue, 31 Jul 2007 07:54:20 +0200 >>>>>>> Pietro Cerutti said: >> gahr> Thanks for your help! >> >> I cannot see _TC1, _TC2 nor _TSP in your `acpidump -dt' output. >> Further, there is no _PSV definition in anywhere, in the first place. >> It seems to me that your ACPI BIOS doesn't support passive cooling at >> all. >=20 > Yep that's what I suspected. >=20 >> gahr> hw.acpi.thermal.user_override: 1 >> gahr> hw.acpi.thermal.tz0._PSV: 80.0C >> >> I suspect that you set hw.acpi.thermal.tz0._PSV manually. >=20 > Yes I did.. >=20 >> Of cource, it is insufficient to make passive cooling work with your A= CPI BIOS, >> and you need the definition of _TC1, _TC2 and _TSP as well. >> If you define apropreate definition of them, passive cooling will >> work. But, we don't provide overriding the values of them. Perhaps, >> modifying your ASL (`acpidump -dt' output) to add the definitions of >> _TC1, _TC2, _TSP and _PSV, and loading it from loader will make >> passive cooling work. >=20 > Do you have an example? I'm really far from being familiar with the ASL= > code... Nevermind, I finally got my passive cooling working. Here's the diff against my acpidump -dt: --- MSI1034.asl.orig 2007-07-31 12:37:55.000000000 +0200 +++ MSI1034.asl 2007-07-31 12:37:57.000000000 +0200 @@ -2612,6 +2612,10 @@ { Return (KLV (0x64)) } + Name (_TC1, 0x00) + Name (_TC2, 0x0C) + Name (_TSP, 0x28) + } } @@ -4425,8 +4429,11 @@ Zero, Zero }) + + /* If (SS1) { + */ Name (_S1, Package (0x04) { One, @@ -4434,10 +4441,14 @@ Zero, Zero }) + /* } + */ + /* If (SS3) { + */ Name (_S3, Package (0x04) { 0x05, @@ -4445,10 +4456,14 @@ Zero, Zero }) + /* } + */ + /* If (SS4) { + */ Name (_S4, Package (0x04) { 0x06, @@ -4456,7 +4471,9 @@ Zero, Zero }) + /* } + */ Name (_S5, Package (0x04) { I don't know if the values of _TC1, _TC2 and TSP are meaningful, but it seems to work for me, having a _PSV value of 65C. Any suggestions on those values are welcome. acpi_tz0: temperature 65.8C: decreasing clock speed from 1743 MHz to 1452 MHz acpi_tz0: temperature 65.8C: decreasing clock speed from 1452 MHz to 1162 MHz acpi_tz0: temperature 63.8C: increasing clock speed from 1162 MHz to 1452 MHz acpi_tz0: temperature 64.8C: increasing clock speed from 1452 MHz to 1660 MHz acpi_tz0: temperature 64.8C: increasing clock speed from 1660 MHz to 1743 MHz acpi_tz0: temperature 65.8C: decreasing clock speed from 1743 MHz to 1452 MHz acpi_tz0: temperature 64.8C: increasing clock speed from 1452 MHz to 1660 MHz acpi_tz0: temperature 64.8C: increasing clock speed from 1660 MHz to 1743 MHz acpi_tz0: temperature 66.8C: decreasing clock speed from 1743 MHz to 1162 MHz acpi_tz0: temperature 64.8C: increasing clock speed from 1162 MHz to 1328 MHz =2E.............. This seems to keep my laptop's temperature around 65C. Thanks again, >=20 >> Sincerely, >=20 > Thank you >=20 >> -- >> Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan >> ume@mahoroba.org ume@{,jp.}FreeBSD.org >> http://www.imasy.org/~ume/ >=20 --=20 Pietro Cerutti PGP Public Key: http://gahr.ch/pgp --------------enigDD61C1913061BBF31FCF3179 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGrxJ7wMJqmJVx944RChyeAKC2xMayD3+AjeNep4cAlOLOjHoMsQCgpVKe Ol49oKNSUsxW7TUxVyOUyFA= =4dwn -----END PGP SIGNATURE----- --------------enigDD61C1913061BBF31FCF3179-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 31 14:43:20 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77FAF16A419; Tue, 31 Jul 2007 14:43:20 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from ameno.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2733613C45B; Tue, 31 Jul 2007 14:43:20 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:3BvvWCs2DIIHpDvEJv4X+asnJ7j9r03ys2zc0TNfUk7g7oPoedCZiqZBua7HPjZf@kasuga.mahoroba.org [IPv6:2001:2f0:104:8010:20b:97ff:fe2e:b521]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.8/8.13.8) with ESMTP/inet6 id l6VEhA28054785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Jul 2007 23:43:13 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Tue, 31 Jul 2007 23:43:10 +0900 Message-ID: From: Hajimu UMEMOTO To: Pietro Cerutti In-Reply-To: <46AF1276.8070808@gahr.ch> References: <46AA0491.5000203@gahr.ch> <46ADAF5B.6050602@gahr.ch> <20070730180355.GA7355@rot26.obsecurity.org> <46AE58B5.3080506@gahr.ch> <46AECE8C.8000500@gahr.ch> <46AEDB0C.6070706@gahr.ch> <46AF1276.8070808@gahr.ch> User-Agent: xcite1.57> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.1 (i386-pc-freebsd) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 6.2-STABLE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (ameno.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Tue, 31 Jul 2007 23:43:13 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, DKIM_POLICY_SIGNSOME,DK_POLICY_SIGNSOME autolearn=ham version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on ameno.mahoroba.org Cc: freebsd-hackers@freebsd.org, freebsd-acpi@freebsd.org Subject: Re: [SOLVED] Re: [patch] enhance powerd(8) to handle max temperature X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2007 14:43:20 -0000 Hi, >>>>> On Tue, 31 Jul 2007 12:44:06 +0200 >>>>> Pietro Cerutti said: gahr> Nevermind, I finally got my passive cooling working. Congratulation! gahr> I don't know if the values of _TC1, _TC2 and TSP are meaningful, but it gahr> seems to work for me, having a _PSV value of 65C. gahr> Any suggestions on those values are welcome. The cpufreq is controlled according to the following formula: P [%] = _TC1 * ( Tn - Tn-1 ) + _TC2 * ( Tn - _PSV ) Pn = Pn-1 + HW[ - P ] where 0% <= Pn <= 100% And, this evaluation is examined every _TSP / 10 second. I'm not sure which values are appropriate for your box, but my laptop has the following values: Name (_TC1, Zero) Name (_TC2, 0x0C) Name (_TSP, 0x28) The values are same as you chose. Please refer the following document for detail: http://www.acpi.info/DOWNLOADS/ACPIspec-2-0c.pdf Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 31 14:55:03 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C830016A417; Tue, 31 Jul 2007 14:55:03 +0000 (UTC) (envelope-from gahr@gahr.ch) Received: from cpanel03.rubas-s03.net (cpanel03.rubas-s03.net [195.182.222.73]) by mx1.freebsd.org (Postfix) with ESMTP id 4B8EB13C481; Tue, 31 Jul 2007 14:55:03 +0000 (UTC) (envelope-from gahr@gahr.ch) Received: from 80-218-187-205.dclient.hispeed.ch ([80.218.187.205] helo=gahrtop.localhost) by cpanel03.rubas-s03.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1IFt7l-0002qV-EY; Tue, 31 Jul 2007 16:55:01 +0200 Message-ID: <46AF4D52.4020500@gahr.ch> Date: Tue, 31 Jul 2007 16:55:14 +0200 From: Pietro Cerutti User-Agent: Thunderbird 2.0.0.5 (X11/20070723) MIME-Version: 1.0 To: Hajimu UMEMOTO References: <46AA0491.5000203@gahr.ch> <46ADAF5B.6050602@gahr.ch> <20070730180355.GA7355@rot26.obsecurity.org> <46AE58B5.3080506@gahr.ch> <46AECE8C.8000500@gahr.ch> <46AEDB0C.6070706@gahr.ch> <46AF1276.8070808@gahr.ch> In-Reply-To: X-Enigmail-Version: 0.95.2 OpenPGP: id=9571F78E; url=http://www.gahr.ch/pgp Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig66366DA221C765B65C236613" X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel03.rubas-s03.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gahr.ch X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-hackers@freebsd.org, freebsd-acpi@freebsd.org Subject: Re: [SOLVED] Re: [patch] enhance powerd(8) to handle max temperature X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2007 14:55:03 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig66366DA221C765B65C236613 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hajimu UMEMOTO wrote: > Hi, >=20 >>>>>> On Tue, 31 Jul 2007 12:44:06 +0200 >>>>>> Pietro Cerutti said: >=20 > gahr> Nevermind, I finally got my passive cooling working. >=20 > Congratulation! Thanx ;-) >=20 > gahr> I don't know if the values of _TC1, _TC2 and TSP are meaningful, = but it > gahr> seems to work for me, having a _PSV value of 65C. > gahr> Any suggestions on those values are welcome. >=20 > The cpufreq is controlled according to the following formula: >=20 > P [%] =3D _TC1 * ( Tn - Tn-1 ) + _TC2 * ( Tn - _PSV ) > Pn =3D Pn-1 + HW[ - P ] where 0% <=3D Pn <=3D 100% Been there, done that ;-) I saw this formula on the ACPI specs, but I feel like I don't have the knowledge to tailor _TC1 and _TC2 to my >=20 > And, this evaluation is examined every _TSP / 10 second. > I'm not sure which values are appropriate for your box, but my laptop > has the following values: >=20 > Name (_TC1, Zero) > Name (_TC2, 0x0C) > Name (_TSP, 0x28) >=20 > The values are same as you chose. ;-) I took the first two values I found in an ACPI asl on the net. > Please refer the following document for detail: >=20 > http://www.acpi.info/DOWNLOADS/ACPIspec-2-0c.pdf Maybe during vacation :-) >=20 > Sincerely, Thanks for your help! >=20 > -- > Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan > ume@mahoroba.org ume@{,jp.}FreeBSD.org > http://www.imasy.org/~ume/ --=20 Pietro Cerutti PGP Public Key: http://gahr.ch/pgp --------------enig66366DA221C765B65C236613 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGr01WwMJqmJVx944RCuJLAJ9l7Ne8jdc2HpeJVDC2sOk9GlAISwCgp2WF W59zWuVPomltDSfHcH7GvPU= =S5ca -----END PGP SIGNATURE----- --------------enig66366DA221C765B65C236613-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 31 18:41:55 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7174E16A41A for ; Tue, 31 Jul 2007 18:41:55 +0000 (UTC) (envelope-from ytriffy@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.freebsd.org (Postfix) with ESMTP id BA1FE13C46C for ; Tue, 31 Jul 2007 18:41:54 +0000 (UTC) (envelope-from ytriffy@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so256513nfb for ; Tue, 31 Jul 2007 11:41:53 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:user-agent:mime-version:to:subject:content-type:content-transfer-encoding:from; b=kB0fd4SqQA5DAH4HlvPwBlpYHIdIwI+sExiJiDJxRqIY3F2j2S7PMICips08s0jwcXOy707st9WWCQ0tJRj/ixwMP89FdoppSvLWU4nLPESIj/EeR6OIBDBvP4AyDiL9wIWl2uOdx86G3Pe2wU8f9OJ05jmZORx4mSQU8/EbxsU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:user-agent:mime-version:to:subject:content-type:content-transfer-encoding:from; b=ObaO27hvwcw0pMDOamt4sO6v3U9y5MAxmH+BxMeU1e0VYBJPOW3mX9CUgzw63H+9IvcQLJ5G9/N8wZdZ8BjJq2YBsyC5rWlglLT4LdLf4GqlgOz29mWUKJ8J9+1TYOvOajnzk6PAXbcV3IA7kLU6fOkuWr4NPu4AYBXs1zJQ7j8= Received: by 10.86.23.17 with SMTP id 17mr4891007fgw.1185907313445; Tue, 31 Jul 2007 11:41:53 -0700 (PDT) Received: from ?192.168.0.179? ( [80.86.254.135]) by mx.google.com with ESMTPS id p38sm3394951fke.2007.07.31.11.41.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 31 Jul 2007 11:41:52 -0700 (PDT) Message-ID: <46AF826E.8000209@gmail.com> Date: Tue, 31 Jul 2007 22:41:50 +0400 User-Agent: Thunderbird 2.0.0.5 (X11/20070720) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit From: ytriffy X-Mailman-Approved-At: Tue, 31 Jul 2007 18:46:53 +0000 Subject: [panic]Fatal trap 12: page fault while in kernel mode X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2007 18:41:55 -0000 Hello. Trap 12 occured when I rebooted PC. Sending you backtrace. My system: amd64 3200+ Venice, MB ECS nForce4 A939,Samsung 250GB and WD 250 GB, 2 memory banks 512MB each, videocard: Geforce 6600gt 128MB, NIC on realtek chip, sound card cirrus logic cs4281. It's very unstable, crashes happen every day, so I'm hoping you would say why(any hints what hardware may cause it). How to repeat it? I don't know. It happened once during reboot process. [root@freelanc /var]# uname -a FreeBSD freelanc.dubki.ru 6.2-STABLE-200706 FreeBSD 6.2-STABLE-200706 #1: Mon Jul 23 13:34:27 MSD 2007 root@freelanc.dubki.ru:/usr/obj/usr/src/sys/DEBUGGER KERN i386 [root@freelanc /usr/obj/usr/src/sys/DEBUGGERKERN]# kgdb kernel.debug /var/crash/vmcore.3 kgdb: kvm_nlist(_stopped_cpus): kgdb: kvm_nlist(_stoppcbs): [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: <118>Jul 25 14:06:32 freelanc syslogd: exiting on signal 15 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...6 5 3 1 0 0 done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done All buffers synced. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x4 fault code = supervisor read, page not present instruction pointer = 0x20:0xc058a4e0 stack pointer = 0x28:0xe9455c48 frame pointer = 0x28:0xe9455c58 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 = 44922 (reboot) panic: from debugger Uptime: 2h45m36s Dumping 1022 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 1022MB (261600 pages) 1006 990 974 958 942 926 910 894 878 862 846 830 814 798 782 766 750 734 718 702 686 670 654 638 622 606 590 574 558 542 526 510 494 478 462 446 430 414 398 382 366 350 334 318 302 286 270 254 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14 #0 doadump () at pcpu.h:165 165 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc053d916 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc053dbdc in panic (fmt=0xc06f5278 "from debugger") at /usr/src/sys/kern/kern_shutdown.c:565 #3 0xc045361d in db_panic (addr=-1067932448, have_addr=0, count=-1, modif=0xe9455a74 "") at /usr/src/sys/ddb/db_command.c:438 #4 0xc04535b4 in db_command (last_cmdp=0xc0766784, cmd_table=0x0, aux_cmd_tablep=0xc0728e90, aux_cmd_tablep_end=0xc0728e94) at /usr/src/sys/ddb/db_command.c:350 #5 0xc045367c in db_command_loop () at /usr/src/sys/ddb/db_command.c:458 #6 0xc0455291 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:222 #7 0xc0556a2b in kdb_trap (type=12, code=0, tf=0xe9455c08) at /usr/src/sys/kern/subr_kdb.c:473 #8 0xc06cba6c in trap_fatal (frame=0xe9455c08, eva=4) at /usr/src/sys/i386/i386/trap.c:828 #9 0xc06cb7d7 in trap_pfault (frame=0xe9455c08, usermode=0, eva=4) at /usr/src/sys/i386/i386/trap.c:745 #10 0xc06cb3f1 in trap (frame= {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -381330360, tf_esi = -993547624, tf_ebp = -381330344, tf_isp = -381330380, tf_ebx = 0, tf_edx = -992513384, tf_ecx = 4, tf_eax = -950651024, tf_trapno = 12, tf_err = 0, tf_eip = -1067932448, tf_cs = 32, tf_eflags = 590338, tf_esp = 0, tf_ss = -992305712}) at /usr/src/sys/i386/i386/trap.c:435 #11 0xc06b8b1a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #12 0xc058a4e0 in cache_purgevfs (mp=0xc4d77298) at /usr/src/sys/kern/vfs_cache.c:622 #13 0xc0591f29 in dounmount (mp=0xc4d77298, flags=524288, td=0xc62ce300) at /usr/src/sys/kern/vfs_mount.c:1214 #14 0xc0597d0a in vfs_unmountall () at /usr/src/sys/kern/vfs_subr.c:2837 #15 0xc053d807 in boot (howto=0) at /usr/src/sys/kern/kern_shutdown.c:391 #16 0xc053d2a2 in reboot (td=0xc62ce300, uap=0xc7563770) at /usr/src/sys/kern/kern_shutdown.c:169 #17 0xc06cbdbb in syscall (frame= {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 2, tf_esi = 18, tf_ebp = -1077941304, tf_isp = -381330076, tf_ebx = 0, tf_edx = -1, tf_ecx = 672491264, tf_eax = 55, tf_trapno = 12, tf_err = 2, tf_eip = 671802263, tf_cs = 51, tf_eflags = 662, tf_esp = -1077941380, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:983 #18 0xc06b8b6f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200 #19 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) up 19 #19 0x00000033 in ?? () (kgdb) down 1 #18 0xc06b8b6f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200 200 call syscall Current language: auto; currently asm (kgdb) down 1 #17 0xc06cbdbb in syscall (frame= {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 2, tf_esi = 18, tf_ebp = -1077941304, tf_isp = -381330076, tf_ebx = 0, tf_edx = -1, tf_ecx = 672491264, tf_eax = 55, tf_trapno = 12, tf_err = 2, tf_eip = 671802263, tf_cs = 51, tf_eflags = 662, tf_esp = -1077941380, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:983 983 error = (*callp->sy_call)(td, args); Current language: auto; currently c (kgdb) p *callp $1 = {sy_narg = 65537, sy_call = 0xc053d258 , sy_auevent = 20} (kgdb) p *callp->sy_call $2 = {int (struct thread *, void *)} 0xc053d258 (kgdb) p td $3 = (struct thread *) 0xc62ce300 (kgdb) p args $4 = {0, 9, -994250272, -1077941388, 0, 0, 3, 0} (kgdb) down 1 #16 0xc053d2a2 in reboot (td=0xc62ce300, uap=0xc7563770) at /usr/src/sys/kern/kern_shutdown.c:169 169 boot(uap->opt); (kgdb) p uap $5 = (struct reboot_args *) 0xc7563770 (kgdb) p uap->opt $6 = 2 (kgdb) down 1 #15 0xc053d807 in boot (howto=0) at /usr/src/sys/kern/kern_shutdown.c:391 391 vfs_unmountall(); (kgdb) down 1 #14 0xc0597d0a in vfs_unmountall () at /usr/src/sys/kern/vfs_subr.c:2837 2837 error = dounmount(mp, MNT_FORCE, td); (kgdb) p mp $7 = (struct mount *) 0xc4d77298 (kgdb) p td $8 = (struct thread *) 0xc62ce300 (kgdb) down 1 #13 0xc0591f29 in dounmount (mp=0xc4d77298, flags=524288, td=0xc62ce300) at /usr/src/sys/kern/vfs_mount.c:1214 1214 cache_purgevfs(mp); /* remove cache entries for this file sys */ (kgdb) down 1 #12 0xc058a4e0 in cache_purgevfs (mp=0xc4d77298) at /usr/src/sys/kern/vfs_cache.c:622 622 for (ncp = LIST_FIRST(ncpp); ncp != 0; ncp = nnp) { (kgdb) p ncp $9 = (struct namecache *) 0x4 (kgdb) p ncpp $10 = (struct nchashhead *) 0xc4c7aa98 (kgdb) down 1 #11 0xc06b8b1a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 139 call trap Current language: auto; currently asm (kgdb) down 1 #10 0xc06cb3f1 in trap (frame= {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -381330360, tf_esi = -993547624, tf_ebp = -381330344, tf_isp = -381330380, tf_ebx = 0, tf_edx = -992513384, tf_ecx = 4, tf_eax = -950651024, tf_trapno = 12, tf_err = 0, tf_eip = -1067932448, tf_cs = 32, tf_eflags = 590338, tf_esp = 0, tf_ss = -992305712}) at /usr/src/sys/i386/i386/trap.c:435 435 (void) trap_pfault(&frame, FALSE, eva); Current language: auto; currently c (kgdb) p frame $11 = {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -381330360, tf_esi = -993547624, tf_ebp = -381330344, tf_isp = -381330380, tf_ebx = 0, tf_edx = -992513384, tf_ecx = 4, tf_eax = -950651024, tf_trapno = 12, tf_err = 0, tf_eip = -1067932448, tf_cs = 32, tf_eflags = 590338, tf_esp = 0, tf_ss = -992305712} (kgdb) p eva $12 = 4 (kgdb) down 1 #9 0xc06cb7d7 in trap_pfault (frame=0xe9455c08, usermode=0, eva=4) at /usr/src/sys/i386/i386/trap.c:745 745 trap_fatal(frame, eva); (kgdb) down 1 #8 0xc06cba6c in trap_fatal (frame=0xe9455c08, eva=4) at /usr/src/sys/i386/i386/trap.c:828 828 if (kdb_trap(type, 0, frame)) { (kgdb) p type $13 = 12 (kgdb) down 1 #7 0xc0556a2b in kdb_trap (type=12, code=0, tf=0xe9455c08) at /usr/src/sys/kern/subr_kdb.c:473 473 handled = kdb_dbbe->dbbe_trap(type, code); (kgdb) p kdb_dbbe $14 = (struct kdb_dbbe *) 0xc072f0e0 (kgdb) p kdb_dbbe->dbbe_trap $15 = (dbbe_trap_f *) 0xc04551ac (kgdb) p type $16 = 12 (kgdb) p code $17 = 0 (kgdb) down 1 #6 0xc0455291 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:222 222 db_command_loop(); (kgdb) down 1 #5 0xc045367c in db_command_loop () at /usr/src/sys/ddb/db_command.c:458 458 db_command(&db_last_command, db_command_table, (kgdb) p &db_last_command $18 = (struct command **) 0xc0766784 (kgdb) p db_command_table $19 = {{name = 0xc0726d8d "print", fcn = 0xc0453e44 , flag = 0, more = 0x0}, {name = 0xc0707446 "p", fcn = 0xc0453e44 , flag = 0, more = 0x0}, {name = 0xc06f521d "examine", fcn = 0xc0453b74 , flag = 256, more = 0x0}, { name = 0xc06f3248 "x", fcn = 0xc0453b74 , flag = 256, more = 0x0}, {name = 0xc06f5225 "search", fcn = 0xc0453f44 , flag = 257, more = 0x0}, { name = 0xc06fc7c7 "set", fcn = 0xc0456d98 , flag = 1, more = 0x0}, {name = 0xc071c1dc "write", fcn = 0xc045714c , flag = 258, more = 0x0}, {name = 0xc070470c "w", fcn = 0xc045714c , flag = 258, more = 0x0}, { name = 0xc0711df9 "delete", fcn = 0xc045312c , flag = 0, more = 0x0}, {name = 0xc06f3296 "d", fcn = 0xc045312c , flag = 0, more = 0x0}, {name = 0xc06f522c "break", fcn = 0xc0453144 , flag = 0, more = 0x0}, { name = 0xc06f5232 "dwatch", fcn = 0xc0457014 , flag = 0, more = 0x0}, {name = 0xc06f5233 "watch", fcn = 0xc045702c , flag = 2, more = 0x0}, { name = 0xc06f5239 "dhwatch", fcn = 0xc04570e4 , flag = 0, more = 0x0}, {name = 0xc06f523a "hwatch", fcn = 0xc0457118 , flag = 0, more = 0x0}, { name = 0xc0721ca0 "step", fcn = 0xc0456438 , flag = 0, more = 0x0}, {name = 0xc06f55e4 "s", fcn = 0xc0456438 , flag = 0, more = 0x0}, { name = 0xc06f5241 "continue", fcn = 0xc045653c , flag = 0, more = 0x0}, {name = 0xc0713305 "c", fcn = 0xc045653c , flag = 0, more = 0x0}, { name = 0xc06f524a "until", fcn = 0xc04564a0 , flag = 0, more = 0x0}, {name = 0xc06f5250 "next", fcn = 0xc04564e8 , flag = 0, more = 0x0}, { name = 0xc070d7da "match", fcn = 0xc04564e8 , flag = 0, more = 0x0}, {name = 0xc070882b "trace", fcn = 0xc0453a4c , flag = 1, more = 0x0}, { name = 0xc06f5255 "alltrace", fcn = 0xc0453b20 , flag = 0, more = 0x0}, {name = 0xc07249cf "where", fcn = 0xc0453a4c , flag = 1, more = 0x0}, { name = 0xc06f525e "bt", fcn = 0xc0453a4c , flag = 1, more = 0x0}, {name = 0xc071aa99 "call", fcn = 0xc04536b0 , flag = 1, more = 0x0}, {name = 0xc06f5261 "show", fcn = 0, flag = 0, more = 0xc072edc0}, {name = 0xc07126a2 "ps", fcn = 0xc0455784 , flag = 0, more = 0x0}, {name = 0xc06f5266 "gdb", fcn = 0xc0453a18 , flag = 0, more = 0x0}, { name = 0xc06fc600 "reset", fcn = 0xc0453920 , flag = 0, more = 0x0}, {name = 0xc06f526a "kill", fcn = 0xc04537d8 , flag = 1, more = 0x0}, {name = 0xc06f526f "watchdog", fcn = 0xc045392c , flag = 0, more = 0x0}, { name = 0xc070887d "thread", fcn = 0xc0456a10 , flag = 1, more = 0x0}, {name = 0x0, fcn = 0, flag = 0, more = 0x0}} (kgdb) down 1 #4 0xc04535b4 in db_command (last_cmdp=0xc0766784, cmd_table=0x0, aux_cmd_tablep=0xc0728e90, aux_cmd_tablep_end=0xc0728e94) at /usr/src/sys/ddb/db_command.c:350 350 (*cmd->fcn)(addr, have_addr, count, modif); (kgdb) p addr $20 = -1067932448 (kgdb) p have_addr $21 = 0 (kgdb) p count $22 = -1 (kgdb) p modif $23 = "\000ZEР�DС‹jСЋ\214ZEР�\220ZEР�\211\a\000\000в•ђZEР�\"LJСЋ\000\000\000\000\000╤╙д\2005yСЋ\r\000\000\000\2005yСЋ\r\000\000\000\001\000\000\000Р»ZEР�\213СЂjСЋР»ZEР�в•“СЂjСЋ\000@РЃРґ@\036wСЋx\000\000\000\200pvСЋ\f\000\000\000Р›ZEР� Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E88A116A417 for ; Wed, 1 Aug 2007 07:47:23 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 963A713C442 for ; Wed, 1 Aug 2007 07:47:23 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id BDDBC2089; Wed, 1 Aug 2007 09:47:19 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 3DF4E2085; Wed, 1 Aug 2007 09:47:19 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 2B3A18447A; Wed, 1 Aug 2007 09:47:19 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Hajimu UMEMOTO References: <46AA0491.5000203@gahr.ch> <46ADAF5B.6050602@gahr.ch> <20070730180355.GA7355@rot26.obsecurity.org> <46AE58B5.3080506@gahr.ch> <46AECE8C.8000500@gahr.ch> Date: Wed, 01 Aug 2007 09:47:19 +0200 In-Reply-To: (Hajimu UMEMOTO's message of "Tue\, 31 Jul 2007 15\:43\:15 +0900") Message-ID: <86hcnjn1bs.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: acpi@freebsd.org, freebsd-hackers@freebsd.org, Pietro Cerutti Subject: Re: [patch] enhance powerd(8) to handle max temperature X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2007 07:47:24 -0000 Hajimu UMEMOTO writes: > I cannot see _TC1, _TC2 nor _TSP in your `acpidump -dt' output. > Further, there is no _PSV definition in anywhere, in the first place. > It seems to me that your ACPI BIOS doesn't support passive cooling at > all. Going off on a tangent, I too have several motherboards (965P-based) which do not define any ACPI thermal zones, which leads me to wonder: what is the preferred way to access thermal data these days? IPMI? Do we have IPMI support in base or ports? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 1 13:18:09 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 619EA16A41F for ; Wed, 1 Aug 2007 13:18:09 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id 231A613C483 for ; Wed, 1 Aug 2007 13:18:09 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from vanquish.pitbpa0.priv.collaborativefusion.com (vanquish.pitbpa0.priv.collaborativefusion.com [192.168.2.61]) (SSL: TLSv1/SSLv3,256bits,AES256-SHA) by wingspan with esmtp; Wed, 01 Aug 2007 09:08:06 -0400 id 00056407.46B085B6.00001E89 Date: Wed, 1 Aug 2007 09:08:05 -0400 From: Bill Moran To: freebsd-hackers@freebsd.org Message-Id: <20070801090805.b3a753fb.wmoran@collaborativefusion.com> In-Reply-To: <86hcnjn1bs.fsf@ds4.des.no> References: <46AA0491.5000203@gahr.ch> <46ADAF5B.6050602@gahr.ch> <20070730180355.GA7355@rot26.obsecurity.org> <46AE58B5.3080506@gahr.ch> <46AECE8C.8000500@gahr.ch> <86hcnjn1bs.fsf@ds4.des.no> Organization: Collaborative Fusion X-Mailer: Sylpheed 2.3.1 (GTK+ 2.10.11; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [patch] enhance powerd(8) to handle max temperature X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2007 13:18:09 -0000 In response to "Dag-Erling Sm=F8rgrav" : > Hajimu UMEMOTO writes: > > I cannot see _TC1, _TC2 nor _TSP in your `acpidump -dt' output. > > Further, there is no _PSV definition in anywhere, in the first place. > > It seems to me that your ACPI BIOS doesn't support passive cooling at > > all. >=20 > Going off on a tangent, I too have several motherboards (965P-based) > which do not define any ACPI thermal zones, which leads me to wonder: > what is the preferred way to access thermal data these days? IPMI? Do > we have IPMI support in base or ports? Not sure about the base, but we've been using ipmitool from ports for a while with success, and we're investigating FreeIPMI. --=20 Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ wmoran@collaborativefusion.com Phone: 412-422-3463x4023 **************************************************************** IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. **************************************************************** From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 1 17:33:05 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 392F716A41F for ; Wed, 1 Aug 2007 17:33:05 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.freebsd.org (Postfix) with ESMTP id 103FC13C45E for ; Wed, 1 Aug 2007 17:33:05 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by ironport2.ambrisko.com with ESMTP; 01 Aug 2007 09:59:18 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.14.1/8.12.11) with ESMTP id l71H6u1E086898; Wed, 1 Aug 2007 10:06:56 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.1/8.13.1/Submit) id l71H6uWw086897; Wed, 1 Aug 2007 10:06:56 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200708011706.l71H6uWw086897@ambrisko.com> In-Reply-To: <20070801090805.b3a753fb.wmoran@collaborativefusion.com> To: Bill Moran Date: Wed, 1 Aug 2007 10:06:56 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: freebsd-hackers@freebsd.org Subject: Re: [patch] enhance powerd(8) to handle max temperature X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2007 17:33:05 -0000 Bill Moran writes: | In response to "Dag-Erling Sm?rgrav" : | > Hajimu UMEMOTO writes: | > > I cannot see _TC1, _TC2 nor _TSP in your `acpidump -dt' output. | > > Further, there is no _PSV definition in anywhere, in the first place. | > > It seems to me that your ACPI BIOS doesn't support passive cooling at | > > all. | > | > Going off on a tangent, I too have several motherboards (965P-based) | > which do not define any ACPI thermal zones, which leads me to wonder: | > what is the preferred way to access thermal data these days? IPMI? Do | > we have IPMI support in base or ports? | | Not sure about the base, but we've been using ipmitool from ports for | a while with success, and we're investigating FreeIPMI. Both ipmitool and freeipmi in ports can use the ipmi(4) which lives in the base system on 6.X & above. I recommend to use ipmi(4) versus direct HW access from user-land so things are a bit more orderely. So it is a mix of base and ports. I like ipmitool & freeipmi in ports as they have a bunch of people working on IPMI things and adding features. Personally, I went with ipmitool since some Dell people are contributors to it. Not all systems have IPMI but it tends to be nice when they do. There are several things that have IPMI as a subset. Things that might have it could have ASF(AMD) or AMT (Intel) capable machines. Some times it an add-in daughter card on server type motherboard. With AMT it seems Intel is pushing it more into the Desktop space :-) Now with regards to CPU temperature. Newer Intel CPU's do not report their temperature. I have read that they report how many degrees away until there is a problem but I think that might have been a joke. Systems that have IPMI version 2 are nice since that means they are supposed to support Serial Over Lan (SOL) via the standard :-) Doug A. From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 2 00:55:08 2007 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BCC016A41B; Thu, 2 Aug 2007 00:55:08 +0000 (UTC) (envelope-from yrao@force10networks.com) Received: from mx.force10networks.com (nat-eqx.force10networks.com [69.25.56.27]) by mx1.freebsd.org (Postfix) with ESMTP id 2132013C467; Thu, 2 Aug 2007 00:55:08 +0000 (UTC) (envelope-from yrao@force10networks.com) Received: from mx.force10networks.com ([10.11.0.215]) by mx.force10networks.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 1 Aug 2007 17:43:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 1 Aug 2007 17:43:15 -0700 Message-ID: <9E2742C54E161041A53F36F9A8DC31BE1F98B3@EXCH-CLUSTER-04.force10networks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: core dump hangs Thread-Index: AcfUnhzy4So9NP4ZSy+IT6Af0ybodw== From: "Yong Rao" To: X-OriginalArrivalTime: 02 Aug 2007 00:43:35.0325 (UTC) FILETIME=[2887ACD0:01C7D49E] X-Mailman-Approved-At: Thu, 02 Aug 2007 01:16:58 +0000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: remko@FreeBSD.org, remko@elvandar.org Subject: core dump hangs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2007 00:55:08 -0000 Hi,=20 =20 Recently, while we developed our own FreeBSD driver, we found the core dump does not work (with SMP options and dual CPUs). We have already filed a PR for this bug. See http://www.freebsd.org/cgi/query-pr.cgi?pr=3D114370. =20 I am wondering if anybody on this list is interested in investigating this issue. This bug is sort of blocking our development work because the core could not be dumped out when our driver crash happens. =20 Thanks a lot for your attention. =20 Yong Rao Force10 Networks, Inc. 408 571 3617(w) =20 =20 From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 2 01:39:00 2007 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6E3E16A418; Thu, 2 Aug 2007 01:39:00 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by mx1.freebsd.org (Postfix) with ESMTP id B1C4A13C465; Thu, 2 Aug 2007 01:39:00 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9] (may be forged)) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.06) with ESMTP id l721cvn6004510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 1 Aug 2007 18:38:57 -0700 X-Auth-Received: from [192.168.10.45] (c-24-10-12-194.hsd1.ca.comcast.net [24.10.12.194]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l721cu3M032358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 1 Aug 2007 18:38:56 -0700 Message-ID: <46B135AE.5030002@u.washington.edu> Date: Wed, 01 Aug 2007 18:38:54 -0700 From: Garrett Cooper User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Yong Rao References: <9E2742C54E161041A53F36F9A8DC31BE1F98B3@EXCH-CLUSTER-04.force10networks.com> In-Reply-To: <9E2742C54E161041A53F36F9A8DC31BE1F98B3@EXCH-CLUSTER-04.force10networks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.1.182222 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__C230066_P5 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Cc: remko@FreeBSD.org, hackers@FreeBSD.org, remko@elvandar.org Subject: Re: core dump hangs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2007 01:39:00 -0000 Yong Rao wrote: > Hi, > > > > Recently, while we developed our own FreeBSD driver, we found the core > dump does not work (with SMP options and dual CPUs). We have already > filed a PR for this bug. See > http://www.freebsd.org/cgi/query-pr.cgi?pr=114370. > > > > I am wondering if anybody on this list is interested in investigating > this issue. This bug is sort of blocking our development work because > the core could not be dumped out when our driver crash happens. > > > > Thanks a lot for your attention. > > > > Yong Rao > > Force10 Networks, Inc. > > 408 571 3617(w) Which scheduler are you using? ULE or 4BSD? -Garrett From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 2 02:30:17 2007 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A12816A421; Thu, 2 Aug 2007 02:30:17 +0000 (UTC) (envelope-from yrao@force10networks.com) Received: from mx.force10networks.com (nat-eqx.force10networks.com [69.25.56.27]) by mx1.freebsd.org (Postfix) with ESMTP id EB53D13C46B; Thu, 2 Aug 2007 02:30:16 +0000 (UTC) (envelope-from yrao@force10networks.com) Received: from mx.force10networks.com ([10.11.0.215]) by mx.force10networks.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 1 Aug 2007 19:30:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Aug 2007 19:30:24 -0700 Message-ID: <9E2742C54E161041A53F36F9A8DC31BE1F98C0@EXCH-CLUSTER-04.force10networks.com> In-Reply-To: <46B135AE.5030002@u.washington.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: core dump hangs Thread-Index: AcfUpfdWURooiEm+Txi5vhzumYX/FQABv4qg References: <9E2742C54E161041A53F36F9A8DC31BE1F98B3@EXCH-CLUSTER-04.force10networks.com> <46B135AE.5030002@u.washington.edu> From: "Yong Rao" To: "Garrett Cooper" X-OriginalArrivalTime: 02 Aug 2007 02:30:43.0466 (UTC) FILETIME=[200026A0:01C7D4AD] X-Mailman-Approved-At: Thu, 02 Aug 2007 02:48:31 +0000 Cc: remko@FreeBSD.org, hackers@FreeBSD.org, remko@elvandar.org Subject: RE: core dump hangs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2007 02:30:17 -0000 We use 4BSD (options SCHED_4BSD). Thanks, -Yong -----Original Message----- From: Garrett Cooper [mailto:youshi10@u.washington.edu]=20 Sent: Wednesday, August 01, 2007 6:39 PM To: Yong Rao Cc: hackers@FreeBSD.org; remko@FreeBSD.org; remko@elvandar.org Subject: Re: core dump hangs Yong Rao wrote: > Hi,=20 > > =20 > > Recently, while we developed our own FreeBSD driver, we found the core > dump does not work (with SMP options and dual CPUs). We have already > filed a PR for this bug. See > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D114370. > > =20 > > I am wondering if anybody on this list is interested in investigating > this issue. This bug is sort of blocking our development work because > the core could not be dumped out when our driver crash happens. > > =20 > > Thanks a lot for your attention. > > =20 > > Yong Rao > > Force10 Networks, Inc. > > 408 571 3617(w) Which scheduler are you using? ULE or 4BSD? -Garrett From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 2 02:53:11 2007 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C072616A417 for ; Thu, 2 Aug 2007 02:53:11 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id 50A2B13C458 for ; Thu, 2 Aug 2007 02:53:11 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id DC87AEB3CA9; Thu, 2 Aug 2007 10:53:06 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id zik7Jgv9eHhq; Thu, 2 Aug 2007 10:53:00 +0800 (CST) Received: from LI-Xins-MacBook.local (sina152-194.staff.sina.com.cn [61.135.152.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id C9AD8EB0F89; Thu, 2 Aug 2007 10:52:58 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type; b=P2nbivSA2VGiBJ3avnSvgvxn9SB2gYyIcDTz2Ujw8FbXkXjXD9Oeq0m9xU9/Ao9hK h896Ue1S8PfLWRa9jvOoA== Message-ID: <46B146F1.8060606@delphij.net> Date: Thu, 02 Aug 2007 10:52:33 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Yong Rao References: <9E2742C54E161041A53F36F9A8DC31BE1F98B3@EXCH-CLUSTER-04.force10networks.com> <46B135AE.5030002@u.washington.edu> <9E2742C54E161041A53F36F9A8DC31BE1F98C0@EXCH-CLUSTER-04.force10networks.com> In-Reply-To: <9E2742C54E161041A53F36F9A8DC31BE1F98C0@EXCH-CLUSTER-04.force10networks.com> X-Enigmail-Version: 0.95.2 OpenPGP: url=http://www.delphij.net/delphij.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigEC157E5BAA7A3F0C37A6887D" Cc: Garrett Cooper , hackers@FreeBSD.org, remko@FreeBSD.org, remko@elvandar.org Subject: Re: core dump hangs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2007 02:53:11 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEC157E5BAA7A3F0C37A6887D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yong Rao wrote: > We use 4BSD (options SCHED_4BSD). Could you please try if setting debug.minidump=3D0 would help the situati= on? Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------enigEC157E5BAA7A3F0C37A6887D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGsUbxOfuToMruuMARCsSLAKCF4IJ8U/vVD76SeAdMJPPVuVb/cACfXsZa s+hFRNC/02pLFP0Aqr4Ew+0= =uiiO -----END PGP SIGNATURE----- --------------enigEC157E5BAA7A3F0C37A6887D-- From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 2 03:20:41 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C108816A41A; Thu, 2 Aug 2007 03:20:40 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 68E4013C48D; Thu, 2 Aug 2007 03:20:40 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l723HBVw048128; Wed, 1 Aug 2007 21:17:12 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 01 Aug 2007 21:17:18 -0600 (MDT) Message-Id: <20070801.211718.1683324313.imp@bsdimp.com> To: nate@root.org From: "M. Warner Losh" In-Reply-To: <46AE8F78.1060203@root.org> References: <46AE58B5.3080506@gahr.ch> <46AE8F78.1060203@root.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Wed, 01 Aug 2007 21:17:13 -0600 (MDT) Cc: acpi@freebsd.org, freebsd-hackers@freebsd.org, ume@freebsd.org, gahr@gahr.ch Subject: Re: [patch] enhance powerd(8) to handle max temperature X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2007 03:20:41 -0000 In message: <46AE8F78.1060203@root.org> Nate Lawson writes: : Hajimu UMEMOTO wrote: : >>>>>> On Mon, 30 Jul 2007 23:31:33 +0200 : >>>>>> Pietro Cerutti said: : > gahr> My patch is really just a first draft that I wrote in order to have : > gahr> feedbacks on the general idea to implement a temperature controlling : > gahr> system inside powerd, and doesn't implement hysteresis as you noted, and : > gahr> your feedback is that it's not a good idea, which I respect. : > : > It is rather backward, IMHO. I did implement a passive cooling : > feature as an enhancement of powerd(8) like you did, during initial : > phases. Then, I implemented it in our kernel as a result. : : I'll take a look at your patch. Umemoto-san is right in that you really : want the kernel to control cooling. What happens if powerd dies/hangs : and your system burns up? Passive cooling is often a last resort to : keep the system from overheating. I keep getting the system shutting down on my HP by FreeBSD because the temperature exceeds the _CRT value. Maybe there's something wrong with my values, since it happens a lot: hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: 0.0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 90.0C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 94.0C hw.acpi.thermal.tz0._ACx: 40.0C -1 -1 -1 -1 -1 -1 -1 -1 -1 Note: temperature is always 0.0C. What can I do to help my situation, if I really want the kernel doing the cooling? Warner From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 2 03:26:56 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93BCE16A418; Thu, 2 Aug 2007 03:26:56 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout7.cac.washington.edu (mxout7.cac.washington.edu [140.142.32.178]) by mx1.freebsd.org (Postfix) with ESMTP id 6CA3413C468; Thu, 2 Aug 2007 03:26:56 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.06) with ESMTP id l723QrCp007390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 1 Aug 2007 20:26:53 -0700 X-Auth-Received: from [192.168.10.45] (c-24-10-12-194.hsd1.ca.comcast.net [24.10.12.194]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l723Qrle028909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 1 Aug 2007 20:26:53 -0700 Message-ID: <46B14EFB.6010207@u.washington.edu> Date: Wed, 01 Aug 2007 20:26:51 -0700 From: Garrett Cooper User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: "M. Warner Losh" References: <46AE58B5.3080506@gahr.ch> <46AE8F78.1060203@root.org> <20070801.211718.1683324313.imp@bsdimp.com> In-Reply-To: <20070801.211718.1683324313.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.1.200229 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Cc: acpi@freebsd.org, freebsd-hackers@freebsd.org, gahr@gahr.ch, ume@freebsd.org, nate@root.org Subject: Re: [patch] enhance powerd(8) to handle max temperature X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2007 03:26:56 -0000 M. Warner Losh wrote: > In message: <46AE8F78.1060203@root.org> > Nate Lawson writes: > : Hajimu UMEMOTO wrote: > : >>>>>> On Mon, 30 Jul 2007 23:31:33 +0200 > : >>>>>> Pietro Cerutti said: > : > gahr> My patch is really just a first draft that I wrote in order to have > : > gahr> feedbacks on the general idea to implement a temperature controlling > : > gahr> system inside powerd, and doesn't implement hysteresis as you noted, and > : > gahr> your feedback is that it's not a good idea, which I respect. > : > > : > It is rather backward, IMHO. I did implement a passive cooling > : > feature as an enhancement of powerd(8) like you did, during initial > : > phases. Then, I implemented it in our kernel as a result. > : > : I'll take a look at your patch. Umemoto-san is right in that you really > : want the kernel to control cooling. What happens if powerd dies/hangs > : and your system burns up? Passive cooling is often a last resort to > : keep the system from overheating. > > I keep getting the system shutting down on my HP by FreeBSD because > the temperature exceeds the _CRT value. Maybe there's something wrong > with my values, since it happens a lot: > > hw.acpi.thermal.min_runtime: 0 > hw.acpi.thermal.polling_rate: 10 > hw.acpi.thermal.user_override: 0 > hw.acpi.thermal.tz0.temperature: 0.0C > hw.acpi.thermal.tz0.active: -1 > hw.acpi.thermal.tz0.passive_cooling: 1 > hw.acpi.thermal.tz0.thermal_flags: 0 > hw.acpi.thermal.tz0._PSV: 90.0C > hw.acpi.thermal.tz0._HOT: -1 > hw.acpi.thermal.tz0._CRT: 94.0C > hw.acpi.thermal.tz0._ACx: 40.0C -1 -1 -1 -1 -1 -1 -1 -1 -1 > > Note: temperature is always 0.0C. > > What can I do to help my situation, if I really want the kernel doing > the cooling? > > Warner > Wow, something's really wrong with those calculated temperatures. At that value most of the plastic and weaker circuitry should have fused together =\. -Garrett From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 2 03:36:30 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6908516A418 for ; Thu, 2 Aug 2007 03:36:30 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outL.internet-mail-service.net (outL.internet-mail-service.net [216.240.47.235]) by mx1.freebsd.org (Postfix) with ESMTP id 45BC013C467 for ; Thu, 2 Aug 2007 03:36:30 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Wed, 01 Aug 2007 20:36:29 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 8E55D125B11; Wed, 1 Aug 2007 20:36:28 -0700 (PDT) Message-ID: <46B15166.1070305@elischer.org> Date: Wed, 01 Aug 2007 20:37:10 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.5 (Macintosh/20070716) MIME-Version: 1.0 To: Garrett Cooper References: <46AE58B5.3080506@gahr.ch> <46AE8F78.1060203@root.org> <20070801.211718.1683324313.imp@bsdimp.com> <46B14EFB.6010207@u.washington.edu> In-Reply-To: <46B14EFB.6010207@u.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ume@freebsd.org, acpi@freebsd.org, freebsd-hackers@freebsd.org, gahr@gahr.ch, nate@root.org Subject: Re: [patch] enhance powerd(8) to handle max temperature X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2007 03:36:30 -0000 Garrett Cooper wrote: > M. Warner Losh wrote: >> In message: <46AE8F78.1060203@root.org> >> Nate Lawson writes: >> : Hajimu UMEMOTO wrote: >> : >>>>>> On Mon, 30 Jul 2007 23:31:33 +0200 >> : >>>>>> Pietro Cerutti said: >> : > gahr> My patch is really just a first draft that I wrote in order >> to have >> : > gahr> feedbacks on the general idea to implement a temperature >> controlling >> : > gahr> system inside powerd, and doesn't implement hysteresis as >> you noted, and >> : > gahr> your feedback is that it's not a good idea, which I respect. >> : > : > It is rather backward, IMHO. I did implement a passive cooling >> : > feature as an enhancement of powerd(8) like you did, during initial >> : > phases. Then, I implemented it in our kernel as a result. >> : : I'll take a look at your patch. Umemoto-san is right in that you >> really >> : want the kernel to control cooling. What happens if powerd dies/hangs >> : and your system burns up? Passive cooling is often a last resort to >> : keep the system from overheating. >> >> I keep getting the system shutting down on my HP by FreeBSD because >> the temperature exceeds the _CRT value. Maybe there's something wrong >> with my values, since it happens a lot: >> >> hw.acpi.thermal.min_runtime: 0 >> hw.acpi.thermal.polling_rate: 10 >> hw.acpi.thermal.user_override: 0 >> hw.acpi.thermal.tz0.temperature: 0.0C >> hw.acpi.thermal.tz0.active: -1 >> hw.acpi.thermal.tz0.passive_cooling: 1 >> hw.acpi.thermal.tz0.thermal_flags: 0 >> hw.acpi.thermal.tz0._PSV: 90.0C >> hw.acpi.thermal.tz0._HOT: -1 >> hw.acpi.thermal.tz0._CRT: 94.0C >> hw.acpi.thermal.tz0._ACx: 40.0C -1 -1 -1 -1 -1 -1 -1 -1 -1 >> >> Note: temperature is always 0.0C. >> >> What can I do to help my situation, if I really want the kernel doing >> the cooling? >> >> Warner >> > > Wow, something's really wrong with those calculated temperatures. At > that value most of the plastic and weaker circuitry should have fused > together =\. It would be interesting to see what the values are just after booting, or even earlier if you can get the bios to give temperatures (some MBs have that possibility) > -Garrett > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 2 04:16:50 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CDFA16A418 for ; Thu, 2 Aug 2007 04:16:50 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outG.internet-mail-service.net (outG.internet-mail-service.net [216.240.47.230]) by mx1.freebsd.org (Postfix) with ESMTP id 695D613C45E for ; Thu, 2 Aug 2007 04:16:50 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Wed, 01 Aug 2007 21:16:49 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id F1F13125B14; Wed, 1 Aug 2007 21:16:48 -0700 (PDT) Message-ID: <46B15AD9.60406@elischer.org> Date: Wed, 01 Aug 2007 21:17:29 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.5 (Macintosh/20070716) MIME-Version: 1.0 To: Garrett Cooper References: <46AE58B5.3080506@gahr.ch> <46AE8F78.1060203@root.org> <20070801.211718.1683324313.imp@bsdimp.com> <46B14EFB.6010207@u.washington.edu> <46B15166.1070305@elischer.org> In-Reply-To: <46B15166.1070305@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: acpi@freebsd.org, freebsd-hackers@freebsd.org, nate@root.org, ume@freebsd.org, gahr@gahr.ch Subject: Re: [patch] enhance powerd(8) to handle max temperature X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2007 04:16:50 -0000 Julian Elischer wrote: > Garrett Cooper wrote: >> M. Warner Losh wrote: >>> In message: <46AE8F78.1060203@root.org> >>> Nate Lawson writes: >>> : Hajimu UMEMOTO wrote: >>> : >>>>>> On Mon, 30 Jul 2007 23:31:33 +0200 >>> : >>>>>> Pietro Cerutti said: >>> : > gahr> My patch is really just a first draft that I wrote in order >>> to have >>> : > gahr> feedbacks on the general idea to implement a temperature >>> controlling >>> : > gahr> system inside powerd, and doesn't implement hysteresis as >>> you noted, and >>> : > gahr> your feedback is that it's not a good idea, which I respect. >>> : > : > It is rather backward, IMHO. I did implement a passive cooling >>> : > feature as an enhancement of powerd(8) like you did, during initial >>> : > phases. Then, I implemented it in our kernel as a result. >>> : : I'll take a look at your patch. Umemoto-san is right in that you >>> really >>> : want the kernel to control cooling. What happens if powerd dies/hangs >>> : and your system burns up? Passive cooling is often a last resort to >>> : keep the system from overheating. >>> >>> I keep getting the system shutting down on my HP by FreeBSD because >>> the temperature exceeds the _CRT value. Maybe there's something wrong >>> with my values, since it happens a lot: >>> >>> hw.acpi.thermal.min_runtime: 0 >>> hw.acpi.thermal.polling_rate: 10 >>> hw.acpi.thermal.user_override: 0 >>> hw.acpi.thermal.tz0.temperature: 0.0C >>> hw.acpi.thermal.tz0.active: -1 >>> hw.acpi.thermal.tz0.passive_cooling: 1 >>> hw.acpi.thermal.tz0.thermal_flags: 0 >>> hw.acpi.thermal.tz0._PSV: 90.0C >>> hw.acpi.thermal.tz0._HOT: -1 >>> hw.acpi.thermal.tz0._CRT: 94.0C >>> hw.acpi.thermal.tz0._ACx: 40.0C -1 -1 -1 -1 -1 -1 -1 -1 -1 >>> >>> Note: temperature is always 0.0C. >>> >>> What can I do to help my situation, if I really want the kernel doing >>> the cooling? >>> >>> Warner >>> >> >> Wow, something's really wrong with those calculated temperatures. At >> that value most of the plastic and weaker circuitry should have fused >> together =\. > > It would be interesting to see what the values are just after booting, > or even earlier if you can get the bios to give temperatures (some MBs > have that possibility) I might add, after all cooling down to room temperature over night. > From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 2 04:53:34 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDFAD16A4A6; Thu, 2 Aug 2007 04:53:34 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 7A10B13C465; Thu, 2 Aug 2007 04:53:34 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l724olgS048881; Wed, 1 Aug 2007 22:50:47 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 01 Aug 2007 22:50:55 -0600 (MDT) Message-Id: <20070801.225055.-345495092.imp@bsdimp.com> To: julian@elischer.org From: "M. Warner Losh" In-Reply-To: <46B15166.1070305@elischer.org> References: <20070801.211718.1683324313.imp@bsdimp.com> <46B14EFB.6010207@u.washington.edu> <46B15166.1070305@elischer.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Wed, 01 Aug 2007 22:50:48 -0600 (MDT) Cc: ume@freebsd.org, acpi@freebsd.org, freebsd-hackers@freebsd.org, youshi10@u.washington.edu, gahr@gahr.ch, nate@root.org Subject: Re: [patch] enhance powerd(8) to handle max temperature X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2007 04:53:35 -0000 In message: <46B15166.1070305@elischer.org> Julian Elischer writes: : Garrett Cooper wrote: : > M. Warner Losh wrote: : >> In message: <46AE8F78.1060203@root.org> : >> Nate Lawson writes: : >> : Hajimu UMEMOTO wrote: : >> : >>>>>> On Mon, 30 Jul 2007 23:31:33 +0200 : >> : >>>>>> Pietro Cerutti said: : >> : > gahr> My patch is really just a first draft that I wrote in order : >> to have : >> : > gahr> feedbacks on the general idea to implement a temperature : >> controlling : >> : > gahr> system inside powerd, and doesn't implement hysteresis as : >> you noted, and : >> : > gahr> your feedback is that it's not a good idea, which I respect. : >> : > : > It is rather backward, IMHO. I did implement a passive cooling : >> : > feature as an enhancement of powerd(8) like you did, during initial : >> : > phases. Then, I implemented it in our kernel as a result. : >> : : I'll take a look at your patch. Umemoto-san is right in that you : >> really : >> : want the kernel to control cooling. What happens if powerd dies/hangs : >> : and your system burns up? Passive cooling is often a last resort to : >> : keep the system from overheating. : >> : >> I keep getting the system shutting down on my HP by FreeBSD because : >> the temperature exceeds the _CRT value. Maybe there's something wrong : >> with my values, since it happens a lot: : >> : >> hw.acpi.thermal.min_runtime: 0 : >> hw.acpi.thermal.polling_rate: 10 : >> hw.acpi.thermal.user_override: 0 : >> hw.acpi.thermal.tz0.temperature: 0.0C : >> hw.acpi.thermal.tz0.active: -1 : >> hw.acpi.thermal.tz0.passive_cooling: 1 : >> hw.acpi.thermal.tz0.thermal_flags: 0 : >> hw.acpi.thermal.tz0._PSV: 90.0C : >> hw.acpi.thermal.tz0._HOT: -1 : >> hw.acpi.thermal.tz0._CRT: 94.0C : >> hw.acpi.thermal.tz0._ACx: 40.0C -1 -1 -1 -1 -1 -1 -1 -1 -1 : >> : >> Note: temperature is always 0.0C. : >> : >> What can I do to help my situation, if I really want the kernel doing : >> the cooling? : >> : >> Warner : >> : > : > Wow, something's really wrong with those calculated temperatures. At : > that value most of the plastic and weaker circuitry should have fused : > together =\. : : It would be interesting to see what the values are just after booting, : or even earlier if you can get the bios to give temperatures : (some MBs have that possibility) The values are always the same. ACx is always 40C -1 ... and temperature is always 0. Warner From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 2 04:58:10 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D91516A419; Thu, 2 Aug 2007 04:58:10 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by mx1.freebsd.org (Postfix) with ESMTP id E9BD513C442; Thu, 2 Aug 2007 04:58:09 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout1.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.06) with ESMTP id l724w6E6017345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 1 Aug 2007 21:58:06 -0700 X-Auth-Received: from [192.168.10.45] (c-24-10-12-194.hsd1.ca.comcast.net [24.10.12.194]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l724w5LL018340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 1 Aug 2007 21:58:06 -0700 Message-ID: <46B1645B.5070108@u.washington.edu> Date: Wed, 01 Aug 2007 21:58:03 -0700 From: Garrett Cooper User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: "M. Warner Losh" References: <20070801.211718.1683324313.imp@bsdimp.com> <46B14EFB.6010207@u.washington.edu> <46B15166.1070305@elischer.org> <20070801.225055.-345495092.imp@bsdimp.com> In-Reply-To: <20070801.225055.-345495092.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.1.214323 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Cc: ume@freebsd.org, acpi@freebsd.org, freebsd-hackers@freebsd.org, gahr@gahr.ch, julian@elischer.org, nate@root.org Subject: Re: [patch] enhance powerd(8) to handle max temperature X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2007 04:58:10 -0000 M. Warner Losh wrote: > In message: <46B15166.1070305@elischer.org> > Julian Elischer writes: > : Garrett Cooper wrote: > : > M. Warner Losh wrote: > : >> In message: <46AE8F78.1060203@root.org> > : >> Nate Lawson writes: > : >> : Hajimu UMEMOTO wrote: > : >> : >>>>>> On Mon, 30 Jul 2007 23:31:33 +0200 > : >> : >>>>>> Pietro Cerutti said: > : >> : > gahr> My patch is really just a first draft that I wrote in order > : >> to have > : >> : > gahr> feedbacks on the general idea to implement a temperature > : >> controlling > : >> : > gahr> system inside powerd, and doesn't implement hysteresis as > : >> you noted, and > : >> : > gahr> your feedback is that it's not a good idea, which I respect. > : >> : > : > It is rather backward, IMHO. I did implement a passive cooling > : >> : > feature as an enhancement of powerd(8) like you did, during initial > : >> : > phases. Then, I implemented it in our kernel as a result. > : >> : : I'll take a look at your patch. Umemoto-san is right in that you > : >> really > : >> : want the kernel to control cooling. What happens if powerd dies/hangs > : >> : and your system burns up? Passive cooling is often a last resort to > : >> : keep the system from overheating. > : >> > : >> I keep getting the system shutting down on my HP by FreeBSD because > : >> the temperature exceeds the _CRT value. Maybe there's something wrong > : >> with my values, since it happens a lot: > : >> > : >> hw.acpi.thermal.min_runtime: 0 > : >> hw.acpi.thermal.polling_rate: 10 > : >> hw.acpi.thermal.user_override: 0 > : >> hw.acpi.thermal.tz0.temperature: 0.0C > : >> hw.acpi.thermal.tz0.active: -1 > : >> hw.acpi.thermal.tz0.passive_cooling: 1 > : >> hw.acpi.thermal.tz0.thermal_flags: 0 > : >> hw.acpi.thermal.tz0._PSV: 90.0C > : >> hw.acpi.thermal.tz0._HOT: -1 > : >> hw.acpi.thermal.tz0._CRT: 94.0C > : >> hw.acpi.thermal.tz0._ACx: 40.0C -1 -1 -1 -1 -1 -1 -1 -1 -1 > : >> > : >> Note: temperature is always 0.0C. > : >> > : >> What can I do to help my situation, if I really want the kernel doing > : >> the cooling? > : >> > : >> Warner > : >> > : > > : > Wow, something's really wrong with those calculated temperatures. At > : > that value most of the plastic and weaker circuitry should have fused > : > together =\. > : > : It would be interesting to see what the values are just after booting, > : or even earlier if you can get the bios to give temperatures > : (some MBs have that possibility) > > The values are always the same. ACx is always 40C -1 ... and > temperature is always 0. > > Warner > Not all temperature sensors report accurate values, just like fans' rpm levels. -Garrett From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 2 04:50:15 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4258916A419; Thu, 2 Aug 2007 04:50:15 +0000 (UTC) (envelope-from SRS0=4a0cb565816d8f22be5eec8a588eb547e0885b96=414=es.net=oberman@es.net) Received: from postal1.es.net (postal4.es.net [IPv6:2001:400:6000:1::66]) by mx1.freebsd.org (Postfix) with ESMTP id 51E8413C465; Thu, 2 Aug 2007 04:50:12 +0000 (UTC) (envelope-from SRS0=4a0cb565816d8f22be5eec8a588eb547e0885b96=414=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal4.es.net (Postal Node 4) with ESMTP (SSL) id HMA95610; Wed, 01 Aug 2007 21:50:10 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 0A6B045047; Wed, 1 Aug 2007 21:50:09 -0700 (PDT) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Julian Elischer In-Reply-To: Your message of "Wed, 01 Aug 2007 21:17:29 PDT." <46B15AD9.60406@elischer.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1186030209_19060P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Wed, 01 Aug 2007 21:50:09 -0700 From: "Kevin Oberman" Message-Id: <20070802045009.0A6B045047@ptavv.es.net> X-Mailman-Approved-At: Thu, 02 Aug 2007 11:21:08 +0000 Cc: acpi@freebsd.org, freebsd-hackers@freebsd.org, Garrett Cooper , ume@freebsd.org, gahr@gahr.ch Subject: Re: [patch] enhance powerd(8) to handle max temperature X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2007 04:50:15 -0000 --==_Exmh_1186030209_19060P Content-Type: text/plain; charset=us-ascii > > Garrett Cooper wrote: > >> M. Warner Losh wrote: > >>> In message: <46AE8F78.1060203@root.org> > >>> Nate Lawson writes: > >>> : Hajimu UMEMOTO wrote: > >>> : >>>>>> On Mon, 30 Jul 2007 23:31:33 +0200 > >>> : >>>>>> Pietro Cerutti said: > >>> : > gahr> My patch is really just a first draft that I wrote in order > >>> to have > >>> : > gahr> feedbacks on the general idea to implement a temperature > >>> controlling > >>> : > gahr> system inside powerd, and doesn't implement hysteresis as > >>> you noted, and > >>> : > gahr> your feedback is that it's not a good idea, which I respect. > >>> : > : > It is rather backward, IMHO. I did implement a passive cooling > >>> : > feature as an enhancement of powerd(8) like you did, during initial > >>> : > phases. Then, I implemented it in our kernel as a result. > >>> : : I'll take a look at your patch. Umemoto-san is right in that you > >>> really > >>> : want the kernel to control cooling. What happens if powerd dies/hangs > >>> : and your system burns up? Passive cooling is often a last resort to > >>> : keep the system from overheating. > >>> > >>> I keep getting the system shutting down on my HP by FreeBSD because > >>> the temperature exceeds the _CRT value. Maybe there's something wrong > >>> with my values, since it happens a lot: > >>> > >>> hw.acpi.thermal.min_runtime: 0 > >>> hw.acpi.thermal.polling_rate: 10 > >>> hw.acpi.thermal.user_override: 0 > >>> hw.acpi.thermal.tz0.temperature: 0.0C > >>> hw.acpi.thermal.tz0.active: -1 > >>> hw.acpi.thermal.tz0.passive_cooling: 1 > >>> hw.acpi.thermal.tz0.thermal_flags: 0 > >>> hw.acpi.thermal.tz0._PSV: 90.0C > >>> hw.acpi.thermal.tz0._HOT: -1 > >>> hw.acpi.thermal.tz0._CRT: 94.0C > >>> hw.acpi.thermal.tz0._ACx: 40.0C -1 -1 -1 -1 -1 -1 -1 -1 -1 > >>> > >>> Note: temperature is always 0.0C. > >>> > >>> What can I do to help my situation, if I really want the kernel doing > >>> the cooling? > >>> > >>> Warner > >>> > >> > >> Wow, something's really wrong with those calculated temperatures. At > >> that value most of the plastic and weaker circuitry should have fused > >> together =\. > > > > It would be interesting to see what the values are just after booting, > > or even earlier if you can get the bios to give temperatures (some MBs > > have that possibility) Not really. My ThinkPad shows even higher values and I am convinced that they are correct: hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: 55.0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 94.5C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 99.0C hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 These are correct. During heavy compute use, I have seen my laptop CPU at 86C. Nothing melts. According to the other five sensors, nothing ouside of the CPU is anywhere near that hot. (It does get hot enough under the heat pipes and sink to be very uncomfortable when used as a literal laptop.) The CPU temperature is measured by a junction in the chip and it is the hottest point in the machine (unless you have a hot GPU). The days of sensors on the mobo that show an external temp are pretty much over as all recent AMD and Intel chips have internal sensors. If you check the spec sheets, many recent chips are rated for operating at internal temps of 100C and higher. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1186030209_19060P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFGsWKBkn3rs5h7N1ERAnbhAJ94mMCqYNxn6ri58Gid74e+JPS+EACgqhBq LZBAaIomMGA++VmiOv52dwE= =dCnc -----END PGP SIGNATURE----- --==_Exmh_1186030209_19060P-- From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 2 12:13:15 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 243AE16A41F; Thu, 2 Aug 2007 12:13:15 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id C3E9C13C45E; Thu, 2 Aug 2007 12:13:14 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.66) with esmtp (envelope-from ) id <1IGZ8C-0006ju-29>; Thu, 02 Aug 2007 13:46:16 +0200 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.66) with esmtpsa (envelope-from ) id <1IGZ8C-0004FK-16>; Thu, 02 Aug 2007 13:46:16 +0200 Message-ID: <46B1C40A.20208@zedat.fu-berlin.de> Date: Thu, 02 Aug 2007 11:46:18 +0000 From: "O. Hartmann" Organization: Freie =?ISO-8859-15?Q?Universit=E4t_Berlin?= User-Agent: Thunderbird 2.0.0.5 (X11/20070726) MIME-Version: 1.0 To: =?ISO-8859-15?Q?Dag-Erling_Sm=F8rgrav?= References: <46AA0491.5000203@gahr.ch> <46ADAF5B.6050602@gahr.ch> <20070730180355.GA7355@rot26.obsecurity.org> <46AE58B5.3080506@gahr.ch> <46AECE8C.8000500@gahr.ch> <86hcnjn1bs.fsf@ds4.des.no> In-Reply-To: <86hcnjn1bs.fsf@ds4.des.no> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable X-Originating-IP: 130.133.86.198 X-Mailman-Approved-At: Thu, 02 Aug 2007 12:38:54 +0000 Cc: acpi@freebsd.org, freebsd-hackers@freebsd.org, Hajimu UMEMOTO , Pietro Cerutti Subject: Re: [patch] enhance powerd(8) to handle max temperature X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2007 12:13:15 -0000 Dag-Erling Sm=F8rgrav wrote: > Hajimu UMEMOTO writes: >> I cannot see _TC1, _TC2 nor _TSP in your `acpidump -dt' output. >> Further, there is no _PSV definition in anywhere, in the first place. >> It seems to me that your ACPI BIOS doesn't support passive cooling at >> all. >=20 > Going off on a tangent, I too have several motherboards (965P-based) > which do not define any ACPI thermal zones, which leads me to wonder: > what is the preferred way to access thermal data these days? IPMI? Do= > we have IPMI support in base or ports? >=20 > DES Well, At our lab we have a lot of i965-based Intel boxes as well as some=20 nForce-4 based ones. I use at home also a nForce4-based one and I=20 realized that none of them equipted qith an AMI BIOS does not show up=20 temperature zones in ACPI. I had an ASUS A8N-SLI motherboard with AWARD BIOS where I definitely had = those temperature zones, when I changed the motherboard to an A8M32-SLI, = BIOS came from AMI and the temperature-zones informations via ACPI has=20 gone. It seemes to me to be an BISO-vendor issue, due to the super IO=20 chip is of the same brand and only a more modern version in the newer MoB= o. Oliver From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 2 16:03:26 2007 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F32F16A417; Thu, 2 Aug 2007 16:03:26 +0000 (UTC) (envelope-from yrao@force10networks.com) Received: from mx.force10networks.com (nat-eqx.force10networks.com [69.25.56.27]) by mx1.freebsd.org (Postfix) with ESMTP id E5FA113C459; Thu, 2 Aug 2007 16:03:25 +0000 (UTC) (envelope-from yrao@force10networks.com) Received: from mx.force10networks.com ([10.11.0.215]) by mx.force10networks.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Aug 2007 09:03:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Aug 2007 09:03:54 -0700 Message-ID: <9E2742C54E161041A53F36F9A8DC31BE1F992F@EXCH-CLUSTER-04.force10networks.com> In-Reply-To: <46B146F1.8060606@delphij.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: core dump hangs Thread-Index: AcfUsFmk9wE1z31zTyaz69qmDMN2QQAbilfw References: <9E2742C54E161041A53F36F9A8DC31BE1F98B3@EXCH-CLUSTER-04.force10networks.com> <46B135AE.5030002@u.washington.edu> <9E2742C54E161041A53F36F9A8DC31BE1F98C0@EXCH-CLUSTER-04.force10networks.com> <46B146F1.8060606@delphij.net> From: "Yong Rao" To: X-OriginalArrivalTime: 02 Aug 2007 16:03:52.0873 (UTC) FILETIME=[B8C0D990:01C7D51E] X-Mailman-Approved-At: Thu, 02 Aug 2007 16:33:14 +0000 Cc: Garrett Cooper , hackers@FreeBSD.org, remko@FreeBSD.org, remko@elvandar.org Subject: RE: core dump hangs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2007 16:03:26 -0000 Oh, I checked our settings. It is already set debug.minidump=3D0. Thanks, Yong -----Original Message----- From: LI Xin [mailto:delphij@delphij.net]=20 Sent: Wednesday, August 01, 2007 7:53 PM To: Yong Rao Cc: Garrett Cooper; remko@FreeBSD.org; hackers@FreeBSD.org; remko@elvandar.org Subject: Re: core dump hangs Yong Rao wrote: > We use 4BSD (options SCHED_4BSD). Could you please try if setting debug.minidump=3D0 would help the situation? Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 2 17:08:53 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C48716A41A for ; Thu, 2 Aug 2007 17:08:53 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id A0E3113C45D for ; Thu, 2 Aug 2007 17:08:49 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 78036 invoked from network); 2 Aug 2007 17:08:49 -0000 Received: from pni-128-64-133-147.prioritynetworks.net (HELO ?10.0.0.78?) (nate-mail@128.64.133.147) by root.org with ESMTPA; 2 Aug 2007 17:08:49 -0000 Message-ID: <46B20F91.5080709@root.org> Date: Thu, 02 Aug 2007 10:08:33 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.4 (X11/20070617) MIME-Version: 1.0 To: "M. Warner Losh" References: <46AE58B5.3080506@gahr.ch> <46AE8F78.1060203@root.org> <20070801.211718.1683324313.imp@bsdimp.com> In-Reply-To: <20070801.211718.1683324313.imp@bsdimp.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 02 Aug 2007 17:21:30 +0000 Cc: acpi@freebsd.org, freebsd-hackers@freebsd.org, ume@freebsd.org, gahr@gahr.ch Subject: Re: [patch] enhance powerd(8) to handle max temperature X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2007 17:08:53 -0000 M. Warner Losh wrote: > In message: <46AE8F78.1060203@root.org> > Nate Lawson writes: > : Hajimu UMEMOTO wrote: > : >>>>>> On Mon, 30 Jul 2007 23:31:33 +0200 > : >>>>>> Pietro Cerutti said: > : > gahr> My patch is really just a first draft that I wrote in order to have > : > gahr> feedbacks on the general idea to implement a temperature controlling > : > gahr> system inside powerd, and doesn't implement hysteresis as you noted, and > : > gahr> your feedback is that it's not a good idea, which I respect. > : > > : > It is rather backward, IMHO. I did implement a passive cooling > : > feature as an enhancement of powerd(8) like you did, during initial > : > phases. Then, I implemented it in our kernel as a result. > : > : I'll take a look at your patch. Umemoto-san is right in that you really > : want the kernel to control cooling. What happens if powerd dies/hangs > : and your system burns up? Passive cooling is often a last resort to > : keep the system from overheating. > > I keep getting the system shutting down on my HP by FreeBSD because > the temperature exceeds the _CRT value. Maybe there's something wrong > with my values, since it happens a lot: > > hw.acpi.thermal.min_runtime: 0 > hw.acpi.thermal.polling_rate: 10 > hw.acpi.thermal.user_override: 0 > hw.acpi.thermal.tz0.temperature: 0.0C > hw.acpi.thermal.tz0.active: -1 > hw.acpi.thermal.tz0.passive_cooling: 1 > hw.acpi.thermal.tz0.thermal_flags: 0 > hw.acpi.thermal.tz0._PSV: 90.0C > hw.acpi.thermal.tz0._HOT: -1 > hw.acpi.thermal.tz0._CRT: 94.0C > hw.acpi.thermal.tz0._ACx: 40.0C -1 -1 -1 -1 -1 -1 -1 -1 -1 > > Note: temperature is always 0.0C. > > What can I do to help my situation, if I really want the kernel doing > the cooling? Your embedded controller is timing out. Thus you're getting a bogus value for _TMP. Those settings for _CRT appear correct. It's the "measured" temperature that is wrong. -Nate From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 2 17:59:32 2007 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1E4E16A41F; Thu, 2 Aug 2007 17:59:32 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 468D613C4CA; Thu, 2 Aug 2007 17:59:32 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l72HvDJ7061335; Thu, 2 Aug 2007 11:57:15 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 02 Aug 2007 11:57:13 -0600 (MDT) Message-Id: <20070802.115713.71149193.imp@bsdimp.com> To: nate@root.org From: Warner Losh In-Reply-To: <46B20F91.5080709@root.org> References: <46AE8F78.1060203@root.org> <20070801.211718.1683324313.imp@bsdimp.com> <46B20F91.5080709@root.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 02 Aug 2007 11:57:16 -0600 (MDT) Cc: acpi@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG, ume@FreeBSD.ORG, gahr@gahr.ch Subject: Re: [patch] enhance powerd(8) to handle max temperature X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2007 17:59:32 -0000 From: Nate Lawson Subject: Re: [patch] enhance powerd(8) to handle max temperature Date: Thu, 02 Aug 2007 10:08:33 -0700 > M. Warner Losh wrote: > > In message: <46AE8F78.1060203@root.org> > > Nate Lawson writes: > > : Hajimu UMEMOTO wrote: > > : >>>>>> On Mon, 30 Jul 2007 23:31:33 +0200 > > : >>>>>> Pietro Cerutti said: > > : > gahr> My patch is really just a first draft that I wrote in order to have > > : > gahr> feedbacks on the general idea to implement a temperature controlling > > : > gahr> system inside powerd, and doesn't implement hysteresis as you noted, and > > : > gahr> your feedback is that it's not a good idea, which I respect. > > : > > > : > It is rather backward, IMHO. I did implement a passive cooling > > : > feature as an enhancement of powerd(8) like you did, during initial > > : > phases. Then, I implemented it in our kernel as a result. > > : > > : I'll take a look at your patch. Umemoto-san is right in that you really > > : want the kernel to control cooling. What happens if powerd dies/hangs > > : and your system burns up? Passive cooling is often a last resort to > > : keep the system from overheating. > > > > I keep getting the system shutting down on my HP by FreeBSD because > > the temperature exceeds the _CRT value. Maybe there's something wrong > > with my values, since it happens a lot: > > > > hw.acpi.thermal.min_runtime: 0 > > hw.acpi.thermal.polling_rate: 10 > > hw.acpi.thermal.user_override: 0 > > hw.acpi.thermal.tz0.temperature: 0.0C > > hw.acpi.thermal.tz0.active: -1 > > hw.acpi.thermal.tz0.passive_cooling: 1 > > hw.acpi.thermal.tz0.thermal_flags: 0 > > hw.acpi.thermal.tz0._PSV: 90.0C > > hw.acpi.thermal.tz0._HOT: -1 > > hw.acpi.thermal.tz0._CRT: 94.0C > > hw.acpi.thermal.tz0._ACx: 40.0C -1 -1 -1 -1 -1 -1 -1 -1 -1 > > > > Note: temperature is always 0.0C. > > > > What can I do to help my situation, if I really want the kernel doing > > the cooling? > > Your embedded controller is timing out. Thus you're getting a bogus > value for _TMP. > > Those settings for _CRT appear correct. It's the "measured" temperature > that is wrong. So how do I track down the problem? I'm tired of the system just shutting down when I'm building OOO or even something simpler like doing a buildworld... Warner From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 2 21:32:21 2007 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71D5916A420 for ; Thu, 2 Aug 2007 21:32:21 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (adsl-75-1-14-242.dsl.scrm01.sbcglobal.net [75.1.14.242]) by mx1.freebsd.org (Postfix) with ESMTP id 56F6713C483 for ; Thu, 2 Aug 2007 21:32:21 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id l72LKRUS001446; Thu, 2 Aug 2007 14:20:31 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200708022120.l72LKRUS001446@gw.catspoiler.org> Date: Thu, 2 Aug 2007 14:20:27 -0700 (PDT) From: Don Lewis To: jonny@jonny.eng.br In-Reply-To: <46AEC3BF.4080309@jonny.eng.br> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Cc: hackers@FreeBSD.org Subject: Re: Problems with rpc.statd and PAE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2007 21:32:21 -0000 On 31 Jul, Joo Carlos Mendes Lus wrote: > Hi, > > Sent this to -questions, but got no answer. Now I'll try -hackers... > > I've just configured my first server with 4G RAM. To use it, I had > to select PAE in kernel config. I was a little bit troubled by it's > advice not to use modules (is it that critical?), but got it running. > > But when it is running on PAE, NFS statd refuses to run: > > # /etc/rc.d/nfslocking start > Starting statd. > rpc.statd: unable to mmap() status file: Cannot allocate memory > Segmentation fault > # > > Using strace I found it was trying to mmap the status file, at > /var/db/statd.status: > > open("/var/db/statd.status", O_RDWR) = 10 > mmap(0, 268435456, PROT_READ|PROT_WRITE, MAP_SHARED, 10, 0) = -1 ENOMEM > (Cannot allocate memory) > > It's really strange to have mmap len = 256M, specially because the > file is always small. But it works without PAE, and do not work with > PAE. And it is described in the handbook: > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/book.html#STATD-MEM-LEAK I've been seeing this same problem for a long time on an 7.0-CURRENT i386 machine with 1GB of RAM, and I'm not using PAE. I haven't discovered any obvious cause for the problem. From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 2 22:29:04 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC6C116A418 for ; Thu, 2 Aug 2007 22:29:04 +0000 (UTC) (envelope-from tijl@ulyssis.org) Received: from mailrelay011.isp.belgacom.be (mailrelay011.isp.belgacom.be [195.238.6.178]) by mx1.freebsd.org (Postfix) with ESMTP id 47D3813C442 for ; Thu, 2 Aug 2007 22:29:04 +0000 (UTC) (envelope-from tijl@ulyssis.org) Received: from 219.106-247-81.adsl-dyn.isp.belgacom.be (HELO kalimero.kotnet.org) ([81.247.106.219]) by mailrelay011.isp.belgacom.be with ESMTP; 02 Aug 2007 23:59:27 +0200 Received: from localhost (localhost [127.0.0.1]) by kalimero.kotnet.org (8.14.1/8.14.1) with ESMTP id l72LxQDx056765 for ; Thu, 2 Aug 2007 23:59:26 +0200 (CEST) (envelope-from tijl@ulyssis.org) From: Tijl Coosemans To: freebsd-hackers@freebsd.org Date: Thu, 2 Aug 2007 23:59:24 +0200 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Disposition: inline X-Length: 907 X-UID: 23 Content-Type: Multipart/Mixed; boundary="Boundary-00=_9OlsGsmBmDL0Wv2" Message-Id: <200708022359.25700.tijl@ulyssis.org> Subject: ptrace(2) race testcase + proposed patch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2007 22:29:04 -0000 --Boundary-00=_9OlsGsmBmDL0Wv2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline While working on Wine I hit on a race between a ptrace PT_DETACH and subsequent PT_ATTACH which causes the SIGSTOP of this attach to get lost and never delivered. Attached are a test program and a proposed patch. The test program forks a child and loops attaching and detaching to it. It can hang during the wait4 call. The problem occurs when the stopped child process returns from the ptracestop() call in sys/kern/kern_sig.c:issignal() after the parent has already returned from the next PT_ATTACH. Then the signal that caused the process to stop is taken off the sigqueue, but this may already be a new SIGSTOP from the next PT_ATTACH. The solution is to take the signal off the queue before calling ptracestop(). A second cause for the problem is in sys/kern/sys_process.c:kern_ptrace() where PT_ATTACH sets td_xsig of a thread to SIGSTOP. If this thread then returns from ptracestop() (returning td_xsig) and it was previously stopped by a SIGSTOP, the new SIGSTOP is ignored and deleted at the end of issignal(). The solution is to deliver the signal via td_xsig only when the process is currently stopped (and now continuing) and otherwise (PT_ATTACH) using psignal(). This is similar to equivalent code in NetBSD. I was hoping if someone could review this to make sure I did the right thing, because I'm not entirely familiar with this code. --Boundary-00=_9OlsGsmBmDL0Wv2 Content-Type: text/plain; charset="us-ascii"; name="race.c" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="race.c" #include #include #include #include #include #include int main( void ) { pid_t pid; int status; /* fork dummy child process */ pid = fork(); if( pid == 0 ) { /* child does nothing */ for( ; ; ) { sleep( 1 ); } } else { /* parent */ sleep( 1 ); for( ; ; ) { /* loop: attach, wait, detach */ printf( "attach " ); fflush( stdout ); ptrace( PT_ATTACH, pid, ( caddr_t ) 0, 0 ); printf( "wait " ); fflush( stdout ); wait4( pid, &status, 0, NULL ); printf( "detach " ); fflush( stdout ); ptrace( PT_DETACH, pid, ( caddr_t ) 1, 0 ); printf( "\n" ); fflush( stdout ); } } return 0; } --Boundary-00=_9OlsGsmBmDL0Wv2 Content-Type: text/plain; charset="us-ascii"; name="patch-ptrace" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="patch-ptrace" --- sys/kern/kern_sig.c.orig 2007-07-19 10:49:16.000000000 +0200 +++ sys/kern/kern_sig.c 2007-07-26 01:37:22.000000000 +0200 @@ -2543,6 +2543,20 @@ continue; } if (p->p_flag & P_TRACED && (p->p_flag & P_PPWAIT) == 0) { + ksiginfo_t ksi; + + /* + * clear old signal. + * XXX shrug off debugger, it causes siginfo to + * be thrown away. + */ + ksiginfo_init( &ksi ); + sigqueue_get(&td->td_sigqueue, sig, &ksi); +#ifdef KSE + if (td->td_pflags & TDP_SA) + SIGADDSET(td->td_sigmask, sig); +#endif + /* * If traced, always stop. */ @@ -2550,20 +2564,7 @@ newsig = ptracestop(td, sig); mtx_lock(&ps->ps_mtx); -#ifdef KSE - if (td->td_pflags & TDP_SA) - SIGADDSET(td->td_sigmask, sig); - -#endif if (sig != newsig) { - ksiginfo_t ksi; - /* - * clear old signal. - * XXX shrug off debugger, it causes siginfo to - * be thrown away. - */ - sigqueue_get(&td->td_sigqueue, sig, &ksi); - /* * If parent wants us to take the signal, * then it will leave it in p->p_xstat; @@ -2585,6 +2586,9 @@ if (SIGISMEMBER(td->td_sigmask, sig)) continue; signotify(td); + } else { + /* Add old signal back. */ + sigqueue_add(&td->td_sigqueue, sig, &ksi); } /* --- sys/kern/sys_process.c.orig 2007-08-02 15:53:10.000000000 +0200 +++ sys/kern/sys_process.c 2007-08-02 19:49:56.000000000 +0200 @@ -779,14 +779,15 @@ sx_xunlock(&proctree_lock); proctree_locked = 0; } - /* deliver or queue signal */ - thread_lock(td2); - td2->td_flags &= ~TDF_XSIG; - thread_unlock(td2); - td2->td_xsig = data; p->p_xstat = data; p->p_xthread = NULL; if ((p->p_flag & (P_STOPPED_SIG | P_STOPPED_TRACE)) != 0) { + /* deliver or queue signal */ + thread_lock(td2); + td2->td_flags &= ~TDF_XSIG; + thread_unlock(td2); + td2->td_xsig = data; + PROC_SLOCK(p); if (req == PT_DETACH) { struct thread *td3; @@ -809,11 +810,10 @@ p->p_flag &= ~(P_STOPPED_TRACE|P_STOPPED_SIG|P_WAITED); thread_unsuspend(p); PROC_SUNLOCK(p); + } else { + if (data) + psignal(p, data); } - - if (data) - psignal(p, data); - break; case PT_WRITE_I: --Boundary-00=_9OlsGsmBmDL0Wv2-- From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 2 22:39:50 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77FFE16A41B for ; Thu, 2 Aug 2007 22:39:50 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 33E4013C461 for ; Thu, 2 Aug 2007 22:39:49 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 8011D48F6F; Thu, 2 Aug 2007 18:39:48 -0400 (EDT) Date: Thu, 2 Aug 2007 23:39:48 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: ytriffy In-Reply-To: <46AF826E.8000209@gmail.com> Message-ID: <20070802233804.G18327@fledge.watson.org> References: <46AF826E.8000209@gmail.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-2120122349-1186094388=:18327" Cc: freebsd-hackers@freebsd.org Subject: Re: [panic]Fatal trap 12: page fault while in kernel mode X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2007 22:39:50 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-2120122349-1186094388=:18327 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 31 Jul 2007, ytriffy wrote: > Trap 12 occured when I rebooted PC. Sending you backtrace. My system: amd= 64=20 > 3200+ Venice, MB ECS nForce4 A939,Samsung 250GB and WD 250 GB, 2 memory= =20 > banks 512MB each, videocard: Geforce 6600gt 128MB, NIC on realtek chip,= =20 > sound card cirrus logic cs4281. It's very unstable, crashes happen every= =20 > day, so I'm hoping you would say why(any hints what hardware may cause it= ).=20 > How to repeat it? I don't know. It happened once during reboot process. In general, you want to report this sort of bug using the send-pr interface= ,=20 or the gnats web submission form. In the past, I've quite a few bug report= s=20 sent to hackers@ get lost because many FreeBSD developers don't subscribe t= o=20 the list. You could also consider sending it to stable@, since that's the= =20 mailing list for discussing 6-STABLE development. FYI, this looks like a= =20 NULL-pointer dereference in the VFS shutdown code. Robert N M Watson Computer Laboratory University of Cambridge > > [root@freelanc /var]# uname -a > FreeBSD freelanc.dubki.ru 6.2-STABLE-200706=20 > FreeBSD 6.2-STABLE-200706 > #1: Mon Jul 23 13:34:27 MSD 2007 > root@freelanc.dubki.ru:/usr/obj/usr/src/sys/DEBUGGER > KERN i386 > > [root@freelanc /usr/obj/usr/src/sys/DEBUGGERKERN]# kgdb kernel.debug > /var/crash/vmcore.3 > kgdb: kvm_nlist(_stopped_cpus): > kgdb: kvm_nlist(_stoppcbs): > [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= =2E > This GDB was configured as "i386-marcel-freebsd". > > Unread portion of the kernel message buffer: > <118>Jul 25 14:06:32 freelanc syslogd: exiting on signal 15 > Waiting (max 60 seconds) for system process `vnlru' to stop...done > Waiting (max 60 seconds) for system process `syncer' to stop... > Syncing disks, vnodes remaining...6 5 3 1 0 0 done > Waiting (max 60 seconds) for system process `bufdaemon' to stop...done > All buffers synced. > > > Fatal trap 12: page fault while in kernel mode > fault virtual address =3D 0x4 > fault code =3D supervisor read, page not present > instruction pointer =3D 0x20:0xc058a4e0 > stack pointer =3D 0x28:0xe9455c48 > frame pointer =3D 0x28:0xe9455c58 > 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 44922 (reboot) > panic: from debugger > Uptime: 2h45m36s > Dumping 1022 MB (2 chunks) > chunk 0: 1MB (159 pages) ... ok > chunk 1: 1022MB (261600 pages) 1006 990 974 958 942 926 910 894 878 862 > 846 830 814 798 782 766 750 734 718 702 686 670 654 638 622 606 590 574 > 558 542 526 510 494 478 462 446 430 414 398 382 366 350 334 318 302 286 > 270 254 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14 > > #0 doadump () at pcpu.h:165 > 165 __asm __volatile("movl %%fs:0,%0" : "=3Dr" (td)); > (kgdb) bt > #0 doadump () at pcpu.h:165 > #1 0xc053d916 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:= 409 > #2 0xc053dbdc in panic (fmt=3D0xc06f5278 "from debugger") > at /usr/src/sys/kern/kern_shutdown.c:565 > #3 0xc045361d in db_panic (addr=3D-1067932448, have_addr=3D0, count=3D-1, > modif=3D0xe9455a74 "") at /usr/src/sys/ddb/db_command.c:438 > #4 0xc04535b4 in db_command (last_cmdp=3D0xc0766784, cmd_table=3D0x0, > aux_cmd_tablep=3D0xc0728e90, aux_cmd_tablep_end=3D0xc0728e94) > at /usr/src/sys/ddb/db_command.c:350 > #5 0xc045367c in db_command_loop () at /usr/src/sys/ddb/db_command.c:458 > #6 0xc0455291 in db_trap (type=3D12, code=3D0) at > /usr/src/sys/ddb/db_main.c:222 > #7 0xc0556a2b in kdb_trap (type=3D12, code=3D0, tf=3D0xe9455c08) > at /usr/src/sys/kern/subr_kdb.c:473 > #8 0xc06cba6c in trap_fatal (frame=3D0xe9455c08, eva=3D4) > at /usr/src/sys/i386/i386/trap.c:828 > #9 0xc06cb7d7 in trap_pfault (frame=3D0xe9455c08, usermode=3D0, eva=3D4) > at /usr/src/sys/i386/i386/trap.c:745 > #10 0xc06cb3f1 in trap (frame=3D > {tf_fs =3D 8, tf_es =3D 40, tf_ds =3D 40, tf_edi =3D -381330360, tf_esi = =3D > -993547624, tf_ebp =3D -381330344, tf_isp =3D -381330380, tf_ebx =3D 0, t= f_edx > =3D -992513384, tf_ecx =3D 4, tf_eax =3D -950651024, tf_trapno =3D 12, tf= _err =3D > 0, tf_eip =3D -1067932448, tf_cs =3D 32, tf_eflags =3D 590338, tf_esp =3D= 0, > tf_ss =3D -992305712}) > at /usr/src/sys/i386/i386/trap.c:435 > #11 0xc06b8b1a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > #12 0xc058a4e0 in cache_purgevfs (mp=3D0xc4d77298) > at /usr/src/sys/kern/vfs_cache.c:622 > #13 0xc0591f29 in dounmount (mp=3D0xc4d77298, flags=3D524288, td=3D0xc62c= e300) > at /usr/src/sys/kern/vfs_mount.c:1214 > #14 0xc0597d0a in vfs_unmountall () at /usr/src/sys/kern/vfs_subr.c:2837 > #15 0xc053d807 in boot (howto=3D0) at /usr/src/sys/kern/kern_shutdown.c:3= 91 > #16 0xc053d2a2 in reboot (td=3D0xc62ce300, uap=3D0xc7563770) > at /usr/src/sys/kern/kern_shutdown.c:169 > #17 0xc06cbdbb in syscall (frame=3D > {tf_fs =3D 59, tf_es =3D 59, tf_ds =3D 59, tf_edi =3D 2, tf_esi =3D 18, t= f_ebp =3D > -1077941304, tf_isp =3D -381330076, tf_ebx =3D 0, tf_edx =3D -1, tf_ecx = =3D > 672491264, tf_eax =3D 55, tf_trapno =3D 12, tf_err =3D 2, tf_eip =3D 6718= 02263, > tf_cs =3D 51, tf_eflags =3D 662, tf_esp =3D -1077941380, tf_ss =3D 59}) a= t > /usr/src/sys/i386/i386/trap.c:983 > #18 0xc06b8b6f in Xint0x80_syscall () at > /usr/src/sys/i386/i386/exception.s:200 > #19 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) up 19 > #19 0x00000033 in ?? () > (kgdb) down 1 > #18 0xc06b8b6f in Xint0x80_syscall () at > /usr/src/sys/i386/i386/exception.s:200 > 200 call syscall > Current language: auto; currently asm > (kgdb) down 1 > #17 0xc06cbdbb in syscall (frame=3D > {tf_fs =3D 59, tf_es =3D 59, tf_ds =3D 59, tf_edi =3D 2, tf_esi =3D 18, t= f_ebp =3D > -1077941304, tf_isp =3D -381330076, tf_ebx =3D 0, tf_edx =3D -1, tf_ecx = =3D > 672491264, tf_eax =3D 55, tf_trapno =3D 12, tf_err =3D 2, tf_eip =3D 6718= 02263, > tf_cs =3D 51, tf_eflags =3D 662, tf_esp =3D -1077941380, tf_ss =3D 59}) a= t > /usr/src/sys/i386/i386/trap.c:983 > 983 error =3D (*callp->sy_call)(td, args); > Current language: auto; currently c > (kgdb) p *callp > $1 =3D {sy_narg =3D 65537, sy_call =3D 0xc053d258 , sy_auevent = =3D 20} > (kgdb) p *callp->sy_call > $2 =3D {int (struct thread *, void *)} 0xc053d258 > (kgdb) p td > $3 =3D (struct thread *) 0xc62ce300 > (kgdb) p args > $4 =3D {0, 9, -994250272, -1077941388, 0, 0, 3, 0} > (kgdb) down 1 > #16 0xc053d2a2 in reboot (td=3D0xc62ce300, uap=3D0xc7563770) > at /usr/src/sys/kern/kern_shutdown.c:169 > 169 boot(uap->opt); > (kgdb) p uap > $5 =3D (struct reboot_args *) 0xc7563770 > (kgdb) p uap->opt > $6 =3D 2 > (kgdb) down 1 > #15 0xc053d807 in boot (howto=3D0) at /usr/src/sys/kern/kern_shutdown.c:3= 91 > 391 vfs_unmountall(); > (kgdb) down 1 > #14 0xc0597d0a in vfs_unmountall () at /usr/src/sys/kern/vfs_subr.c:2837 > 2837 error =3D dounmount(mp, MNT_FORCE, td); > (kgdb) p mp > $7 =3D (struct mount *) 0xc4d77298 > (kgdb) p td > $8 =3D (struct thread *) 0xc62ce300 > (kgdb) down 1 > #13 0xc0591f29 in dounmount (mp=3D0xc4d77298, flags=3D524288, td=3D0xc62c= e300) > at /usr/src/sys/kern/vfs_mount.c:1214 > 1214 cache_purgevfs(mp); /* remove cache entries for this file sys */ > (kgdb) down 1 > #12 0xc058a4e0 in cache_purgevfs (mp=3D0xc4d77298) > at /usr/src/sys/kern/vfs_cache.c:622 > 622 for (ncp =3D LIST_FIRST(ncpp); ncp !=3D 0; ncp =3D nnp) { > (kgdb) p ncp > $9 =3D (struct namecache *) 0x4 > (kgdb) p ncpp > $10 =3D (struct nchashhead *) 0xc4c7aa98 > (kgdb) down 1 > #11 0xc06b8b1a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > 139 call trap > Current language: auto; currently asm > (kgdb) down 1 > #10 0xc06cb3f1 in trap (frame=3D > {tf_fs =3D 8, tf_es =3D 40, tf_ds =3D 40, tf_edi =3D -381330360, tf_esi = =3D > -993547624, tf_ebp =3D -381330344, tf_isp =3D -381330380, tf_ebx =3D 0, t= f_edx > =3D -992513384, tf_ecx =3D 4, tf_eax =3D -950651024, tf_trapno =3D 12, tf= _err =3D > 0, tf_eip =3D -1067932448, tf_cs =3D 32, tf_eflags =3D 590338, tf_esp =3D= 0, > tf_ss =3D -992305712}) > at /usr/src/sys/i386/i386/trap.c:435 > 435 (void) trap_pfault(&frame, FALSE, eva); > Current language: auto; currently c > (kgdb) p frame > $11 =3D {tf_fs =3D 8, tf_es =3D 40, tf_ds =3D 40, tf_edi =3D -381330360, > tf_esi =3D -993547624, tf_ebp =3D -381330344, tf_isp =3D -381330380, tf_e= bx =3D 0, > tf_edx =3D -992513384, tf_ecx =3D 4, tf_eax =3D -950651024, tf_trapno =3D= 12, > tf_err =3D 0, tf_eip =3D -1067932448, tf_cs =3D 32, tf_eflags =3D 590338, > tf_esp =3D 0, tf_ss =3D -992305712} > (kgdb) p eva > $12 =3D 4 > (kgdb) down 1 > #9 0xc06cb7d7 in trap_pfault (frame=3D0xe9455c08, usermode=3D0, eva=3D4) > at /usr/src/sys/i386/i386/trap.c:745 > 745 trap_fatal(frame, eva); > (kgdb) down 1 > #8 0xc06cba6c in trap_fatal (frame=3D0xe9455c08, eva=3D4) > at /usr/src/sys/i386/i386/trap.c:828 > 828 if (kdb_trap(type, 0, frame)) { > (kgdb) p type > $13 =3D 12 > (kgdb) down 1 > #7 0xc0556a2b in kdb_trap (type=3D12, code=3D0, tf=3D0xe9455c08) > at /usr/src/sys/kern/subr_kdb.c:473 > 473 handled =3D kdb_dbbe->dbbe_trap(type, code); > (kgdb) p kdb_dbbe > $14 =3D (struct kdb_dbbe *) 0xc072f0e0 > (kgdb) p kdb_dbbe->dbbe_trap > $15 =3D (dbbe_trap_f *) 0xc04551ac > (kgdb) p type > $16 =3D 12 > (kgdb) p code > $17 =3D 0 > (kgdb) down 1 > #6 0xc0455291 in db_trap (type=3D12, code=3D0) at > /usr/src/sys/ddb/db_main.c:222 > 222 db_command_loop(); > (kgdb) down 1 > #5 0xc045367c in db_command_loop () at /usr/src/sys/ddb/db_command.c:458 > 458 db_command(&db_last_command, db_command_table, > (kgdb) p &db_last_command > $18 =3D (struct command **) 0xc0766784 > (kgdb) p db_command_table > $19 =3D {{name =3D 0xc0726d8d "print", fcn =3D 0xc0453e44 ,= flag > =3D 0, > more =3D 0x0}, {name =3D 0xc0707446 "p", fcn =3D 0xc0453e44 , > flag =3D 0, more =3D 0x0}, {name =3D 0xc06f521d "examine", > fcn =3D 0xc0453b74 , flag =3D 256, more =3D 0x0}, { > name =3D 0xc06f3248 "x", fcn =3D 0xc0453b74 , flag =3D 25= 6, > more =3D 0x0}, {name =3D 0xc06f5225 "search", > fcn =3D 0xc0453f44 , flag =3D 257, more =3D 0x0}, { > name =3D 0xc06fc7c7 "set", fcn =3D 0xc0456d98 , flag =3D 1, > more =3D 0x0}, {name =3D 0xc071c1dc "write", fcn =3D 0xc045714c , > flag =3D 258, more =3D 0x0}, {name =3D 0xc070470c "w", > fcn =3D 0xc045714c , flag =3D 258, more =3D 0x0}, { > name =3D 0xc0711df9 "delete", fcn =3D 0xc045312c , flag = =3D 0, > more =3D 0x0}, {name =3D 0xc06f3296 "d", fcn =3D 0xc045312c , > flag =3D 0, more =3D 0x0}, {name =3D 0xc06f522c "break", > fcn =3D 0xc0453144 , flag =3D 0, more =3D 0x0}, { > name =3D 0xc06f5232 "dwatch", fcn =3D 0xc0457014 , > flag =3D 0, more =3D 0x0}, {name =3D 0xc06f5233 "watch", > fcn =3D 0xc045702c , flag =3D 2, more =3D 0x0}, { > name =3D 0xc06f5239 "dhwatch", fcn =3D 0xc04570e4 , > flag =3D 0, more =3D 0x0}, {name =3D 0xc06f523a "hwatch", > fcn =3D 0xc0457118 , flag =3D 0, more =3D 0x0}, { > name =3D 0xc0721ca0 "step", fcn =3D 0xc0456438 , flag= =3D 0, > more =3D 0x0}, {name =3D 0xc06f55e4 "s", > fcn =3D 0xc0456438 , flag =3D 0, more =3D 0x0}, { > name =3D 0xc06f5241 "continue", fcn =3D 0xc045653c , > flag =3D 0, more =3D 0x0}, {name =3D 0xc0713305 "c", > fcn =3D 0xc045653c , flag =3D 0, more =3D 0x0}, { > name =3D 0xc06f524a "until", fcn =3D 0xc04564a0 = , > flag =3D 0, more =3D 0x0}, {name =3D 0xc06f5250 "next", > fcn =3D 0xc04564e8 , flag =3D 0, more =3D 0x= 0}, { > name =3D 0xc070d7da "match", fcn =3D 0xc04564e8 , > flag =3D 0, more =3D 0x0}, {name =3D 0xc070882b "trace", > fcn =3D 0xc0453a4c , flag =3D 1, more =3D 0x0}, { > name =3D 0xc06f5255 "alltrace", fcn =3D 0xc0453b20 , > flag =3D 0, more =3D 0x0}, {name =3D 0xc07249cf "where", > fcn =3D 0xc0453a4c , flag =3D 1, more =3D 0x0}, { > name =3D 0xc06f525e "bt", fcn =3D 0xc0453a4c , flag =3D 1= , > more =3D 0x0}, {name =3D 0xc071aa99 "call", fcn =3D 0xc04536b0 , > flag =3D 1, more =3D 0x0}, {name =3D 0xc06f5261 "show", fcn =3D 0, flag = =3D 0, > more =3D 0xc072edc0}, {name =3D 0xc07126a2 "ps", fcn =3D 0xc0455784 , > flag =3D 0, more =3D 0x0}, {name =3D 0xc06f5266 "gdb", > fcn =3D 0xc0453a18 , flag =3D 0, more =3D 0x0}, { > name =3D 0xc06fc600 "reset", fcn =3D 0xc0453920 , flag =3D 0, > more =3D 0x0}, {name =3D 0xc06f526a "kill", fcn =3D 0xc04537d8 , > flag =3D 1, more =3D 0x0}, {name =3D 0xc06f526f "watchdog", > fcn =3D 0xc045392c , flag =3D 0, more =3D 0x0}, { > name =3D 0xc070887d "thread", fcn =3D 0xc0456a10 , flag = =3D 1, > more =3D 0x0}, {name =3D 0x0, fcn =3D 0, flag =3D 0, more =3D 0x0}} > (kgdb) down 1 > #4 0xc04535b4 in db_command (last_cmdp=3D0xc0766784, cmd_table=3D0x0, > aux_cmd_tablep=3D0xc0728e90, aux_cmd_tablep_end=3D0xc0728e94) > at /usr/src/sys/ddb/db_command.c:350 > 350 (*cmd->fcn)(addr, have_addr, count, modif); > (kgdb) p addr > $20 =3D -1067932448 > (kgdb) p have_addr > $21 =3D 0 > (kgdb) p count > $22 =3D -1 > (kgdb) p modif > $23 =3D > "\000ZEDj\214ZE\220ZE\211\a\000\000ZE\"LJ\000\000\000\000\000=A4\2005y\r\= 000\000\000\2005y\r\000\000\000\001\000\000\000=BBZE\213j=BBZEj\000@@\036wx= \000\000\000\200pv\f\000\000\000ZE > (kgdb) down 1 > #3 0xc045361d in db_panic (addr=3D-1067932448, have_addr=3D0, count=3D-1, > modif=3D0xe9455a74 "") at /usr/src/sys/ddb/db_command.c:438 > 438 panic("from debugger"); > (kgdb) down 1 > #2 0xc053dbdc in panic (fmt=3D0xc06f5278 "from debugger") > at /usr/src/sys/kern/kern_shutdown.c:565 > 565 boot(bootopt); > (kgdb) p bootopt > $24 =3D 260 > (kgdb) down 1 > #1 0xc053d916 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:= 409 > 409 doadump(); > (kgdb) down 1 > #0 doadump () at pcpu.h:165 > 165 __asm __volatile("movl %%fs:0,%0" : "=3Dr" (td)); > (kgdb) > > Some other info orequired - feel free to email me:) > Best regards, Slava. > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > --0-2120122349-1186094388=:18327-- From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 2 22:41:41 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B60316A417; Thu, 2 Aug 2007 22:41:41 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 3660213C49D; Thu, 2 Aug 2007 22:41:41 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l72Mf9re064933; Thu, 2 Aug 2007 16:41:09 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 02 Aug 2007 16:41:16 -0600 (MDT) Message-Id: <20070802.164116.-1894448262.imp@bsdimp.com> To: nate@root.org From: "M. Warner Losh" In-Reply-To: <46B25AD0.70706@root.org> References: <46B20F91.5080709@root.org> <20070802.115713.71149193.imp@bsdimp.com> <46B25AD0.70706@root.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 02 Aug 2007 16:41:10 -0600 (MDT) Cc: acpi@freebsd.org, freebsd-hackers@freebsd.org, ume@freebsd.org, gahr@gahr.ch Subject: Re: [patch] enhance powerd(8) to handle max temperature X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2007 22:41:41 -0000 In message: <46B25AD0.70706@root.org> Nate Lawson writes: : Warner Losh wrote: : > From: Nate Lawson : > Subject: Re: [patch] enhance powerd(8) to handle max temperature : > Date: Thu, 02 Aug 2007 10:08:33 -0700 : > : >> M. Warner Losh wrote: : >>> I keep getting the system shutting down on my HP by FreeBSD because : >>> the temperature exceeds the _CRT value. Maybe there's something wrong : >>> with my values, since it happens a lot: : >>> : >>> hw.acpi.thermal.min_runtime: 0 : >>> hw.acpi.thermal.polling_rate: 10 : >>> hw.acpi.thermal.user_override: 0 : >>> hw.acpi.thermal.tz0.temperature: 0.0C : >>> hw.acpi.thermal.tz0.active: -1 : >>> hw.acpi.thermal.tz0.passive_cooling: 1 : >>> hw.acpi.thermal.tz0.thermal_flags: 0 : >>> hw.acpi.thermal.tz0._PSV: 90.0C : >>> hw.acpi.thermal.tz0._HOT: -1 : >>> hw.acpi.thermal.tz0._CRT: 94.0C : >>> hw.acpi.thermal.tz0._ACx: 40.0C -1 -1 -1 -1 -1 -1 -1 -1 -1 : >>> : >>> Note: temperature is always 0.0C. : >>> : >>> What can I do to help my situation, if I really want the kernel doing : >>> the cooling? : >> Your embedded controller is timing out. Thus you're getting a bogus : >> value for _TMP. : >> : >> Those settings for _CRT appear correct. It's the "measured" temperature : >> that is wrong. : > : > So how do I track down the problem? I'm tired of the system just : > shutting down when I'm building OOO or even something simpler like : > doing a buildworld... : : You do what's #1 on my list, which is rewrite the EC driver event model : (yet again) and figure out if it's possible to automatically detect : which workarounds are needed. Linux requires you to specify boot-time : flags to select polled or event-driven work. Hmmm. OK. Warner From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 2 22:29:44 2007 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DCCD16A41A for ; Thu, 2 Aug 2007 22:29:44 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 4C34813C465 for ; Thu, 2 Aug 2007 22:29:44 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 94511 invoked from network); 2 Aug 2007 22:29:45 -0000 Received: from pni-128-64-133-147.prioritynetworks.net (HELO ?10.0.0.78?) (nate-mail@128.64.133.147) by root.org with ESMTPA; 2 Aug 2007 22:29:45 -0000 Message-ID: <46B25AD0.70706@root.org> Date: Thu, 02 Aug 2007 15:29:36 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.4 (X11/20070617) MIME-Version: 1.0 To: Warner Losh References: <46AE8F78.1060203@root.org> <20070801.211718.1683324313.imp@bsdimp.com> <46B20F91.5080709@root.org> <20070802.115713.71149193.imp@bsdimp.com> In-Reply-To: <20070802.115713.71149193.imp@bsdimp.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 02 Aug 2007 23:29:05 +0000 Cc: acpi@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG, ume@FreeBSD.ORG, gahr@gahr.ch Subject: Re: [patch] enhance powerd(8) to handle max temperature X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2007 22:29:44 -0000 Warner Losh wrote: > From: Nate Lawson > Subject: Re: [patch] enhance powerd(8) to handle max temperature > Date: Thu, 02 Aug 2007 10:08:33 -0700 > >> M. Warner Losh wrote: >>> I keep getting the system shutting down on my HP by FreeBSD because >>> the temperature exceeds the _CRT value. Maybe there's something wrong >>> with my values, since it happens a lot: >>> >>> hw.acpi.thermal.min_runtime: 0 >>> hw.acpi.thermal.polling_rate: 10 >>> hw.acpi.thermal.user_override: 0 >>> hw.acpi.thermal.tz0.temperature: 0.0C >>> hw.acpi.thermal.tz0.active: -1 >>> hw.acpi.thermal.tz0.passive_cooling: 1 >>> hw.acpi.thermal.tz0.thermal_flags: 0 >>> hw.acpi.thermal.tz0._PSV: 90.0C >>> hw.acpi.thermal.tz0._HOT: -1 >>> hw.acpi.thermal.tz0._CRT: 94.0C >>> hw.acpi.thermal.tz0._ACx: 40.0C -1 -1 -1 -1 -1 -1 -1 -1 -1 >>> >>> Note: temperature is always 0.0C. >>> >>> What can I do to help my situation, if I really want the kernel doing >>> the cooling? >> Your embedded controller is timing out. Thus you're getting a bogus >> value for _TMP. >> >> Those settings for _CRT appear correct. It's the "measured" temperature >> that is wrong. > > So how do I track down the problem? I'm tired of the system just > shutting down when I'm building OOO or even something simpler like > doing a buildworld... You do what's #1 on my list, which is rewrite the EC driver event model (yet again) and figure out if it's possible to automatically detect which workarounds are needed. Linux requires you to specify boot-time flags to select polled or event-driven work. -Nate From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 3 03:45:37 2007 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F409E16A41A for ; Fri, 3 Aug 2007 03:45:36 +0000 (UTC) (envelope-from jonny@jonny.eng.br) Received: from coe.ufrj.br (roma.coe.ufrj.br [146.164.53.65]) by mx1.freebsd.org (Postfix) with ESMTP id 97B6013C467 for ; Fri, 3 Aug 2007 03:45:36 +0000 (UTC) (envelope-from jonny@jonny.eng.br) Received: from localhost (localhost [127.0.0.1]) by coe.ufrj.br (Postfix) with ESMTP id 7C5F11256C0; Fri, 3 Aug 2007 00:45:35 -0300 (BRT) X-Virus-Scanned: amavisd-new at coe.ufrj.br Received: from coe.ufrj.br ([146.164.53.65]) by localhost (roma.coe.ufrj.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vKiB8sHNrcO; Fri, 3 Aug 2007 00:45:30 -0300 (BRT) Received-SPF: none (coe.ufrj.br: 201.19.161.98 is neither permitted nor denied by domain of jonny.eng.br) client-ip=201.19.161.98; envelope-from=jonny@jonny.eng.br; helo=[201.19.161.98]; Received: from [201.19.161.98] (unknown [201.19.161.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by coe.ufrj.br (Postfix) with ESMTP id 0A5621256BE; Fri, 3 Aug 2007 00:45:29 -0300 (BRT) Message-ID: <46B2A4DC.4080000@jonny.eng.br> Date: Fri, 03 Aug 2007 00:45:32 -0300 From: =?ISO-8859-1?Q?Jo=E3o_Carlos_Mendes_Lu=EDs?= User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Don Lewis References: <200708022120.l72LKRUS001446@gw.catspoiler.org> In-Reply-To: <200708022120.l72LKRUS001446@gw.catspoiler.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: hackers@FreeBSD.org Subject: Re: Problems with rpc.statd and PAE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2007 03:45:37 -0000 Don Lewis wrote: > On 31 Jul, Joo Carlos Mendes Lus wrote: > >> Hi, >> >> Sent this to -questions, but got no answer. Now I'll try -hackers... >> >> I've just configured my first server with 4G RAM. To use it, I had >> to select PAE in kernel config. I was a little bit troubled by it's >> advice not to use modules (is it that critical?), but got it running. >> >> But when it is running on PAE, NFS statd refuses to run: >> >> # /etc/rc.d/nfslocking start >> Starting statd. >> rpc.statd: unable to mmap() status file: Cannot allocate memory >> Segmentation fault >> # >> >> Using strace I found it was trying to mmap the status file, at >> /var/db/statd.status: >> >> open("/var/db/statd.status", O_RDWR) = 10 >> mmap(0, 268435456, PROT_READ|PROT_WRITE, MAP_SHARED, 10, 0) = -1 ENOMEM >> (Cannot allocate memory) >> >> It's really strange to have mmap len = 256M, specially because the >> file is always small. But it works without PAE, and do not work with >> PAE. And it is described in the handbook: >> >> http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/book.html#STATD-MEM-LEAK >> > > I've been seeing this same problem for a long time on an 7.0-CURRENT > i386 machine with 1GB of RAM, and I'm not using PAE. I haven't > discovered any obvious cause for the problem. > It's a production file server, so I cannot make any test today, but this weekend I'll try to recompile statd to use less memory. Is there a good reason to map 256M at once? Jonny -- Joo Carlos Mendes Lus - Networking Engineer - jonny@jonny.eng.br From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 3 04:14:22 2007 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43D6716A41B; Fri, 3 Aug 2007 04:14:22 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id E466513C46E; Fri, 3 Aug 2007 04:14:21 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l734DKTt067828; Thu, 2 Aug 2007 22:13:20 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 02 Aug 2007 22:13:27 -0600 (MDT) Message-Id: <20070802.221327.1783981813.imp@bsdimp.com> To: alex.kovalenko@verizon.net From: "M. Warner Losh" In-Reply-To: <1186101359.846.12.camel@RabbitsDen> References: <20070801.211718.1683324313.imp@bsdimp.com> <46B20F91.5080709@root.org> <1186101359.846.12.camel@RabbitsDen> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 02 Aug 2007 22:13:21 -0600 (MDT) Cc: acpi@FreeBSD.org, freebsd-hackers@FreeBSD.org, gahr@gahr.ch, ume@FreeBSD.org, nate@root.org Subject: Re: [patch] enhance powerd(8) to handle max temperature X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2007 04:14:22 -0000 In message: <1186101359.846.12.camel@RabbitsDen> "Alexandre \"Sunny\" Kovalenko" writes: : On Thu, 2007-08-02 at 10:08 -0700, Nate Lawson wrote: : > M. Warner Losh wrote: : > > In message: <46AE8F78.1060203@root.org> : > > Nate Lawson writes: : > > : Hajimu UMEMOTO wrote: : > > : >>>>>> On Mon, 30 Jul 2007 23:31:33 +0200 : > > : >>>>>> Pietro Cerutti said: : > > : > gahr> My patch is really just a first draft that I wrote in order to have : > > : > gahr> feedbacks on the general idea to implement a temperature controlling : > > : > gahr> system inside powerd, and doesn't implement hysteresis as you noted, and : > > : > gahr> your feedback is that it's not a good idea, which I respect. : > > : > : > > : > It is rather backward, IMHO. I did implement a passive cooling : > > : > feature as an enhancement of powerd(8) like you did, during initial : > > : > phases. Then, I implemented it in our kernel as a result. : > > : : > > : I'll take a look at your patch. Umemoto-san is right in that you really : > > : want the kernel to control cooling. What happens if powerd dies/hangs : > > : and your system burns up? Passive cooling is often a last resort to : > > : keep the system from overheating. : > > : > > I keep getting the system shutting down on my HP by FreeBSD because : > > the temperature exceeds the _CRT value. Maybe there's something wrong : > > with my values, since it happens a lot: : > > : > > hw.acpi.thermal.min_runtime: 0 : > > hw.acpi.thermal.polling_rate: 10 : > > hw.acpi.thermal.user_override: 0 : > > hw.acpi.thermal.tz0.temperature: 0.0C : > > hw.acpi.thermal.tz0.active: -1 : > > hw.acpi.thermal.tz0.passive_cooling: 1 : > > hw.acpi.thermal.tz0.thermal_flags: 0 : > > hw.acpi.thermal.tz0._PSV: 90.0C : > > hw.acpi.thermal.tz0._HOT: -1 : > > hw.acpi.thermal.tz0._CRT: 94.0C : > > hw.acpi.thermal.tz0._ACx: 40.0C -1 -1 -1 -1 -1 -1 -1 -1 -1 : > > : > > Note: temperature is always 0.0C. : > > : > > What can I do to help my situation, if I really want the kernel doing : > > the cooling? : > : > Your embedded controller is timing out. Thus you're getting a bogus : > value for _TMP. : I have sort of picked up this thread in the middle... was it determined : that EC is timing out? The reason for asking is -- I used to have a : laptop where _TMP would just read value from the memory location, which : was never populated anywhere else in ASL. Call to _PSV method would go : figure current temperature and start fan, if necessary. Ugly... : : Dumping ASL (using instructions from handbook) and looking for something : like : : Method (_TMP, 0, NotSerialized) : : might be a real eye opener. : : If you would like me to take a look at your ASL, send it to me privately : -- I've only done it for one laptop, so no claims of the great skill : there, but maybe it is as simple as the other one ;) Method (_TMP, 0, NotSerialized) { If (\_SB.PCI0.LPC0.ECOK ()) { Multiply (\_SB.PCI0.LPC0.EC0.THEM, 0x0A, Local0) Add (Local0, 0x0AAC, Local0) Return (Local0) } Return (DTMP) } From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 3 08:20:08 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8A0C16A41F for ; Fri, 3 Aug 2007 08:20:08 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 5FA8613C465 for ; Fri, 3 Aug 2007 08:20:08 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1IGsOA-0001Ah-GF for freebsd-hackers@freebsd.org; Fri, 03 Aug 2007 10:20:02 +0200 Received: from firewall.andxor.it ([195.223.2.2]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 03 Aug 2007 10:20:02 +0200 Received: from lapo by firewall.andxor.it with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 03 Aug 2007 10:20:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Lapo Luchini Date: Fri, 03 Aug 2007 10:08:48 +0200 Lines: 30 Message-ID: References: <4232198F.5030705@kfu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: firewall.andxor.it User-Agent: Thunderbird 2.0.0.5 (X11/20070721) In-Reply-To: X-Enigmail-Version: 0.95.1 OpenPGP: id=C8F252FB Sender: news Subject: Re: 6to4, stf and shoebox NAT routers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2007 08:20:08 -0000 Hajimu UMEMOTO wrote: > I posted my proposed patch to current@ for review in the past. But, > no one responded. Could you test this? This is for 6-CURRENT at Feb 1. > If it doesn't apply cleanly, please let me know. It applied cleanly to 6.2-STABLE and seems to work perfectly... outbound at least. I have a box at home called cyberx which has static IPv4 but is NATted (and is thus using your patch). The other test box is a server called motoko which has static IPv4 assigned to one of his interfaces directly (no patches here). The wl500g router correctly forwards the protocol 41 packets to cyberx. Pinging from cyberx to motoko (and using tcpdump on both) I can see that: a. cyberx if producing correct IPv4 packets that are from his local NATted address to the real motoko address, but containing a IPv6 packet that contains the '2002:'-encoding of both real IPv4 addresses b. motoko is receiving the echo request correctly c. motoko is sending the echo reply correctly d. cyberx is receiving the echo reply encapsulated in IPv4 packets correctly e. cyberx's stf0 interface IS NOT RECEIVING his IPv6 echo reply f. the 'ping' command thinks that all packets are lost Does you patch address incoming packets too? Can I do some ipfw magic to convince stf to receive also incoming packets with a mismatched IPv4-IPv6 address? Lapo From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 3 19:30:06 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0398E16A417 for ; Fri, 3 Aug 2007 19:30:06 +0000 (UTC) (envelope-from lulf@stud.ntnu.no) Received: from decibel.pvv.ntnu.no (unknown [IPv6:2001:700:300:1900:2e0:81ff:fe2d:e9b2]) by mx1.freebsd.org (Postfix) with ESMTP id 8C3AA13C467 for ; Fri, 3 Aug 2007 19:30:05 +0000 (UTC) (envelope-from lulf@stud.ntnu.no) Received: from tvilling.pvv.ntnu.no ([129.241.210.198] helo=carrot.studby.ntnu.no ident=lulf) by decibel.pvv.ntnu.no with esmtp (Exim 4.60) (envelope-from ) id 1IH2qZ-0003KK-Sp for freebsd-hackers@freebsd.org; Fri, 03 Aug 2007 21:30:04 +0200 Date: Fri, 3 Aug 2007 21:29:33 +0200 From: Ulf Lilleengen To: freebsd-hackers@freebsd.org Message-ID: <20070803192910.GA23699@carrot.studby.ntnu.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) Subject: VFS locking questions X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2007 19:30:06 -0000 Hi, I have a couple of questions regarding VFS, since I'm trying to SMPify the fdescfs code in an effort to get some experience with VFS and freebsd locking... What is really LK_INTERLOCK? When should it be used? When should one acquire it (with VI_LOCK i assume), and what are the "semantics"? Let's say I have a function that should return a locked vnode. I lock the hash-table with a regular mutex. Then, when I traverse the list, I check if the entry is what I look for. If it is, I call VI_LOCK() on the vnode, use vget to increment refcount, and then use vn_lock(vp, LK_EXCLUSIVE...) to lock the vnode before the function returns. Is this correct behaviour? The LK_INTERLOCK bothers me a bit, because I'm not 100% sure on how it works. -- Ulf Lilleengen From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 3 19:57:53 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94EA016A418 for ; Fri, 3 Aug 2007 19:57:53 +0000 (UTC) (envelope-from joseph.koshy@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.238]) by mx1.freebsd.org (Postfix) with ESMTP id 6378913C47E for ; Fri, 3 Aug 2007 19:57:53 +0000 (UTC) (envelope-from joseph.koshy@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so373185nzf for ; Fri, 03 Aug 2007 12:57:52 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=XOhBatTZHc+316begX2udUdAGDmbaAxonNwqcy86KOAzhaWuUMeVd/MgG22PubVmWzyJaqbt9d1LHiP2NSYHvcODS8gmiCpqqoSsYd0GaPabYiPmssPp3abPrCg3Z4Eq7SmN9/RfDGOohW0GLGR5/oK46MA1yy3D8skmCJyJfC4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=RV6VIsLCxysZEc5NO3eujtol4flBp0xfGyXYR76GPk/jgQofoNVmfjqZOnn+h5x9M+xbiuGRQ0d3nAe0KepYmSMMHT0R920izmLoFhP0NYcXWWNOeCYB06RTWxNJK8gSM6l7oD4cIf9lEnPk+da3Yg9xeA23AnfKmqtZ2R8g1X0= Received: by 10.142.240.9 with SMTP id n9mr147310wfh.1186169504285; Fri, 03 Aug 2007 12:31:44 -0700 (PDT) Received: by 10.143.158.6 with HTTP; Fri, 3 Aug 2007 12:31:44 -0700 (PDT) Message-ID: <84dead720708031231n45533e41uba5ffa6cbe252c1c@mail.gmail.com> Date: Fri, 3 Aug 2007 19:31:44 +0000 From: "Joseph Koshy" To: "freebsd-current@freebsd.org" , "FreeBSD Hackers" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: [CFT] Callchain capture in PmcTools X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2007 19:57:53 -0000 I'm pleased to offer a patch implementing callchain capture for hwpmc(4) for review. Test reports, comments etc. are welcome. Regards, Koshy ============================================= >>>> Summary <<<< hwpmc(4): * hwpmc(4) can now walk kernel and user stacks and capture caller information for subsequent analysis by pmcstat(8). * An additional flag in the API `PMC_F_CALLCHAIN' controls whether a PMC will capture a callchain. * Tunable kern.hwpmc.callchaindepth controls the maximum depth to which stacks are walked. The default is `8'. pmcstat(8): * pmcstat(8) now defaults to allocating PMCs that capture callchains. Use the new `-N' option (a toggle) to turn this off. * The '-g' option (gmon.out generation) now writes call arc data for subsequent analysis by gprof(1). * The new '-G' option generates system-wide callchain summaries. The new '-z maxprintdepth' option restricts the depth of the the callchain summary. >>>> Patch Information <<<< 1) Download the patch % fetch \ http://people.freebsd.org/~jkoshy/download/pmctools-callgraph-patch.gz MD5 (pmctools-callgraph-patch.gz) = 632185755d1004e82c3d2bbc69827307 2) Apply using patch -p1 against a recent (Aug 3rd) -current: % cvs checkout -P src % cd src; gzip -dc pmctools-callgraph-patch.gz | patch -p1 3) Build and update the kernel+world. You will need to add 'options HWPMC_HOOKS' to your kernel config before you can use hwpmc(4). % (follow the usual procedure, see src/UPDATING) >>>> Using the patch <<<< 1) Load hwpmc into the kernel % kldload hwpmc 2) Collect measurements % pmcstat -S instructions -O logfile etc. 3) Use option -g to generate gprof(1) style 'gmon.out' files. % pmcstat -R logfile -g % gprof /boot/kernel/kernel /kernel.gmon 4) Use option -G to generate a callchain summary: % pmcstat -R logfile -G summaryfile % vi summaryfile >>>> Known Bugs with this patch <<<< 1) P4 HTT lockup Symptom: Lockup under load of Pentium 4 machines with HTT enabled. Workaround: Restrict sampling to one CPU using the '-c' option: # pmcstat -c 0 -S instructions -O logfile 2) pmcstat(8) stuck in an unkillable state. Symptom: When interrupted, pmcstat(8) gets stuck sleeping on wait channel "pmcctx". Workaround: Use the '-n' option to reduce sampling frequency: # pmcstat -n 1048576 -S instructions ...other options... Other (older) known bugs are listed at http://wiki.freebsd.org/PmcTools. >>>> Other Notes <<<< pmcstat(8) works best with unstripped executables (e.g. set "STRIP=" in /etc/make.conf). On the amd64 the heuristic used to determine the frame pointer given a sampled PC address is not very good and can at times result in the next to topmost frame being missed in the sampled callchain. >>>> Thanks <<<< - To the users of PmcTools in the FreeBSD community for their feedback, encouragement and support. - To the FreeBSD Foundation and Google Inc., for supporting this work. ============================================= From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 4 07:36:01 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EF4F16A420 for ; Sat, 4 Aug 2007 07:36:01 +0000 (UTC) (envelope-from artifact.one@googlemail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.239]) by mx1.freebsd.org (Postfix) with ESMTP id 2C78B13C4CC for ; Sat, 4 Aug 2007 07:36:01 +0000 (UTC) (envelope-from artifact.one@googlemail.com) Received: by wx-out-0506.google.com with SMTP id i29so764911wxd for ; Sat, 04 Aug 2007 00:36:00 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=googlemail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=YFa9mVwqI00+6pTil2n7HB3f4suE7WeR8p/aDuECFz5pTGi0rz+X9w7oAYEc9I5L9tzwyCg6oTAfWlVZnyl8fFqOr3bWorzznQzBFklBmtgTygNaQKf1eJvJJ2bMegush66tYBZuPlwGGw6t6LAxkdrb/zMe3fuAxVKumuI/fJI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=I4XXSzOm7kmHO1l8gETIAmPkNsQDaTYcGC8eveRlcqPuugq7d3yxJtU7EtC4g1/1RjJdUDjcDCDKwTfzDDPagWxhOU2QnJlbYMMn2TXmt7x75AWMa40gjEF7J94DtK/dfx+wdbsAZZ+chNzsjS7uQotwDPFLdB+Vo1mxPB+d82Y= Received: by 10.90.34.3 with SMTP id h3mr3732028agh.1186211413027; Sat, 04 Aug 2007 00:10:13 -0700 (PDT) Received: by 10.90.51.1 with HTTP; Sat, 4 Aug 2007 00:10:13 -0700 (PDT) Message-ID: <8e96a0b90708040010r3980d5ffj709e16058740955a@mail.gmail.com> Date: Sat, 4 Aug 2007 08:10:13 +0100 From: "mal content" To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: CPU activity as percentage. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2007 07:36:01 -0000 Hello. I'm trying to write a function sys_cpu_percent() that returns the current cpu usage as a percentage. I currently have this: double sys_cpu_percent() { long cp_time[CPUSTATES]; double used; double total; size_t len = sizeof(cp_time); if (sysctlbyname("kern.cp_time", cp_time, &len, 0, 0) < 0) return 0; used = cp_time[CP_USER] + cp_time[CP_NICE] + cp_time[CP_SYS] + cp_time[CP_INTR]; total = cp_time[CP_USER] + cp_time[CP_NICE] + cp_time[CP_SYS] + cp_time[CP_INTR] + cp_time[CP_IDLE]; return (used / total) * 100; } However the function always returns ~9%, even when running a cpu intensive task in the background. Am I missing something obvious here? Is there a better way of doing this? My system is uniprocessor, if that makes any difference. thanks, MC From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 4 07:53:03 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7497916A418 for ; Sat, 4 Aug 2007 07:53:03 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mx1.freebsd.org (Postfix) with ESMTP id 1F4C513C457 for ; Sat, 4 Aug 2007 07:53:02 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.14.1/8.14.1) with ESMTP id l747r0WA095567; Sat, 4 Aug 2007 17:53:00 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.14.1/8.14.1/Submit) id l747r01l095566; Sat, 4 Aug 2007 17:53:00 +1000 (EST) (envelope-from peter) Date: Sat, 4 Aug 2007 17:53:00 +1000 From: Peter Jeremy To: mal content Message-ID: <20070804075300.GO1262@turion.vk2pj.dyndns.org> References: <8e96a0b90708040010r3980d5ffj709e16058740955a@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nYySOmuH/HDX6pKp" Content-Disposition: inline In-Reply-To: <8e96a0b90708040010r3980d5ffj709e16058740955a@mail.gmail.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-hackers@freebsd.org Subject: Re: CPU activity as percentage. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2007 07:53:03 -0000 --nYySOmuH/HDX6pKp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Aug-04 08:10:13 +0100, mal content wr= ote: > if (sysctlbyname("kern.cp_time", cp_time, &len, 0, 0) < 0) return 0; kern.cp_time returns a set of counters that are incrememted at kern.clockrate{stathz}. To calculate CPU activity, you need to look at the change in counters over a defined period. --=20 Peter Jeremy --nYySOmuH/HDX6pKp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGtDBc/opHv/APuIcRAsMfAJ9wXMh7noNvEJBpkC7dB4h/Fyw98ACeMvPq yU3T9lUBZExQxvw0gRN61sk= =4hUU -----END PGP SIGNATURE----- --nYySOmuH/HDX6pKp-- From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 4 08:49:34 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EEFF16A46B for ; Sat, 4 Aug 2007 08:49:34 +0000 (UTC) (envelope-from artifact.one@googlemail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.239]) by mx1.freebsd.org (Postfix) with ESMTP id EC5D613C469 for ; Sat, 4 Aug 2007 08:49:33 +0000 (UTC) (envelope-from artifact.one@googlemail.com) Received: by wx-out-0506.google.com with SMTP id i29so770234wxd for ; Sat, 04 Aug 2007 01:49:33 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=googlemail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bNEd5rgGh+3TWcQ8FF3hIWFOeGp3ltPxfalVvlW5O4i6RJ1YD8vuB1c5nLjQbjJT+Qf6HkvZ8Mim13iNO+xjy/WEH66TR2roXVLsJ/SWbfwIUOGPJeIVTV98LEjSYKaQ1PufuDjaP9d2qoeA7tHmd09fU0UJtHvAD+3xP8orlss= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=E9hiQG4In0R/QD7qi3+FdwuaAt+bC5pd8Z08TCUDb3OIxQa3AKdpIBZ1hLL5dxqKEGbYBKV/g+/J+3WVyDVxbibMo8BhFEdiPlvElHv1WkN9hRqBUWs4NMgoYVSFPLWXqYeZ7KAcuVNS/zcy7egBsJ2nq8Wi+fYigs2VQuIf1Qs= Received: by 10.90.27.13 with SMTP id a13mr3755622aga.1186217372889; Sat, 04 Aug 2007 01:49:32 -0700 (PDT) Received: by 10.90.51.1 with HTTP; Sat, 4 Aug 2007 01:49:32 -0700 (PDT) Message-ID: <8e96a0b90708040149n35b9e948xeed06ccda962133@mail.gmail.com> Date: Sat, 4 Aug 2007 09:49:32 +0100 From: "mal content" To: "Peter Jeremy" In-Reply-To: <20070804075300.GO1262@turion.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8e96a0b90708040010r3980d5ffj709e16058740955a@mail.gmail.com> <20070804075300.GO1262@turion.vk2pj.dyndns.org> Cc: freebsd-hackers@freebsd.org Subject: Re: CPU activity as percentage. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2007 08:49:34 -0000 On 04/08/07, Peter Jeremy wrote: > On 2007-Aug-04 08:10:13 +0100, mal content wrote: > > if (sysctlbyname("kern.cp_time", cp_time, &len, 0, 0) < 0) return 0; > > kern.cp_time returns a set of counters that are incrememted at > kern.clockrate{stathz}. To calculate CPU activity, you need to look > at the change in counters over a defined period. *ahem* That would explain it then. thanks, MC