From owner-freebsd-stable@FreeBSD.ORG Sun Jul 23 10:33:03 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2434C16A4DA for ; Sun, 23 Jul 2006 10:33:03 +0000 (UTC) (envelope-from thompsa@freebsd.org) Received: from grunt15.ihug.co.nz (grunt15.ihug.co.nz [203.109.254.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBA4643D49 for ; Sun, 23 Jul 2006 10:33:02 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: from 203-109-251-39.static.bliink.ihug.co.nz (heff.fud.org.nz) [203.109.251.39] by grunt15.ihug.co.nz with esmtp (Exim 3.35 #1 (Debian)) id 1G4bGf-0001CV-00; Sun, 23 Jul 2006 22:33:01 +1200 Received: by heff.fud.org.nz (Postfix, from userid 1001) id 4A3041CC22; Sun, 23 Jul 2006 22:33:06 +1200 (NZST) Date: Sun, 23 Jul 2006 22:33:06 +1200 From: Andrew Thompson To: stable@freebsd.org Message-ID: <20060723103306.GB53338@heff.fud.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 Cc: Subject: interface announcement MFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jul 2006 10:33:03 -0000 Hi, I would quite like to MFC the autobridge feature but it depends on this change, http://lists.freebsd.org/pipermail/cvs-src/2006-May/064529.html I cant see it being a problem MFCing this to stable as the existing devd announcement still exists, it just adds another that includes pseudo ones too. Does anyone forsee any problems? Andrew From owner-freebsd-stable@FreeBSD.ORG Sun Jul 23 11:17:47 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A928616A4EB for ; Sun, 23 Jul 2006 11:17:47 +0000 (UTC) (envelope-from kkowalik@uci.agh.edu.pl) Received: from galaxy.agh.edu.pl (galaxy.agh.edu.pl [149.156.96.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54EF443D49 for ; Sun, 23 Jul 2006 11:17:46 +0000 (GMT) (envelope-from kkowalik@uci.agh.edu.pl) Received: by galaxy.agh.edu.pl (Postfix, from userid 1001) id 49D791012; Sun, 23 Jul 2006 13:17:45 +0200 (CEST) Date: Sun, 23 Jul 2006 13:17:45 +0200 From: Krzysztof Kowalik To: James O'Gorman Message-ID: <20060723111745.GA27510@uci.agh.edu.pl> References: <44C26D28.4000304@inoc.net> <20060722191631.GB122@netinertia.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060722191631.GB122@netinertia.co.uk> Cc: freebsd-stable@freebsd.org Subject: Re: Sun X86 servers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jul 2006 11:17:47 -0000 James O'Gorman wrote: > Actually I'd be quite interested to know how they perform as well. I've > been contemplating the new Ultra 20 workstation to try and learn Solaris > on (but be able to run FreeBSD as well). For the Ultra 20, I can say it works pretty well with RELENG_6_1 (32-bit). % uname -mrs FreeBSD 6.1-PRERELEASE i386 % uptime 1:13PM up 121 days, 1 min, 2 users, load averages: 0,04 0,01 0,00 SATA, sound[1], USB, DVD burner, the weird nVidia's NIC, and the graphics card work without issues (so far). I do, however, added the second NIC (Intel PRO 10/100) as I don't exactly trust the nve(4) driver yet (even though it seems to work on this particular motherboard). There is no high load on the machine, just a workstation with X.org and KDE. [1] snd_ich -- Krzysztof Kowalik | () ASCII Ribbon Campaign Computer Center, AGH UST | /\ Support plain text e-mail From owner-freebsd-stable@FreeBSD.ORG Sun Jul 23 12:59:36 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9E8416A4DA for ; Sun, 23 Jul 2006 12:59:36 +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 2BBC443D53 for ; Sun, 23 Jul 2006 12:59:36 +0000 (GMT) (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 3A45046C5E; Sun, 23 Jul 2006 08:59:35 -0400 (EDT) Date: Sun, 23 Jul 2006 13:59:35 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Stephen Montgomery-Smith In-Reply-To: <44BEBA2F.3060403@math.missouri.edu> Message-ID: <20060723135739.M60996@fledge.watson.org> References: <44BEBA2F.3060403@math.missouri.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable Subject: Re: Panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jul 2006 12:59:37 -0000 On Wed, 19 Jul 2006, Stephen Montgomery-Smith wrote: > I just had a kernel panic. This happened seconds after I started a reboot > using alt-ctl-del, at about the time just after it it said it was writing > the entropy file. > > Here is the kernel config file, the results of the dump, and dmesg. Do you > want anything else? I hope this info helps. Thanks for this report. I'm very interested in tracking this down, but need to think about it some, as the code paths in question are quite complex. Could you: (1) Submit a PR for this, including all the below information. Forward the PR receipt to me once submitted so I can grab ownership. (2) See if you can easily reproduce the problem. (3) Keep the core dump around for a bit longer if I need to ask you to refer back to it. I've recently fixed a number of bugs in the UNIX domain socket code and merged those fixes to 7-CURRENT. My first thought was that this is a symptom of one of those bugs, but I'm now leaning against that, so need to read code for a bit. Thanks, Robert N M Watson Computer Laboratory University of Cambridge > > include GENERIC > ident HUB2 > nooption INET6 > options SMP > device atapicam > makeoptions DEBUG=-g > > > hub2# cd /usr/obj/usr/src/sys/HUB2/ > hub2# kgdb kernel.debug /var/crash/vmcore.196 > [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>. > <118>. > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x24 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc06acdc8 > stack pointer = 0x28:0xeadd7ae0 > frame pointer = 0x28:0xeadd7c68 > 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 = 479 (mountd) > trap number = 12 > panic: page fault > cpuid = 0 > Uptime: 17h48m47s > Dumping 3071 MB (2 chunks) > chunk 0: 1MB (158 pages) ... ok > chunk 1: 3071MB (786126 pages) 3055 3039 3023 3007 2991 2975 2959 2943 2927 > 2911 2895 2879 2863 2847 2831 2815 2799 2783 2767 2751 2735 2719 2703 2687 > 2671 2655 2639 2623 2607 2591 2575 2559 2543 2527 2511 2495 2479 2463 2447 > 2431 2415 2399 2383 2367 2351 2335 2319 2303 2287 2271 2255 2239 2223 2207 > 2191 2175 2159 2143 2127 2111 2095 2079 2063 2047 2031 2015 1999 1983 1967 > 1951 1935 1919 1903 1887 1871 1855 1839 1823 1807 1791 1775 1759 1743 1727 > 1711 1695 1679 1663 1647 1631 1615 1599 1583 1567 1551 1535 1519 1503 1487 > 1471 1455 1439 1423 1407 1391 1375 1359 1343 1327 1311 1295 1279 1263 1247 > 1231 1215 1199 1183 1167 1151 1135 1119 1103 1087 1071 1055 1039 1023 1007 > 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767 751 735 719 703 > 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 447 431 415 399 > 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 > 63 47 31 15 > > #0 doadump () at pcpu.h:165 > 165 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); > (kgdb) list 0xc06acdc8 > Function "0xc06acdc8" not defined. > (kgdb) list *0xc06acdc8 > 0xc06acdc8 is in unp_connect (/usr/src/sys/kern/uipc_usrreq.c:992). > 987 goto bad2; > 988 } > 989 unp = sotounpcb(so); > 990 unp2 = sotounpcb(so2); > 991 unp3 = sotounpcb(so3); > 992 if (unp2->unp_addr != NULL) { > 993 bcopy(unp2->unp_addr, sa, > unp2->unp_addr->sun_len); > 994 unp3->unp_addr = (struct sockaddr_un *) sa; > 995 sa = NULL; > 996 } > (kgdb) backtrace > #0 doadump () at pcpu.h:165 > #1 0xc0668736 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 > #2 0xc0668a5d in panic (fmt=0xc08ae2d2 "%s") > at /usr/src/sys/kern/kern_shutdown.c:565 > #3 0xc085895c in trap_fatal (frame=0xeadd7aa0, eva=36) > at /usr/src/sys/i386/i386/trap.c:836 > #4 0xc085869b in trap_pfault (frame=0xeadd7aa0, usermode=0, eva=36) > at /usr/src/sys/i386/i386/trap.c:744 > #5 0xc08582d5 in trap (frame= > {tf_fs = -814350328, tf_es = -354615256, tf_ds = -1066794968, tf_edi = > 0, tf_esi = -926606416, tf_ebp = -354583448, tf_isp = -354583860, tf_ebx = > -928231144, tf_edx = -927683016, tf_ecx = 4, tf_eax = -814325048, tf_trapno = > 12, tf_err = 0, tf_eip = -1066742328, tf_cs = 32, tf_eflags = 66178, tf_esp = > -926077568, tf_ss = -927683016}) at /usr/src/sys/i386/i386/trap.c:434 > #6 0xc08452ea in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > #7 0xc06acdc8 in unp_connect (so=0xc8cc1858, nam=0xcef36b60, td=0xc883f480) > at /usr/src/sys/kern/uipc_usrreq.c:991 > #8 0xc06ab308 in uipc_connect (so=0xc8cc1858, nam=0xcef36b60, td=0xc883f480) > at /usr/src/sys/kern/uipc_usrreq.c:232 > #9 0xc06a295e in soconnect (so=0xc8cc1858, nam=0xcef36b60, td=0xc883f480) > at /usr/src/sys/kern/uipc_socket.c:558 > #10 0xc06a82c8 in kern_connect (td=0xc883f480, fd=3, sa=0xcef36b60) > at /usr/src/sys/kern/uipc_syscalls.c:536 > ---Type to continue, or q to quit--- > #11 0xc06a822f in connect (td=0xc883f480, uap=0xeadd7d04) > at /usr/src/sys/kern/uipc_syscalls.c:505 > #12 0xc0858ca3 in syscall (frame= > {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 1, tf_esi = 134598656, > tf_ebp = -1077942152, tf_isp = -354583196, tf_ebx = -2011836128, tf_edx = -1, > tf_ecx = -2011836128, tf_eax = 98, tf_trapno = 0, tf_err = 2, tf_eip = > -2012021137, tf_cs = 51, tf_eflags = 582, tf_esp = -1077942500, tf_ss = 59}) > at /usr/src/sys/i386/i386/trap.c:981 > #13 0xc084533f in Xint0x80_syscall () at > /usr/src/sys/i386/i386/exception.s:200 > #14 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) > > > > > > Copyright (c) 1992-2006 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD 6.1-STABLE #0: Tue Jul 11 19:27:52 CDT 2006 > stephen@hub2.montlan:/usr/obj/usr/src/sys/HUB2 > ACPI APIC Table: > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Xeon(TM) CPU 3.40GHz (3391.52-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf41 Stepping = 1 > > Features=0xbfebfbff > Features2=0x649d> > AMD Features=0x20000000 > Logical CPUs per core: 2 > real memory = 3221020672 (3071 MB) > avail memory = 3142680576 (2997 MB) > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu2 (AP): APIC ID: 6 > cpu3 (AP): APIC ID: 7 > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 24-47 on motherboard > kbd1 at kbdmux0 > ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) > acpi0: on motherboard > acpi0: Power Button (fixed) > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > cpu0: on acpi0 > acpi_throttle0: on cpu0 > cpu1: on acpi0 > acpi_throttle1: on cpu1 > acpi_throttle1: failed to attach P_CNT > device_attach: acpi_throttle1 attach returned 6 > cpu2: on acpi0 > cpu3: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pci0: at device 0.1 (no driver attached) > pcib1: at device 2.0 on pci0 > pci1: on pcib1 > pcib2: at device 3.0 on pci0 > pci2: on pcib2 > pcib3: at device 4.0 on pci0 > pci3: on pcib3 > nvidia0: port 0xcf80-0xcfff mem > 0xfb000000-0xfbffffff,0xd0000000-0xdfffffff,0xfa000000-0xfaffffff at device > 0.0 on pci3 > nvidia0: [GIANT-LOCKED] > pcib4: at device 28.0 on pci0 > pci4: on pcib4 > em0: port > 0xdf80-0xdfbf mem 0xfcfe0000-0xfcffffff,0xfcfc0000-0xfcfdffff irq 24 at > device 2.0 on pci4 > em0: Ethernet address: 00:0e:0c:63:34:14 > twe0: <3ware Storage Controller. Driver version 1.50.01.002> port > 0xdf00-0xdf0f mem 0xfc000000-0xfc7fffff irq 25 at device 3.0 on pci4 > twe0: [GIANT-LOCKED] > twe0: 2 ports, Firmware FE8S 1.05.00.068, BIOS BE7X 1.08.00.048 > uhci0: port 0xbf00-0xbf1f irq 16 at device > 29.0 on pci0 > uhci0: [GIANT-LOCKED] > usb0: on uhci0 > usb0: USB revision 1.0 > uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub0: 2 ports with 2 removable, self powered > uhci1: port 0xbf80-0xbf9f irq 19 at device > 29.1 on pci0 > uhci1: [GIANT-LOCKED] > usb1: on uhci1 > usb1: USB revision 1.0 > uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub1: 2 ports with 2 removable, self powered > pci0: at device 29.4 (no driver attached) > pci0: at device 29.5 (no driver > attached) > ehci0: mem 0xf9effc00-0xf9efffff irq 23 at > device 29.7 on pci0 > ehci0: [GIANT-LOCKED] > usb2: EHCI version 1.0 > usb2: companion controllers, 2 ports each: usb0 usb1 > usb2: on ehci0 > usb2: USB revision 2.0 > uhub2: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 > uhub2: 4 ports with 4 removable, self powered > pcib5: at device 30.0 on pci0 > pci5: on pcib5 > em1: port > 0xee80-0xeebf mem 0xfeba0000-0xfebbffff irq 16 at device 3.0 on pci5 > em1: Ethernet address: 00:0e:0c:3d:e1:6f > pcm0: port 0xee00-0xee3f irq 21 at device 4.0 on pci5 > pcm0: es1370_wrcodec: timed out > pcm0: > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 > ata0: on atapci0 > ata1: on atapci0 > pci0: at device 31.3 (no driver attached) > acpi_button0: on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: model IntelliMouse Explorer, device ID 4 > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > sio0: type 16550A > sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 > sio1: type 16550A > fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on > acpi0 > fdc0: [FAST] > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > pmtimer0 on isa0 > orm0: at iomem > 0xcf000-0xcffff,0xd0000-0xd0fff,0xd1000-0xd1fff,0xd2800-0xd37ff on isa0 > ppc0: parallel port not found. > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > ugen0: American Power Conversion Back-UPS RS 1500 FW:8.g9 .D USB FW:g9, rev > 1.10/1.06, addr 2 > Timecounters tick every 1.000 msec > acd0: DMA limited to UDMA33, controller found non-ATA66 cable > acd0: DVDR at ata0-master UDMA33 > twed0: on twe0 > twed0: 228944MB (468879104 sectors) > SMP: AP CPU #3 Launched! > SMP: AP CPU #1 Launched! > SMP: AP CPU #2 Launched! > cd0 at ata0 bus 0 target 0 lun 0 > cd0: Removable CD-ROM SCSI-0 device > cd0: 33.000MB/s transfers > cd0: Attempt to query device size failed: NOT READY, Medium not present > Trying to mount root from ufs:/dev/twed0s3a > WARNING: / was not properly dismounted > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Sun Jul 23 21:39:00 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D0BBB16A4E0; Sun, 23 Jul 2006 21:39:00 +0000 (UTC) (envelope-from gmenhennitt@optusnet.com.au) Received: from mail23.syd.optusnet.com.au (mail23.syd.optusnet.com.au [211.29.133.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7AEEC43D6D; Sun, 23 Jul 2006 21:38:57 +0000 (GMT) (envelope-from gmenhennitt@optusnet.com.au) Received: from [203.2.73.8] (c220-237-136-178.mckinn1.vic.optusnet.com.au [220.237.136.178]) by mail23.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k6NLcsIe006051; Mon, 24 Jul 2006 07:38:54 +1000 Message-ID: <44C3EC68.6050802@optusnet.com.au> Date: Mon, 24 Jul 2006 07:38:48 +1000 From: Graham Menhennitt User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Robert Watson References: <44BEBA2F.3060403@math.missouri.edu> <20060723135739.M60996@fledge.watson.org> In-Reply-To: <20060723135739.M60996@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable Subject: Re: Panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jul 2006 21:39:00 -0000 On Wed, 19 Jul 2006, Stephen Montgomery-Smith wrote: >> I just had a kernel panic. This happened seconds after I started a >> reboot using alt-ctl-del, at about the time just after it it said it >> was writing the entropy file. >> >> Here is the kernel config file, the results of the dump, and dmesg. >> Do you want anything else? I hope this info helps. > >> Fatal trap 12: page fault while in kernel mode >> current process = 479 (mountd) I have the same panic reproducibly. Shutting off nfs_server_enable (i.e. mountd) in rc.conf prevents it. This is with 6-STABLE cvsupped yesterday. I'll get some more info and follow up the PR. Graham From owner-freebsd-stable@FreeBSD.ORG Mon Jul 24 11:21:01 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA96E16A4DA for ; Mon, 24 Jul 2006 11:21:01 +0000 (UTC) (envelope-from mb@tns.cz) Received: from pha.tns.cz (pha.tns.cz [85.207.56.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 201D743D5F for ; Mon, 24 Jul 2006 11:20:59 +0000 (GMT) (envelope-from mb@tns.cz) Received: from pha.tns.cz (localhost [127.0.0.1]) by pha.tns.cz (Postfix) with ESMTP id 45E7B273509 for ; Mon, 24 Jul 2006 13:20:58 +0200 (CEST) Received: by pha.tns.cz with ESMTP id 49H5D340000WWYQBDFW; Mon, 24 Jul 2006 13:20:57 +0200 (CEST) Date: Mon, 24 Jul 2006 13:20:56 +0200 From: Martin Beran To: freebsd-stable@freebsd.org Message-ID: <20060724112056.GA8744@mb.tns.cz> References: <20060721010559.GB23227@insomnia.benzedrine.cx> <1153410809.1126.66.camel@genius.i.cz> <200607210205.51614.max@love2party.net> <1153410809.1126.66.camel@genius.i.cz> <44BFA8F9.8010403@jellydonut.org> <1153433881.1173.3.camel@genius.i.cz> <1153410809.1126.66.camel@genius.i.cz> <44BFA8F9.8010403@jellydonut.org> <1153410809.1126.66.camel@genius.i.cz> <20060721161522.GA10111@mb.tns.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060721161522.GA10111@mb.tns.cz> User-Agent: Mutt/1.4.2.1i X-Kernun-Loop-Info: 1 Subject: Re: Kernel panic with PF X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 11:21:01 -0000 On Fri, Jul 21, 2006 at 02:15:33PM +0000, Martin Beran wrote: > I think this is not the case. The proxy uses either DIOCXBEGIN + DIOCBEGINADDRS > + DIOCADDADDR + DIOCADDRULE + DIOCXCOMMIT or > DIOCCHANGERULE(PF_CHANGE_GET_TICKET) + DIOCBEGINADDRS + DIOCADDADDR > + DIOCCHANGERULE(PF_CHANGE_ADD_TAIL). The first method is used in the first > call to create the ruleset. In the subsequent call, the second method is used > to modify the ruleset. I did an experiment - repeated adding and deleting rules in two processes, as fast as possible. I expected EBUSY from time to time, but I also received EINVAL indeterministically. It seems to me that when the PF ioctl() is called simultaneously by two processes, it sometimes retuns EINVAL, although it sould be possible to either complete the operation (parameters are correct), or return EBUSY. -- Martin Beran Senior Developer Trusted Network Solutions, a.s. mobil: +420 603 820 932 [ www.tns.cz ] From owner-freebsd-stable@FreeBSD.ORG Mon Jul 24 13:27:42 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B725C16A4E2 for ; Mon, 24 Jul 2006 13:27:42 +0000 (UTC) (envelope-from isn-bounces@attrition.org) Received: from forced.attrition.org (forced.attrition.org [66.80.146.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72A7043D45 for ; Mon, 24 Jul 2006 13:27:42 +0000 (GMT) (envelope-from isn-bounces@attrition.org) Received: from forced.attrition.org (localhost [127.0.0.1]) by forced.attrition.org (Postfix) with ESMTP id A4C3879AFE for ; Mon, 24 Jul 2006 09:24:06 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: isn-bounces@attrition.org To: stable@freebsd.org Message-ID: Date: Mon, 24 Jul 2006 09:24:00 -0400 Precedence: bulk X-BeenThere: isn@attrition.org X-Mailman-Version: 2.1.7rc1 X-List-Administrivia: yes Sender: isn-bounces@attrition.org Errors-To: isn-bounces@attrition.org Cc: Subject: Your message to ISN awaits moderator approval X-BeenThere: freebsd-stable@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 13:27:42 -0000 Your mail to 'ISN' with the subject Returned mail: Data format error Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://www.attrition.org/mailman/confirm/isn/b9d793d3f30dd3434a8e7b542cb9f55d57583ca8 From owner-freebsd-stable@FreeBSD.ORG Mon Jul 24 14:05:44 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A76FF16A4DD; Mon, 24 Jul 2006 14:05:44 +0000 (UTC) (envelope-from gmenhennitt@optusnet.com.au) Received: from mail25.syd.optusnet.com.au (mail25.syd.optusnet.com.au [211.29.133.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A84F43D6E; Mon, 24 Jul 2006 14:05:43 +0000 (GMT) (envelope-from gmenhennitt@optusnet.com.au) Received: from [203.2.73.8] (c220-237-136-178.mckinn1.vic.optusnet.com.au [220.237.136.178]) by mail25.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k6OE5f52024945; Tue, 25 Jul 2006 00:05:41 +1000 Message-ID: <44C4D3B0.7090705@optusnet.com.au> Date: Tue, 25 Jul 2006 00:05:36 +1000 From: Graham Menhennitt User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: freebsd-stable References: <44BEBA2F.3060403@math.missouri.edu> <20060723135739.M60996@fledge.watson.org> <44C3EC68.6050802@optusnet.com.au> In-Reply-To: <44C3EC68.6050802@optusnet.com.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Robert Watson Subject: Re: Panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 14:05:44 -0000 Graham Menhennitt wrote: > On Wed, 19 Jul 2006, Stephen Montgomery-Smith wrote: > >>> I just had a kernel panic. This happened seconds after I started a >>> reboot using alt-ctl-del, at about the time just after it it said it >>> was writing the entropy file. >>> >>> Here is the kernel config file, the results of the dump, and dmesg. >>> Do you want anything else? I hope this info helps. >>> >>> Fatal trap 12: page fault while in kernel mode >>> current process = 479 (mountd) >>> > > I have the same panic reproducibly. Shutting off nfs_server_enable (i.e. > mountd) in rc.conf prevents it. This is with 6-STABLE cvsupped > yesterday. I'll get some more info and follow up the PR. > I rebuilt my kernel (to enable debugging) and now it doesn't panic. So it seems that an old kernel (from around the end of May) with a new mountd (from Sunday) will crash. But a new kernel with a new mountd won't. Graham From owner-freebsd-stable@FreeBSD.ORG Mon Jul 24 15:14:35 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C72A16A4DF for ; Mon, 24 Jul 2006 15:14:35 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD3CE43D4C for ; Mon, 24 Jul 2006 15:14:34 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (xqvcpa@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id k6OFERKe052697 for ; Mon, 24 Jul 2006 17:14:32 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id k6OFERos052696; Mon, 24 Jul 2006 17:14:27 +0200 (CEST) (envelope-from olli) Date: Mon, 24 Jul 2006 17:14:27 +0200 (CEST) Message-Id: <200607241514.k6OFERos052696@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG In-Reply-To: <20060721140005.5365e4b7@mablung.edhellond.fbi.ie> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.0-20051224 ("Ronay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Mon, 24 Jul 2006 17:14:33 +0200 (CEST) Cc: Subject: Re: filesystem full error with inumber X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 15:14:35 -0000 Nobody else has answered so far, so I try to give it a shot ... Feargal Reilly wrote: > The following error is being logged in /var/log/messages on > FreeBSD 5.4: > > Jul 21 09:58:44 arwen kernel: pid 615 (postgres), uid 1001 > inumber 6166128 on /data0: filesystem full > > However, this does not appear to be a case of being out of disk > space, or running out of inodes: The "filesystem full" error can happen in three cases: 1. The file system is running out of data space. 2. The file system is running out of inodes. 3. The file system is running out of non-fragmented blocks. The third case can only happen on extremely fragmented file systems which happens very rarely, but maybe it's a possible cause of your problem. > kern.maxfiles: 20000 > kern.openfiles: 3582 Those have nothing to do with "filesystem full". > Looking again at dumpfs, it appears to say that this is formatted > with a block size of 8K, and a fragment size of 2K, but > tuning(7) says: [...] > Reading this makes me think that when this server was installed, > the block size was dropped from the 16K default to 8K for > performance reasons, but the fragment size was not modified > accordingly. > > Would this be the root of my problem? I think a bsize/fsize ratio of 4/1 _should_ work, but it's not widely used, so there might be bugs hidden somewhere. > If so, is my only option > to back everything up and newfs the disk, or is there something > else I can do that will minimise my downtime? If you need to change bsize and/or fsize, then you will have to backup and newfs, I'm afraid. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." -- Doug Gwyn From owner-freebsd-stable@FreeBSD.ORG Mon Jul 24 15:48:55 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA42E16A4E0 for ; Mon, 24 Jul 2006 15:48:55 +0000 (UTC) (envelope-from feargal@helgrim.com) Received: from mail17.svc.cra.dublin.eircom.net (mail17.svc.cra.dublin.eircom.net [159.134.118.216]) by mx1.FreeBSD.org (Postfix) with SMTP id 4CA3843D5E for ; Mon, 24 Jul 2006 15:48:40 +0000 (GMT) (envelope-from feargal@helgrim.com) Received: (qmail 31767 messnum 5074851 invoked from network[82.141.233.46/unknown]); 24 Jul 2006 15:48:38 -0000 Received: from unknown (HELO alatar.edhellond.fbi.ie) (82.141.233.46) by mail17.svc.cra.dublin.eircom.net (qp 31767) with SMTP; 24 Jul 2006 15:48:38 -0000 Received: from mablung.edhellond.fbi.ie (mablung.edhellond.fbi.ie [192.168.0.14]) by alatar.edhellond.fbi.ie (8.13.1/8.13.1) with ESMTP id k6OFmXBF012147 for ; Mon, 24 Jul 2006 15:48:38 GMT (envelope-from feargal@helgrim.com) Date: Mon, 24 Jul 2006 16:48:32 +0100 From: Feargal Reilly To: freebsd-stable@freebsd.org Message-ID: <20060724164832.11683f08@mablung.edhellond.fbi.ie> In-Reply-To: <200607241514.k6OFERos052696@lurza.secnetix.de> References: <20060721140005.5365e4b7@mablung.edhellond.fbi.ie> <200607241514.k6OFERos052696@lurza.secnetix.de> Organization: www.helgrim.com X-Mailer: Sylpheed-Claws 2.1.1 (GTK+ 2.8.7; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_8mWkG7M.EDc2L7O8RQHTbS="; protocol="application/pgp-signature"; micalg=PGP-SHA1 Subject: Re: filesystem full error with inumber X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 15:48:56 -0000 --Sig_8mWkG7M.EDc2L7O8RQHTbS= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 24 Jul 2006 17:14:27 +0200 (CEST) Oliver Fromme wrote: > Nobody else has answered so far, so I try to give it a shot ... >=20 > The "filesystem full" error can happen in three cases: > 1. The file system is running out of data space. > 2. The file system is running out of inodes. > 3. The file system is running out of non-fragmented blocks. >=20 > The third case can only happen on extremely fragmented > file systems which happens very rarely, but maybe it's > a possible cause of your problem. I rebooted that server, and df then reported that disk at 108%, so it appears that df was reporting incorrect figures prior to the reboot. Having cleaned up, it appears by my best calculations to be showing correct figures now. > > kern.maxfiles: 20000 > > kern.openfiles: 3582 >=20 > Those have nothing to do with "filesystem full". >=20 Yeah, that's what I figured. > > Looking again at dumpfs, it appears to say that this is > > formatted with a block size of 8K, and a fragment size of > > 2K, but tuning(7) says: [...] > > Reading this makes me think that when this server was > > installed, the block size was dropped from the 16K default > > to 8K for performance reasons, but the fragment size was > > not modified accordingly. > >=20 > > Would this be the root of my problem? >=20 > I think a bsize/fsize ratio of 4/1 _should_ work, but it's > not widely used, so there might be bugs hidden somewhere. >=20 Such as df not reporting the actual data usage, which is now my best working theory. I don't know what df bases it's figures on, perhaps it either slowly got out of sync, or more likely, got things wrong once the disk filled up. I'll monitor it to see if this happens again, but hopefully won't keep that configuration around for too much longer anyway. Thanks, -fr. --=20 Feargal Reilly. PGP Key: 0x847DE4C8 (expires: 2006-11-30) Web: http://www.helgrim.com/ | ICQ: 109837009 | YIM: ectoraige Visit http://ie.bsd.net/ - BSDs presence in Ireland --Sig_8mWkG7M.EDc2L7O8RQHTbS= Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFExOvQHfl+zYR95MgRAkxgAJ9v8yja+81hyTw95wGnx6Kex2gSWQCfa7vG s8AXxUMOrUdMwZY0msAQqQY= =rgCR -----END PGP SIGNATURE----- --Sig_8mWkG7M.EDc2L7O8RQHTbS=-- From owner-freebsd-stable@FreeBSD.ORG Mon Jul 24 16:49:22 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7887E16A4DF for ; Mon, 24 Jul 2006 16:49:22 +0000 (UTC) (envelope-from anton@nikiforov.ru) Received: from vika.newlines.ru (anna.newlines.ru [195.246.218.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 926B943D49 for ; Mon, 24 Jul 2006 16:49:21 +0000 (GMT) (envelope-from anton@nikiforov.ru) Received: from localhost (unknown [127.0.0.1]) by vika.newlines.ru (Postfix) with ESMTP id 90580115E5 for ; Mon, 24 Jul 2006 20:49:20 +0400 (MSD) Received: from vika.newlines.ru ([127.0.0.1]) by localhost (anna.newlines.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30973-06 for ; Mon, 24 Jul 2006 20:49:16 +0400 (MSD) Received: from [192.168.100.10] (nata.newlines.ru [195.246.218.100]) by vika.newlines.ru (Postfix) with ESMTP for ; Mon, 24 Jul 2006 20:49:16 +0400 (MSD) Message-ID: <44C4FA0F.4050204@nikiforov.ru> Date: Mon, 24 Jul 2006 20:49:19 +0400 From: Anton Nikiforov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070800020000050408070302" X-Virus-Scanned: By amavis at office-gw.newlines.ru Subject: gmirror problem/question X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 16:49:22 -0000 This is a cryptographically signed message in MIME format. --------------ms070800020000050408070302 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Dear All I'm trying to implement gmirror file system for my cluster. Does someone using geom/gmirror solutions for that? any comments? I'm confused with the algorithm of moving gmirrored volume from one server to another. And how to add failed provider to a volume. I'm trying to stop the volume, then start ggatec on another server (all volumes are always exported with ggated on both servers), then I'm recreating mirror with gmirror label...... Sometimes when I'm adding/moving the volume I'm getting /dev/da1s1h device busy error, sometimes ggatec dies, sometimes I'm getting "device not connected" message. Looks like some kind of voodoo for me. The only way i can bring all volumes up - is to reboot both servers. Does someone solve this? Any suggestions? Please. OS is 6.1-RELEASE-p2. HW is Intel JR2 sever with hot swap scsi discs under mpt driver. Servers are cross linked via em1 (gigabit Ethernet). -- Best regards, Anton Nikiforov --------------ms070800020000050408070302 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJBzCC At4wggJHoAMCAQICED5iPRHTm8oxoqEN/9ixjGgwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDcyMDA1NTEzM1oX DTA3MDcyMDA1NTEzM1owRDEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEhMB8G CSqGSIb3DQEJARYSYW50b25AbmlraWZvcm92LnJ1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAzi4dy65s7w6qdSSOecwDqfaU2CVDXGShsD4l89gadJAiIWSSH7kjo8wJIJEK WGRsPfM8zJk5V7EBxNFM3X89g3phBbA+sLYc4+dRJoLLPLAKgsDUWQ3iXUvihNYLwnaLBCiZ 1of+AVIdlZ0A/XN5ZWX9iHqkwFTxfOXG5LGSlBMgeWQQXwz9aDhlSPfgnhjSAMKNI+XxFV/a sVAGfv3YUNDqwRno4HQI7YcSHJh3ozA+m8sWLm5mW8D2wKb0XGKD8Ldm1Mz4sH/mAj+PvsSi bryaq/Se3XuOnvO5IhZGUcLMqfW+bpzgyUsjBPGkKbyOs9ujQZUoFXS71ozQ3sDRaQIDAQAB oy8wLTAdBgNVHREEFjAUgRJhbnRvbkBuaWtpZm9yb3YucnUwDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQUFAAOBgQCTvdT0nAzuDCmAa37GaUKw41Ywlp2yxc4wN9g2/CXut9140xMZTfCm Hzsks7pGVZUiGzfZrXx2byVW3uA4r/LFPcGv19dWVx/j3OHBGagfFDVtSkfC/vdGiCG6/Kh/ 3o/0Jf+0TOzBiQv1FznkVN6StXOs7dIQ8ZZIspbcuJzhhTCCAt4wggJHoAMCAQICED5iPRHT m8oxoqEN/9ixjGgwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDcyMDA1NTEzM1oXDTA3MDcyMDA1NTEzM1owRDEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEhMB8GCSqGSIb3DQEJARYSYW50b25A bmlraWZvcm92LnJ1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzi4dy65s7w6q dSSOecwDqfaU2CVDXGShsD4l89gadJAiIWSSH7kjo8wJIJEKWGRsPfM8zJk5V7EBxNFM3X89 g3phBbA+sLYc4+dRJoLLPLAKgsDUWQ3iXUvihNYLwnaLBCiZ1of+AVIdlZ0A/XN5ZWX9iHqk wFTxfOXG5LGSlBMgeWQQXwz9aDhlSPfgnhjSAMKNI+XxFV/asVAGfv3YUNDqwRno4HQI7YcS HJh3ozA+m8sWLm5mW8D2wKb0XGKD8Ldm1Mz4sH/mAj+PvsSibryaq/Se3XuOnvO5IhZGUcLM qfW+bpzgyUsjBPGkKbyOs9ujQZUoFXS71ozQ3sDRaQIDAQABoy8wLTAdBgNVHREEFjAUgRJh bnRvbkBuaWtpZm9yb3YucnUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTvdT0 nAzuDCmAa37GaUKw41Ywlp2yxc4wN9g2/CXut9140xMZTfCmHzsks7pGVZUiGzfZrXx2byVW 3uA4r/LFPcGv19dWVx/j3OHBGagfFDVtSkfC/vdGiCG6/Kh/3o/0Jf+0TOzBiQv1FznkVN6S tXOs7dIQ8ZZIspbcuJzhhTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEa MBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vy dmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcw MDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FW y688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEE QB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2 oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0x MzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9l X5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIIDYAIBATB2 MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQPmI9EdOb yjGioQ3/2LGMaDAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wNjA3MjQxNjQ5MTlaMCMGCSqGSIb3DQEJBDEWBBRBZZ03+qciHngs gHuxX5ywIRs2EDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAE MXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED5i PRHTm8oxoqEN/9ixjGgwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED5iPRHTm8oxoqEN/9ixjGgwDQYJKoZIhvcN AQEBBQAEggEAGhSUR7ZuI0KEtZ8dr3b9xMSfeym/k51fyhsJ/lXhevdF6pyn7JwSIqqEH7bR QW5vD0/Ihs23WTlVniER+e6l1voa1bfjvnegCklyvuu+dotYQUpmgu+CNLwEJQH5cthomMtm jmNqOH3q2RVmuS95UDD2DuAdD+fJxMQiBD5TzKoCOdWuFnxvtWHGbkJndIRTmi2o6aCM62az xlCWs2w4zlRUJLJ1Ej2m2TdCFENMgJR0KcdaiDvaV2dw8FrpVZkgSYYLK/bQF1jfKXkso4tY hfmvOfEfwmKmvTa/o7WsuOEco/76vmKtlg1f3G4Z7z2gwoGWgfebb76q2lNIl/tFLwAAAAAA AA== --------------ms070800020000050408070302-- From owner-freebsd-stable@FreeBSD.ORG Mon Jul 24 16:50:37 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 00F3F16A4DF for ; Mon, 24 Jul 2006 16:50:37 +0000 (UTC) (envelope-from jason@monsterjam.org) Received: from ms-smtp-03.southeast.rr.com (ms-smtp-03.southeast.rr.com [24.25.9.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id E495343D6E for ; Mon, 24 Jul 2006 16:50:21 +0000 (GMT) (envelope-from jason@monsterjam.org) Received: from monsterjam.org (cpe-066-057-016-142.nc.res.rr.com [66.57.16.142]) by ms-smtp-03.southeast.rr.com (8.13.6/8.13.6) with SMTP id k6OGoDSe016518 for ; Mon, 24 Jul 2006 12:50:14 -0400 (EDT) Received: (qmail 16459 invoked by uid 0); 24 Jul 2006 16:50:10 -0000 Received: from 127.0.0.1 by monsterjam.org (envelope-from , uid 82) with qmail-scanner-2.01st (clamdscan: 0.88/1287. Clear:RC:1(127.0.0.1):. Processed in 0.072136 secs); 24 Jul 2006 16:50:10 -0000 Received: from unknown (HELO monsterjam.org) (127.0.0.1) by 0 with SMTP; 24 Jul 2006 16:50:10 -0000 Received: (from jason@localhost) by monsterjam.org (8.13.1/8.13.1/Submit) id k6OGoAJI016440 for stable@freebsd.org; Mon, 24 Jul 2006 12:50:10 -0400 (EDT) (envelope-from jason) Date: Mon, 24 Jul 2006 12:50:10 -0400 From: Jason To: stable@freebsd.org Message-ID: <20060724165010.GA5589@monsterjam.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: Symantec AntiVirus Scan Engine Cc: Subject: crashes on newly updated freebsd 6.1 box.. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 16:50:37 -0000 I was running 6.0 stable on my dual Pentium III/733Mhz box and was running fine and dandy.. I did makeworld to upgrade to 6.1 and its been crashing weekly if not less.. the only thing I get on the console is Sleeping thread (tid 100075, pid 4401) owns a non-sleepable lock panic: sleeping thread cpuid = 0 KDB: enter: panic I couldnt break in on the console and had to hard reboot the box. I was thinking this is kern/99094 but im not sure. I dont have any linux fs references in my /etc/fstab.. jason@monsterjam jason $ cat /etc/fstab # Device Mountpoint FStype Options Dump Pass# /dev/idad0s1b none swap sw 0 0 /dev/idad0s1a / ufs rw 1 1 /dev/idad0s1e /tmp ufs rw 2 2 /dev/idad0s1f /usr ufs rw 2 2 /dev/idad0s1d /var ufs rw 2 2 /dev/idad1s1d /stuff ufs rw 2 2 /dev/acd0 /cdrom cd9660 ro,noauto 0 0 proc /proc procfs rw 0 0 jason@monsterjam jason $ but I do have jason@monsterjam jason $ kldstat Id Refs Address Size Name 1 5 0xc0400000 6540b0 kernel 2 1 0xc4f8c000 16000 linux.ko jason@monsterjam jason $ should I disable linux compatibility? or what? this is getting very annoying. jason@monsterjam jason $ uname -a FreeBSD mj.org 6.1-STABLE FreeBSD 6.1-STABLE #1: Sat Jul 22 17:40:37 EDT 2006 jason@mj.org:/usr/src/sys/i386/compile/BEAST i386 regards, Jason From owner-freebsd-stable@FreeBSD.ORG Mon Jul 24 17:18:58 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 02B2716A4DD; Mon, 24 Jul 2006 17:18:58 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from sccmmhc92.asp.att.net (sccmmhc92.asp.att.net [204.127.203.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7324843D45; Mon, 24 Jul 2006 17:18:57 +0000 (GMT) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net ([12.207.12.9]) by sccmmhc92.asp.att.net (sccmmhc92) with ESMTP id <20060724171856m92002sjp6e>; Mon, 24 Jul 2006 17:18:56 +0000 Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.6/8.13.6) with ESMTP id k6OHIsJO093028; Mon, 24 Jul 2006 12:18:55 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.6/8.13.6/Submit) id k6OHIsam093027; Mon, 24 Jul 2006 12:18:54 -0500 (CDT) (envelope-from brooks) Date: Mon, 24 Jul 2006 12:18:54 -0500 From: Brooks Davis To: Andrew Thompson Message-ID: <20060724171853.GC91329@lor.one-eyed-alien.net> References: <20060723103306.GB53338@heff.fud.org.nz> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DSayHWYpDlRfCAAQ" Content-Disposition: inline In-Reply-To: <20060723103306.GB53338@heff.fud.org.nz> User-Agent: Mutt/1.5.11 Cc: stable@freebsd.org Subject: Re: interface announcement MFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 17:18:58 -0000 --DSayHWYpDlRfCAAQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 23, 2006 at 10:33:06PM +1200, Andrew Thompson wrote: > > I would quite like to MFC the autobridge feature but it depends on this > change, http://lists.freebsd.org/pipermail/cvs-src/2006-May/064529.html >=20 > I cant see it being a problem MFCing this to stable as the existing devd > announcement still exists, it just adds another that includes pseudo ones > too. Does anyone forsee any problems? I think it should be OK. We haven't seen any problems on -current and there should be enough time for things to settle before 6.2 in any case. -- Brooks --DSayHWYpDlRfCAAQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFExQD9XY6L6fI4GtQRAqUTAJ9bxekXr72ahoJVDelIriiyNrPFvwCfRLXX 38YHomILrWlYV10MlKqZoBA= =zIZl -----END PGP SIGNATURE----- --DSayHWYpDlRfCAAQ-- From owner-freebsd-stable@FreeBSD.ORG Mon Jul 24 19:23:43 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0150216A4DD for ; Mon, 24 Jul 2006 19:23:43 +0000 (UTC) (envelope-from marcelo@registro.br) Received: from clone.registro.br (clone.registro.br [200.160.2.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A03A43D45 for ; Mon, 24 Jul 2006 19:23:42 +0000 (GMT) (envelope-from marcelo@registro.br) Received: by clone.registro.br (Postfix, from userid 1014) id E387A2A4F8; Mon, 24 Jul 2006 16:23:40 -0300 (BRT) Date: Mon, 24 Jul 2006 16:23:40 -0300 From: Marcelo Gardini do Amaral To: Ed Maste Message-ID: <20060724192340.GA51092@registro.br> References: <20060711190908.GC69272@registro.br> <20060720023856.GA65960@sandvine.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060720023856.GA65960@sandvine.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-stable@freebsd.org Subject: Re: How to setup polling on 'bge' interface X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 19:23:43 -0000 > A few points: > > - Polling and SMP are compatible in 6.1. In fact, they were compatible > in earlier versions too; basically it's just the compile-time check > that had to be "fixed." > > - You may have to adjust some parameters in the kern.polling sysctl > tree - specifically, kern.polling.burst_max, kern.polling.each_burst > and kern.polling.user_frac might need tweaking. > > - The polling feedback algorithm does not work very well if your > workload is focused largely on per-packet tasks (such as routing or > bridging). You'll find that there is still idle CPU time at the > point you start dropping packets. I have some work in progress to > address this, but it's not yet committed. > > - Polling's major advantage is the avoidance of livelock on UP systems, > and not improved performance. > > What level of traffic are you putting through this box? Is it routing/ > bridging, or an endpoint like a web server? It's an endpoint with no more than 1k pkts/s in normal condition. Almost all traffic is UDP. I really intend to avoid locking my system in a high load situation. -- Att., Marcelo Gardini From owner-freebsd-stable@FreeBSD.ORG Mon Jul 24 19:35:25 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4826016A4E2 for ; Mon, 24 Jul 2006 19:35:25 +0000 (UTC) (envelope-from marcelo@registro.br) Received: from clone.registro.br (clone.registro.br [200.160.2.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id D10CA43D4C for ; Mon, 24 Jul 2006 19:35:24 +0000 (GMT) (envelope-from marcelo@registro.br) Received: by clone.registro.br (Postfix, from userid 1014) id E4D652A55B; Mon, 24 Jul 2006 16:35:23 -0300 (BRT) Date: Mon, 24 Jul 2006 16:35:23 -0300 From: Marcelo Gardini do Amaral To: Scott Long Message-ID: <20060724193523.GB51092@registro.br> References: <20060711190908.GC69272@registro.br> <20060720023856.GA65960@sandvine.com> <20060720112613.GB716@turion.vk2pj.dyndns.org> <44BFA2EE.7060308@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44BFA2EE.7060308@samsco.org> User-Agent: Mutt/1.4.2.1i Cc: Peter Jeremy , freebsd-stable@freebsd.org, Ed Maste Subject: Re: How to setup polling on 'bge' interface X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 19:35:25 -0000 > >The limited testing I've done on a Sun V20z at work suggests that you > >can get better routing throughput in interrupt mode than polling mode. > >YMMV and this is before tweaking the polling parameters. (My testing > >also suggests that I don't really need to do any tweaking because > >the limiting factor is the gigabit interfaces rather than the V20z). I've noticed a higher (and variable) RTT with polling mode activated, without tweaking any parameters. > > This might not apply to bge, but the adaptive polling + fast interrupt > changes that I made to if_em earlier in the year were a huge win over > the standard polling code in terms of CPU utilization and packets per > second. I think it also survived a load that caused normal polling to > essentially livelock the machine. And, it had the advantage of > automatically adapting to bursty loads. -- Att., Marcelo Gardini From owner-freebsd-stable@FreeBSD.ORG Mon Jul 24 19:41:21 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D7F9016A4EA for ; Mon, 24 Jul 2006 19:41:21 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52F3443D69 for ; Mon, 24 Jul 2006 19:41:17 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [10.10.3.185] ([165.236.175.187]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k6OJf8Rj048832; Mon, 24 Jul 2006 13:41:14 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <44C5223D.5010707@samsco.org> Date: Mon, 24 Jul 2006 13:40:45 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060206 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcelo Gardini do Amaral References: <20060711190908.GC69272@registro.br> <20060720023856.GA65960@sandvine.com> <20060720112613.GB716@turion.vk2pj.dyndns.org> <44BFA2EE.7060308@samsco.org> <20060724193523.GB51092@registro.br> In-Reply-To: <20060724193523.GB51092@registro.br> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=3.8 tests=none autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: Peter Jeremy , freebsd-stable@freebsd.org, Ed Maste Subject: Re: How to setup polling on 'bge' interface X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 19:41:22 -0000 Marcelo Gardini do Amaral wrote: >>>The limited testing I've done on a Sun V20z at work suggests that you >>>can get better routing throughput in interrupt mode than polling mode. >>>YMMV and this is before tweaking the polling parameters. (My testing >>>also suggests that I don't really need to do any tweaking because >>>the limiting factor is the gigabit interfaces rather than the V20z). > > > I've noticed a higher (and variable) RTT with polling mode activated, > without tweaking any parameters. > Yes, the RTT will vary based on whether the interface has to wait a full tick or only a partial tick for the polling loop to become active. Adaptive polling eliminates most of this variance. Scott From owner-freebsd-stable@FreeBSD.ORG Mon Jul 24 20:23:00 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA43B16A4DE for ; Mon, 24 Jul 2006 20:23:00 +0000 (UTC) (envelope-from peo@intersonic.se) Received: from neonpark.inter-sonic.com (neonpark.inter-sonic.com [212.247.8.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74DDA43D4C for ; Mon, 24 Jul 2006 20:23:00 +0000 (GMT) (envelope-from peo@intersonic.se) X-Virus-Scanned: amavisd-new at inter-sonic.com Message-ID: <44C52C20.6030104@intersonic.se> Date: Mon, 24 Jul 2006 22:22:56 +0200 From: Per olof Ljungmark Organization: Intersonic AB User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: 6-STABLE locks solid - current ok, why? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 20:23:00 -0000 Hi, Got a testbed Proliant DL380G2, internal SmartArray 5i disabled, have SmartArray 5300 with 6 disks. Installed 6.1-REL last week, rebuilt to -STABLE three times since without a problem. However, when I try to add various (random) applications the box locks up solid during "configure" or "make". Apps tested are postfix, jdk15, OpenOffice-2.0 and more. When it hangs the only thing remaining is power cycling, no keyboard access possible. What puzzles me here is that now I installed -CURRENT from yesterday on same box without any other changes and it works like charm, so far I'm through building close to 50 ports including kde with dependencies. Next step I guess is to go back to RELENG and check again. Meanwhile, does anyone out there have an idea where I should look? This box is going into production and I'm not brave enough to run -CURRENT... Thanks, From owner-freebsd-stable@FreeBSD.ORG Mon Jul 24 20:32:55 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F161016A4DD for ; Mon, 24 Jul 2006 20:32:55 +0000 (UTC) (envelope-from peo@intersonic.se) Received: from neonpark.inter-sonic.com (neonpark.inter-sonic.com [212.247.8.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75F8643D68 for ; Mon, 24 Jul 2006 20:32:55 +0000 (GMT) (envelope-from peo@intersonic.se) X-Virus-Scanned: amavisd-new at inter-sonic.com Message-ID: <44C52E73.6060407@intersonic.se> Date: Mon, 24 Jul 2006 22:32:51 +0200 From: Per olof Ljungmark Organization: Intersonic AB User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Daniel Bond References: <44C52C20.6030104@intersonic.se> <20060724202944.GA36011@spearburn.danielbond.org> In-Reply-To: <20060724202944.GA36011@spearburn.danielbond.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: 6-STABLE locks solid - current ok, why? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 20:32:56 -0000 Daniel Bond wrote: > On 22:22 Mon 24 Jul, Per olof Ljungmark wrote: >> Hi, >> >> Got a testbed Proliant DL380G2, internal SmartArray 5i disabled, have SmartArray 5300 with 6 disks. >> >> Installed 6.1-REL last week, rebuilt to -STABLE three times since without a problem. However, when I try to >> add various (random) applications the box locks up solid during "configure" or "make". Apps tested are >> postfix, jdk15, OpenOffice-2.0 and more. When it hangs the only thing remaining is power cycling, no >> keyboard access possible. >> >> What puzzles me here is that now I installed -CURRENT from yesterday on same box without any other changes >> and it works like charm, so far I'm through building close to 50 ports including kde with dependencies. >> >> Next step I guess is to go back to RELENG and check again. Meanwhile, does anyone out there have an idea >> where I should look? This box is going into production and I'm not brave enough to run -CURRENT... > > Hi, > > try to disable ACPI. It can be usefull for reading CPU temperature and fan > speeds, but has no real function on a server. It's mostly usefull for power > managment, supend and resume support. From the handbook: > > Most system hangs are a result of lost interrupts or an interrupt storm. > Chipsets have a lot of problems based on how the BIOS configures interrupts > before boot, correctness of the APIC (MADT) table, and routing of the System > Control Interrupt (SCI). > > Interrupt storms can be distinguished from lost interrupts by checking the > output of vmstat -i and looking at the line that has acpi0. If the counter is > increasing at more than a couple per second, you have an interrupt storm. If > the system appears hung, try breaking to DDB (CTRL+ALT+ESC on console) and > type show interrupts. > > Your best hope when dealing with interrupt problems is to try disabling APIC > support with hint.apic.0.disabled="1" in loader.conf > Sorry, I should have mentioned that I tried both ways with same outcome. From owner-freebsd-stable@FreeBSD.ORG Mon Jul 24 20:46:28 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8547516A5D3 for ; Mon, 24 Jul 2006 20:46:28 +0000 (UTC) (envelope-from peo@intersonic.se) Received: from neonpark.inter-sonic.com (neonpark.inter-sonic.com [212.247.8.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id E743243D6A for ; Mon, 24 Jul 2006 20:46:22 +0000 (GMT) (envelope-from peo@intersonic.se) X-Virus-Scanned: amavisd-new at inter-sonic.com Message-ID: <44C5319B.3060508@intersonic.se> Date: Mon, 24 Jul 2006 22:46:19 +0200 From: Per olof Ljungmark Organization: Intersonic AB User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: msaad@datapipe.com References: <44C52C20.6030104@intersonic.se> <44C52E57.8010906@datapipe.com> In-Reply-To: <44C52E57.8010906@datapipe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: 6-STABLE locks solid - current ok, why? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 20:46:28 -0000 The 5300 have a battery backed up cache, I guess I should try to run the box off the 5i to check. Have several 360/380 G1/2/3's here too and never saw this before. I did: * Installed hw; iLO card + one Intel em0 + the 5300 * Booted 6.1-REL CD, installed base system including ports tree and sources * pkg_add -r cvsup-without-gui * fetched 6-STABLE sources * Edit the kernel config (took out 486/586, added SMP/APIC) * rebuilt and installed world (I usually do this a few times over to check for hardware problems) * Installed postfix, that worked ok. * Next app (don't remeber which one sorry) hung the box * fetched 6-STABLE sources again * rebuilt and installed world, worked fine * tried again to complie apps, no joy. Hangs at random places, no error messages, just locks. * fetched 6-STABLE sources again * rebuilt and installed world, worked fine and finally, fetched -CURRENT, rebuilt and now everything is just great. ACPI is enabled. Reason I'm running -STABE is that I expect this one to go into production about the time 6.2 is released. Thanks, Mark Saad wrote: > Hello > I use many 380's here G2 G3 and G4's and I have not see this yet . I > am currently using a G3 w/o any issues with RELENG_6. > This box is a jumpstart and buildmaster for my office and this is the DL > I use 6.1 on the most. As for the G2 I moved away from them for the most > part, but I have one here in my office I could check out if you have a > list of what you did. I have two questions for you first, Why are you > using the SA5300 , and are you running famd or ganim on the server; or a > nfs client attached to the server ? > > > Per olof Ljungmark wrote: >> Hi, >> >> Got a testbed Proliant DL380G2, internal SmartArray 5i disabled, have >> SmartArray 5300 with 6 disks. >> >> Installed 6.1-REL last week, rebuilt to -STABLE three times since >> without a problem. However, when I try to add various (random) >> applications the box locks up solid during "configure" or "make". Apps >> tested are postfix, jdk15, OpenOffice-2.0 and more. When it hangs the >> only thing remaining is power cycling, no keyboard access possible. >> >> What puzzles me here is that now I installed -CURRENT from yesterday >> on same box without any other changes and it works like charm, so far >> I'm through building close to 50 ports including kde with dependencies. >> >> Next step I guess is to go back to RELENG and check again. Meanwhile, >> does anyone out there have an idea where I should look? This box is >> going into production and I'm not brave enough to run -CURRENT... >> >> Thanks, >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > From owner-freebsd-stable@FreeBSD.ORG Mon Jul 24 21:58:35 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8457516A4DE for ; Mon, 24 Jul 2006 21:58:35 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 30B9F43D4C for ; Mon, 24 Jul 2006 21:58:35 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.13.7/8.13.7) with ESMTP id k6OLupHX089605 for ; Mon, 24 Jul 2006 14:56:51 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.7/8.13.7/Submit) id k6OLupuv089604 for freebsd-stable@freebsd.org; Mon, 24 Jul 2006 14:56:51 -0700 (PDT) (envelope-from sgk) Date: Mon, 24 Jul 2006 14:56:51 -0700 From: Steve Kargl To: freebsd-stable@freebsd.org Message-ID: <20060724215640.GA89543@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: Cardbus0: CIS pointer != 0 problem. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 21:58:35 -0000 I have a colleague who installed FreeBSD 6.1-stable onto an Alienware MJ-12 laptop. A verbose dmesg is at http://troutmask.apl.washington.edu/~kargl/alienware.dmesg We are trying to getting his wireless nic up, but seem to have run into a cardbus issue. I've built a custom kernel and stripped out all unneeded device drives. During boot,r we see cardbus0: CIS pointer is 0! cardbus0: Resource not specified in CIS: id=10, size=1000000 cardbus0: Resource not specified in CIS: id=14, size=0 cardbus0: Resource not specified in CIS: id=1c, size=1000000 cardbus0: Resource not specified in CIS: id=24, size=80 cbb alloc res fail found-> vendor=0x10de, dev=0x0299, revid=0xa1 bus=2, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit Has anyone seen this problem and do you have some recommendations to fix or work around the issue? -- Steve From owner-freebsd-stable@FreeBSD.ORG Tue Jul 25 02:20:43 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 376CB16A4DA for ; Tue, 25 Jul 2006 02:20:43 +0000 (UTC) (envelope-from j.m.cooper@borgsdemons.com) Received: from smtp107.biz.mail.mud.yahoo.com (smtp107.biz.mail.mud.yahoo.com [68.142.200.255]) by mx1.FreeBSD.org (Postfix) with SMTP id B6F4B43D45 for ; Tue, 25 Jul 2006 02:20:42 +0000 (GMT) (envelope-from j.m.cooper@borgsdemons.com) Received: (qmail 83900 invoked from network); 25 Jul 2006 02:20:42 -0000 Received: from unknown (HELO borgdemon2.clspco.adelphia.net) (j.m.cooper@borgsdemons.com@67.22.17.55 with login) by smtp107.biz.mail.mud.yahoo.com with SMTP; 25 Jul 2006 02:20:41 -0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by borgdemon2.clspco.adelphia.net (Postfix) with ESMTP id DF0C15D18; Mon, 24 Jul 2006 21:20:39 -0500 (CDT) Message-ID: <44C57FF5.9020904@borgsdemons.com> Date: Mon, 24 Jul 2006 21:20:37 -0500 From: John Merryweather Cooper User-Agent: Thunderbird 1.5.0.4 (X11/20060617) MIME-Version: 1.0 To: Steve Kargl References: <20060724215640.GA89543@troutmask.apl.washington.edu> In-Reply-To: <20060724215640.GA89543@troutmask.apl.washington.edu> Content-Type: multipart/mixed; boundary="------------090703060103080608000002" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: Cardbus0: CIS pointer != 0 problem. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2006 02:20:43 -0000 This is a multi-part message in MIME format. --------------090703060103080608000002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Steve Kargl wrote: > I have a colleague who installed FreeBSD 6.1-stable onto > an Alienware MJ-12 laptop. A verbose dmesg is at > http://troutmask.apl.washington.edu/~kargl/alienware.dmesg > > We are trying to getting his wireless nic up, but seem to > have run into a cardbus issue. I've built a custom kernel > and stripped out all unneeded device drives. During boot,r > we see > > cardbus0: CIS pointer is 0! > cardbus0: Resource not specified in CIS: id=10, size=1000000 > cardbus0: Resource not specified in CIS: id=14, size=0 > cardbus0: Resource not specified in CIS: id=1c, size=1000000 > cardbus0: Resource not specified in CIS: id=24, size=80 > cbb alloc res fail > found-> vendor=0x10de, dev=0x0299, revid=0xa1 > bus=2, slot=0, func=0 > class=03-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0003, statreg=0x0010, cachelnsz=8 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=255 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > > Has anyone seen this problem and do you have some recommendations > to fix or work around the issue? > > This message most commonly comes up when the NIC/PCCARD is NOT supported by a native FreeBSD driver. For example: cardbus0: CIS pointer is 0! cardbus0: Resource not specified in CIS: id=10, size=2000 ndis0: mem 0xf6002000-0xf6003fff irq 11 at device 0.0 on cardbus0 ndis0: NDIS API version: 5.1 ndis0: Ethernet address: 00:11:50:7b:ba:b1 is the output for my Broadcom-based wireless NIC. I use a WinDoze driver and the ndis interface. jmc --------------090703060103080608000002-- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 25 04:09:41 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4797116A4DD for ; Tue, 25 Jul 2006 04:09:41 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id E801B43D4C for ; Tue, 25 Jul 2006 04:09:40 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.13.7/8.13.7) with ESMTP id k6P47sd3091601; Mon, 24 Jul 2006 21:07:54 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.7/8.13.7/Submit) id k6P47sBJ091600; Mon, 24 Jul 2006 21:07:54 -0700 (PDT) (envelope-from sgk) Date: Mon, 24 Jul 2006 21:07:54 -0700 From: Steve Kargl To: John Merryweather Cooper Message-ID: <20060725040754.GA91513@troutmask.apl.washington.edu> References: <20060724215640.GA89543@troutmask.apl.washington.edu> <44C57FF5.9020904@borgsdemons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44C57FF5.9020904@borgsdemons.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-stable@freebsd.org Subject: Re: Cardbus0: CIS pointer != 0 problem. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2006 04:09:41 -0000 On Mon, Jul 24, 2006 at 09:20:37PM -0500, John Merryweather Cooper wrote: > Steve Kargl wrote: > > > >cardbus0: CIS pointer is 0! > >cardbus0: Resource not specified in CIS: id=10, size=1000000 > >cardbus0: Resource not specified in CIS: id=14, size=0 > >cardbus0: Resource not specified in CIS: id=1c, size=1000000 > >cardbus0: Resource not specified in CIS: id=24, size=80 > >cbb alloc res fail > > > >Has anyone seen this problem and do you have some recommendations > >to fix or work around the issue? > > > > > This message most commonly comes up when the NIC/PCCARD is NOT supported > by a native FreeBSD driver. For example: The card has a atheros chip, and I know that it worked with FreeBSD 6.1-RELEASE. However, because of patches, I upgraded to 6.1-stable, and a acpi failure may be confusing cardbus. -- Steve From owner-freebsd-stable@FreeBSD.ORG Tue Jul 25 06:53:58 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EEDB216A603 for ; Tue, 25 Jul 2006 06:53:58 +0000 (UTC) (envelope-from dkirhlarov@oilspace.com) Received: from office.oilspace.com (ns2.oilspace.com [194.129.65.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8524643D45 for ; Tue, 25 Jul 2006 06:53:58 +0000 (GMT) (envelope-from dkirhlarov@oilspace.com) Received: from dimma (hq.oilspace.com [81.222.156.185]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.oilspace.com (Postfix) with ESMTP id 7BA65136D01 for ; Tue, 25 Jul 2006 07:53:56 +0100 (BST) Received: from dimma (localhost [127.0.0.1]) by dimma (8.13.6/8.13.6) with ESMTP id k6P6ru16032276 for ; Tue, 25 Jul 2006 10:53:56 +0400 (MSD) (envelope-from dkirhlarov@oilspace.com) Received: (from dkirhlarov@localhost) by dimma (8.13.6/8.13.6/Submit) id k6P6rtvs032275 for freebsd-stable@freebsd.org; Tue, 25 Jul 2006 10:53:55 +0400 (MSD) (envelope-from dkirhlarov) Date: Tue, 25 Jul 2006 10:53:55 +0400 From: Dmitriy Kirhlarov To: freebsd-stable@freebsd.org Message-ID: <20060725065355.GE12004@dimma.mow.oilspace.com> Mail-Followup-To: freebsd-stable@freebsd.org References: <44C4FA0F.4050204@nikiforov.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44C4FA0F.4050204@nikiforov.ru> X-Mailer: Mutt-ng devel (2005-03-13) based on Mutt 1.5.9 X-Operating-System: FreeBSD 6.1-STABLE User-Agent: mutt-ng/devel-r804 (FreeBSD) Subject: Re: gmirror problem/question X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2006 06:53:59 -0000 On Mon, Jul 24, 2006 at 08:49:19PM +0400, Anton Nikiforov wrote: > I'm trying to implement gmirror file system for my cluster. > Does someone using geom/gmirror solutions for that? any comments? > > I'm confused with the algorithm of moving gmirrored volume from one server to another. > And how to add failed provider to a volume. On first server you must make gmirror with one (local) disk. After that, you must start ggated on second server, ggatec on first server, run "gmirror forget ${DRIVE}" and add ggate${ID} disk in gmirror mirror. > I'm trying to stop the volume, then start ggatec on another server (all volumes are > always exported with ggated on both servers), then I'm recreating mirror with gmirror "always exported" -- not very good for me. By. Dmitriy From owner-freebsd-stable@FreeBSD.ORG Tue Jul 25 13:54:06 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 52E1516A4DA for ; Tue, 25 Jul 2006 13:54:06 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 255C843D45 for ; Tue, 25 Jul 2006 13:54:03 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 06A935138C; Tue, 25 Jul 2006 15:53:59 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id D1F945138A; Tue, 25 Jul 2006 15:53:52 +0200 (CEST) Date: Tue, 25 Jul 2006 15:53:32 +0200 From: Pawel Jakub Dawidek To: Anton Nikiforov Message-ID: <20060725135332.GC44939@garage.freebsd.pl> References: <44C0D388.3040205@nikiforov.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mvpLiMfbWzRoNl4x" Content-Disposition: inline In-Reply-To: <44C0D388.3040205@nikiforov.ru> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-stable@freebsd.org Subject: Re: gmirror problems X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2006 13:54:06 -0000 --mvpLiMfbWzRoNl4x Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 21, 2006 at 05:15:52PM +0400, Anton Nikiforov wrote: > Dear All, > I have the following gmirror configuration: > server1 > ggated > ggatec create -u 10 -o rw 192.168.100.110 /dev/da1s1d > gmirror label -v -b split -s 2048 geom1 /dev/da1s1d /dev/ggate10d > ggatec create -u 11 -o rw 192.168.100.110 /dev/da1s1e > gmirror label -v -b split -s 2048 geom2 /dev/da1s1e /dev/ggate11 > ggatec create -u 12 -o rw 192.168.100.110 /dev/da1s1f > gmirror label -v -b split -s 2048 geom3 /dev/da1s1f /dev/ggate12 > ggatec create -u 13 -o rw 192.168.100.110 /dev/da1s1g > gmirror label -v -b split -s 2048 geom4 /dev/da1s1g /dev/ggate13 > ggatec create -u 14 -o rw 192.168.100.110 /dev/da1s1h > gmirror label -v -b split -s 2048 geom5 /dev/da1s1h /dev/ggate14 >=20 > server 2 > ggated >=20 > When I'm starting from scratch. (currently by manually running all comman= ds/daemons) > Everything is fine, until I'm trying to mount gmirrored device from serve= r2. What I'm doing listed below > 1. Unmounting all file systems > 2. stooping all devices (all, but i need only one to start it on another = host) > 3. stopping daemons > 4. Starting daemon on server1 > 5. Trying to create ggatec device on server2 with the same command, but w= ith IP of server1 > getting error: ggatec: ggatec: ioctl(/dev/ggctl): Invalid argument. > ggatec: Exiting. > 6. looking into gmirror status device list i have all devices in DEGRADED= state on server 2 (there was no devices in the list while everything was u= p) > 7. longing into gmirror status device list i have all devices in COMPLETE= state and next time gmirror hangs forever. >=20 > Could you please help me or direct to the right manual? > I have found a lot of sources of how to setup (and I'm done with this). B= ut what should i do with failure? How to mount disk on another node or star= t it after failure? You cannot open any GEOM provider for writting twice. If you try to start ggatec on one server, ggated on the other server tries to open given partition, but it fails when it is already open on this server. Bascially, if you call: # ggatec create -u 10 -o rw 192.168.100.110 /dev/da1s1d You must be sure /dev/da1s1d on server 192.168.100.110 is not opened for writting already. > And one more question: is there any way to get gmirror to re mirror devic= es before carp interfaces become up? I want to get data mirrored before mov= ing services from backup=20 > firewall to main one (in case main was failed) Not sure if I understand this... > And one more thing..... after some manipulations with gmirror devices i h= ave server crushed while booting kernel. At the moment it initialize GEOM_M= IRROR device - kernel=20 > panics. > When i remove the disk that was containing gmirror devices - server just = booted normally. But insertion of that disk back and running camcontol resc= an all - bring it back=20 > to panic... so, i cannot use this disk anymore (i know, that i can rewrit= e it's last sector on machine without GEOM compiled into the kernel) I you want me to help with this one, you need to provide more info, especially what's going on on the console, panic message, backtrace, anything. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --mvpLiMfbWzRoNl4x Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFExiJcForvXbEpPzQRAkN9AJ9YUjvUSUNndO67VGiAkRexQaAMiwCfeK0O eFBvnNYKjl6HrLwaZh2nTHY= =Q3qW -----END PGP SIGNATURE----- --mvpLiMfbWzRoNl4x-- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 25 15:51:03 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 93E3116A4DD for ; Tue, 25 Jul 2006 15:51:03 +0000 (UTC) (envelope-from mikej@rogers.com) Received: from H43.C18.B96.tor.eicat.ca (H43.C18.B96.tor.eicat.ca [66.96.18.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F33943D53 for ; Tue, 25 Jul 2006 15:51:03 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from [127.0.0.1] (desktop.home.local [172.16.0.200]) by H43.C18.B96.tor.eicat.ca (Postfix) with ESMTP id 66A6111439 for ; Tue, 25 Jul 2006 11:50:52 -0400 (EDT) Message-ID: <44C63DFD.5040401@rogers.com> Date: Tue, 25 Jul 2006 11:51:25 -0400 From: Mike Jakubik User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SpamToaster-Information: This messages has been scanned by SpamToaster http://www.digitalprogression.ca X-SpamToaster: Found to be clean X-SpamToaster-SpamCheck: not spam, SpamAssassin (not cached, score=-2.49, required 3.5, ALL_TRUSTED -1.80, BAYES_00 -2.60, DK_POLICY_SIGNSOME 0.00, DNS_FROM_RFC_ABUSE 0.20, DNS_FROM_RFC_POST 1.71) X-SpamToaster-From: mikej@rogers.com X-Spam-Status: No Cc: Subject: Monitoring temperature with acpi (sysctls) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2006 15:51:03 -0000 I need to be able to get the cpu and fan information from my motherboard, however none of the monitoring utilities in the ports seems to support my motherboard (Supermicro PDSMi, Intel E7230 (Mukilteo) Chipset). On my older VIA based motherboards and some Nvidia, i can get this information using ACPI and the hw.acpi.thermal sysctl. This however is not available on this motherboard. Would this be a shortcoming of the motherboards ACPI implementation, or a lack of support by freebsd? From owner-freebsd-stable@FreeBSD.ORG Tue Jul 25 15:59:39 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B1D916A4DD; Tue, 25 Jul 2006 15:59:39 +0000 (UTC) (envelope-from mikej@rogers.com) Received: from H43.C18.B96.tor.eicat.ca (H43.C18.B96.tor.eicat.ca [66.96.18.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55BD943D64; Tue, 25 Jul 2006 15:59:32 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from [127.0.0.1] (desktop.home.local [172.16.0.200]) by H43.C18.B96.tor.eicat.ca (Postfix) with ESMTP id 5F37B1147C; Tue, 25 Jul 2006 11:59:25 -0400 (EDT) Message-ID: <44C63FFE.3080300@rogers.com> Date: Tue, 25 Jul 2006 11:59:58 -0400 From: Mike Jakubik User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: John Baldwin References: <20060629193346.GA2548@dragon.NUXI.org> <200607071343.14205.jhb@freebsd.org> <44AEAB61.6000104@rogers.com> <200607071526.47758.jhb@freebsd.org> In-Reply-To: <200607071526.47758.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SpamToaster-Information: This messages has been scanned by SpamToaster http://www.digitalprogression.ca X-SpamToaster: Found to be clean X-SpamToaster-SpamCheck: not spam, SpamAssassin (not cached, score=-2.49, required 3.5, ALL_TRUSTED -1.80, BAYES_00 -2.60, DK_POLICY_SIGNSOME 0.00, DNS_FROM_RFC_ABUSE 0.20, DNS_FROM_RFC_POST 1.71) X-SpamToaster-From: mikej@rogers.com X-Spam-Status: No Cc: stable@freebsd.org Subject: Re: Still getting 'calcru: runtime went backwards' X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2006 15:59:39 -0000 John Baldwin wrote: > On Friday 07 July 2006 14:43, Mike Jakubik wrote: > >> John Baldwin wrote: >> >>> That is partly because when you run top it queries the resource usage of >>> the various processes via fill_kinfo_proc(). When you don't run top, no >>> one is asking for the resource usage numbers, so the kernel doesn't waste >>> time calculating them. >>> >> Right, also running ps has the same effect. But why do these messages occur? >> > > Not sure. My guess would be an overflow of some sort but given the short > uptime that likely is not the case. > > Its not always instant, sometimes its after 4 hours of uptime, and its almost always on the yarrow or swi4 process. I would really like to solve this problem, would this be an issue of the motherboard or freebsd? If its the earlier, i can contact the manufacturer, but i would appreciate more information on the problem. Thanks. From owner-freebsd-stable@FreeBSD.ORG Tue Jul 25 17:23:09 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C1C816A4DD for ; Tue, 25 Jul 2006 17:23:09 +0000 (UTC) (envelope-from ohartman@mail.uni-mainz.de) Received: from mailgate2.zdv.Uni-Mainz.DE (mailgate2.zdv.Uni-Mainz.DE [134.93.178.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AAA843D5F for ; Tue, 25 Jul 2006 17:23:06 +0000 (GMT) (envelope-from ohartman@mail.uni-mainz.de) Received: from [192.168.1.128] (e178000066.adsl.alicedsl.de [85.178.0.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate2.zdv.Uni-Mainz.DE (Postfix) with ESMTP id E75ED3002C2B; Tue, 25 Jul 2006 19:23:04 +0200 (CEST) Message-ID: <44C65375.70908@mail.uni-mainz.de> Date: Tue, 25 Jul 2006 19:23:01 +0200 From: "O. Hartmann" User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: Mike Jakubik References: <44C63DFD.5040401@rogers.com> In-Reply-To: <44C63DFD.5040401@rogers.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-mainz.de Cc: stable@freebsd.org Subject: Re: Monitoring temperature with acpi (sysctls) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2006 17:23:09 -0000 Mike Jakubik wrote: > I need to be able to get the cpu and fan information from my > motherboard, however none of the monitoring utilities in the ports > seems to support my motherboard (Supermicro PDSMi, Intel E7230 > (Mukilteo) Chipset). On my older VIA based motherboards and some > Nvidia, i can get this information using ACPI and the hw.acpi.thermal > sysctl. This however is not available on this motherboard. Would this > be a shortcoming of the motherboards ACPI implementation, or a lack of > support by freebsd? > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" Similar problem to me here with a ASUS A8N32-SLI Deluxe. The older versions of this motherboard type like A8N-SLI Deluxe and maybe A8N-SLI Premium had thermal zones in ACPI output, but not the A8N32-SLI. No temperature, no fanspeed, no thermal zones. From owner-freebsd-stable@FreeBSD.ORG Tue Jul 25 18:18:16 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 370E516A4DD for ; Tue, 25 Jul 2006 18:18:16 +0000 (UTC) (envelope-from karagodov@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id B525243D53 for ; Tue, 25 Jul 2006 18:18:15 +0000 (GMT) (envelope-from karagodov@gmail.com) Received: by py-out-1112.google.com with SMTP id b36so2490292pyb for ; Tue, 25 Jul 2006 11:18:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=XXOd4sPwNF/YtMmClT2iPLVaEoIk+/SnwRvgDtejbFpbA1EdxTre4T5z4hQdSZwl3Ox/1VdRRp+op3n0GGI4tIC0oCqYzqN3lpBwYCKxxLR360Anji3qpWL0oTh0APEB2nu+aDpLXbPfIKI9zey424/irT5cotN4+SbeZ7m4VHg= Received: by 10.35.26.14 with SMTP id d14mr9860765pyj; Tue, 25 Jul 2006 11:18:11 -0700 (PDT) Received: by 10.35.69.12 with HTTP; Tue, 25 Jul 2006 11:18:10 -0700 (PDT) Message-ID: Date: Tue, 25 Jul 2006 22:18:10 +0400 From: "Alexey Karagodov" To: "Mike Jakubik" In-Reply-To: <44C63DFD.5040401@rogers.com> MIME-Version: 1.0 References: <44C63DFD.5040401@rogers.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: stable@freebsd.org Subject: Re: Monitoring temperature with acpi (sysctls) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2006 18:18:16 -0000 "me too". chipset - e7520 From owner-freebsd-stable@FreeBSD.ORG Tue Jul 25 22:01:56 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0FAC116A4DD; Tue, 25 Jul 2006 22:01:56 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8201343D46; Tue, 25 Jul 2006 22:01:53 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id k6PM1plJ050364; Tue, 25 Jul 2006 18:01:51 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.4P/8.13.4) with ESMTP id k6PM1q2p007992; Tue, 25 Jul 2006 18:01:52 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 224AC7302F; Tue, 25 Jul 2006 18:01:52 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20060725220152.224AC7302F@freebsd-current.sentex.ca> Date: Tue, 25 Jul 2006 18:01:52 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [releng_6 tinderbox] failure on i386/pc98 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2006 22:01:56 -0000 TB --- 2006-07-25 21:38:56 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-07-25 21:38:56 - starting RELENG_6 tinderbox run for i386/pc98 TB --- 2006-07-25 21:38:57 - cleaning the object tree TB --- 2006-07-25 21:39:25 - checking out the source tree TB --- 2006-07-25 21:39:25 - cd /tinderbox/RELENG_6/i386/pc98 TB --- 2006-07-25 21:39:25 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_6 src TB --- 2006-07-25 21:50:04 - building world (CFLAGS=-O2 -pipe) TB --- 2006-07-25 21:50:04 - cd /src TB --- 2006-07-25 21:50:04 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] sh /src/tools/install.sh -s -o root -g wheel -m 444 libbsdxml.so.2 /obj/pc98/src/tmp/lib ln -fs /obj/pc98/src/tmp/lib/libbsdxml.so.2 /obj/pc98/src/tmp/usr/lib/libbsdxml.so sh /src/tools/install.sh -C -o root -g wheel -m 444 bsdxml.h /obj/pc98/src/tmp/usr/include ===> lib/libkvm (depend,all,install) rm -f .depend mkdep -f .depend -a -DLIBC_SCCS -I/src/lib/libkvm /src/lib/libkvm/kvm.c /src/lib/libkvm/kvm_i386.c /src/lib/libkvm/kvm_file.c /src/lib/libkvm/kvm_getloadavg.c /src/lib/libkvm/kvm_getswapinfo.c /src/lib/libkvm/kvm_proc.c /src/lib/libkvm/kvm_minidump_i386.c /src/lib/libkvm/kvm_minidump_i386.c:49:30: machine/minidump.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /src/lib/libkvm. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-07-25 22:01:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-07-25 22:01:51 - ERROR: failed to build world TB --- 2006-07-25 22:01:51 - tinderbox aborted TB --- 1.04 user 5.69 system 1374.95 real From owner-freebsd-stable@FreeBSD.ORG Wed Jul 26 09:26:39 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 34AB516A4DD for ; Wed, 26 Jul 2006 09:26:39 +0000 (UTC) (envelope-from sdupille@nospam.fr.eu.org) Received: from mail.nospam.fr.eu.org (galadriel.nospam.fr.eu.org [88.191.16.109]) by mx1.FreeBSD.org (Postfix) with ESMTP id F3D8F43D46 for ; Wed, 26 Jul 2006 09:26:38 +0000 (GMT) (envelope-from sdupille@nospam.fr.eu.org) Received: by mail.nospam.fr.eu.org (Postfix, from userid 2001) id 519D5440814; Wed, 26 Jul 2006 11:26:34 +0200 (CEST) From: Stephane Dupille To: stable@freebsd.org Organization: Home Mail-copies-to: never Date: Wed, 26 Jul 2006 11:26:34 +0200 Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: Memory management X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 09:26:39 -0000 Hello there, I have a computer running FreeBSD 6.1. As time passing by, the memory fills up. When the machine starts, memory is occupied to 30 %, and after two or three weeks memory is occupied to 100 % and it begins to use swap. It is "inactive" pages that fills up the memory. I tried to restart every process, but memory usage does not decrease. Only a reboot can fix that. And I'm not able to see which process leaks. I was not able to find a correct definition of what "inactive" memory is. First, I would like to know what are these kind of pages : wired, active, inactive, cache and free. Is that normal that inactive memory usage grows ? What should I do ? Do you have any tools to monitor memory usage of processes ? Many thanks, regards, From owner-freebsd-stable@FreeBSD.ORG Wed Jul 26 11:34:29 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A588516A4DD for ; Wed, 26 Jul 2006 11:34:29 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 014E643D49 for ; Wed, 26 Jul 2006 11:34:28 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail07.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k6QBYDAj004348 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 26 Jul 2006 21:34:15 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.6/8.13.6) with ESMTP id k6QBYDwl088711; Wed, 26 Jul 2006 21:34:13 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.6/8.13.6/Submit) id k6QBYCs4088693; Wed, 26 Jul 2006 21:34:12 +1000 (EST) (envelope-from peter) Date: Wed, 26 Jul 2006 21:34:12 +1000 From: Peter Jeremy To: Stephane Dupille Message-ID: <20060726113412.GE740@turion.vk2pj.dyndns.org> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6Vw0j8UKbyX0bfpA" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: stable@freebsd.org Subject: Re: Memory management X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 11:34:29 -0000 --6Vw0j8UKbyX0bfpA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, 2006-Jul-26 11:26:34 +0200, Stephane Dupille wrote: > As time passing by, the memory fills up. When the machine starts, >memory is occupied to 30 %, and after two or three weeks memory is >occupied to 100 % and it begins to use swap. How are you monitoring memory usage? Do you mean 'swap' or 'page'? A level of page-in's is normal because text and data areas for processes are loaded by paging them in. > I was not able to find a correct definition of what "inactive" >memory is. First, I would like to know what are these kind of pages : >wired, active, inactive, cache and free. Wired pages are pages that the kernel has wired to RAM so they cannot be paged out. Active pages are being mapped by virtual memory and in use by running processes. Inactive pages are not currently mapped but the kernel knows their contents and can re-map them without needing to retrieve them from disk - they may be dirty. Cache pages are similar to active pages but aren't dirty and are higher-priority candidates for being freed. Free pages have no useful content and will be used to fulfil page-in requests. > Is that normal that inactive memory usage grows ? Yes. 'Free' memory is basically wasted and so the kernel tries to limit it, subject to having sufficient free memory to meet page-faults. Most of your RAM should be wired, active or inactive. Inactive memory will start at 0 and grow as active pages are released. > What should I do ? Nothing. Why do you think you have a problem? > Do you have any tools to monitor memory usage of processes ? ps(1) --=20 Peter Jeremy --6Vw0j8UKbyX0bfpA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEx1M0/opHv/APuIcRAjPsAJ488oChFIWPOTFZ6G0hvTnfr/mXGQCbBhqC kUqaAqyreICZndhL6XvXIs4= =azDF -----END PGP SIGNATURE----- --6Vw0j8UKbyX0bfpA-- From owner-freebsd-stable@FreeBSD.ORG Wed Jul 26 11:52:46 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5FAF316A4DD for ; Wed, 26 Jul 2006 11:52:46 +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 12E0143D46 for ; Wed, 26 Jul 2006 11:52:45 +0000 (GMT) (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 EF59846C14; Wed, 26 Jul 2006 07:52:44 -0400 (EDT) Date: Wed, 26 Jul 2006 12:52:44 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Stephane Dupille In-Reply-To: Message-ID: <20060726124251.W4612@fledge.watson.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: stable@freebsd.org Subject: Re: Memory management X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 11:52:46 -0000 On Wed, 26 Jul 2006, Stephane Dupille wrote: > I have a computer running FreeBSD 6.1. > > As time passing by, the memory fills up. When the machine starts, memory is > occupied to 30 %, and after two or three weeks memory is occupied to 100 % > and it begins to use swap. > > It is "inactive" pages that fills up the memory. > > I tried to restart every process, but memory usage does not decrease. Only > a reboot can fix that. And I'm not able to see which process leaks. > > I was not able to find a correct definition of what "inactive" memory is. > First, I would like to know what are these kind of pages : wired, active, > inactive, cache and free. > > Is that normal that inactive memory usage grows ? What should I do ? > > Do you have any tools to monitor memory usage of processes ? You can find an article discussing some of the FreeBSD VM system design here: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/vm-design/article.html This document is gradually aging, and doesn't cover certain elements of the design, including some recent optimizations, SMP behavior, etc, but still makes quite a good read. It could be that you have applications leaking memory, but it's more likely that the VM system is simply being efficient. Free memory is, in effect, wasted memory, since it's not being used. FreeBSD will agressively cache file system data, and either drop or page out unused pages (depending on whether they are dirty) in order to maximize the amount of memory available for actively used data. This means it will swap out dirty pages allocated by a process if the process isn't using them, rather than keep them in memory preventing that memory from being used by processes that need it. The result is that at any given moment, an active system should have almost no free memory, and instead should be providing as much memory as possible to active pages, and the largest possible file system cache. This may seem counter-intuitive compared to some other systems where a premium is placed on free pages as representing the resources available to run additional applications. We consider memory floating around "unused" to be a waste of memory that could be used to improve system performance. "systat -vmstat 1" is a good tool to monitor the VM system, as it will let you monitor memory use, in particular, the vnode and swap paging rates. You can use ps(1) with various parameters to inspect process memory use. A popular combination is "aux", which views all processes and displays, among other things, their virtual and resident sizes. The resident size is the figure you want to look at, as it represents the number of pages actually in memory, rather than pages that could be paged in. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Wed Jul 26 11:56:58 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 96AD616A4DA for ; Wed, 26 Jul 2006 11:56:58 +0000 (UTC) (envelope-from sdupille@nospam.fr.eu.org) Received: from mail.nospam.fr.eu.org (galadriel.nospam.fr.eu.org [88.191.16.109]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37BEF43D53 for ; Wed, 26 Jul 2006 11:56:57 +0000 (GMT) (envelope-from sdupille@nospam.fr.eu.org) Received: by mail.nospam.fr.eu.org (Postfix, from userid 2001) id 3AE09440813; Wed, 26 Jul 2006 13:56:56 +0200 (CEST) From: Stephane Dupille To: stable@freebsd.org References: <20060726113412.GE740@turion.vk2pj.dyndns.org> Organization: Home Mail-copies-to: never Date: Wed, 26 Jul 2006 13:56:56 +0200 In-Reply-To: <20060726113412.GE740@turion.vk2pj.dyndns.org> (Peter Jeremy's message of "Wed, 26 Jul 2006 21:34:12 +1000") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit Cc: Subject: Re: Memory management X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 11:56:58 -0000 Peter Jeremy écrit : >> As time passing by, the memory fills up. When the machine starts, >>memory is occupied to 30 %, and after two or three weeks memory is >>occupied to 100 % and it begins to use swap. > How are you monitoring memory usage? Using top, mainly. And ps, swapinfo, vmstat... > Do you mean 'swap' or 'page'? swap. > A level of page-in's is normal because text and data areas for > processes are loaded by paging them in. OK for that, but when I have 700 MB of "inactive memory", and "free memory" reaching zero, the system begins to use the swap : swapinfo says that swap is used (paged out). Is that normal ? > Wired pages are pages that the kernel has wired to RAM so they cannot > be paged out. Active pages are being mapped by virtual memory and > in use by running processes. Inactive pages are not currently mapped > but the kernel knows their contents and can re-map them without > needing to retrieve them from disk - they may be dirty. Cache pages > are similar to active pages but aren't dirty and are higher-priority > candidates for being freed. Free pages have no useful content and > will be used to fulfil page-in requests. OK, thanks for the definitions. Why there is two states "inactive" and "cache", if they are so similar ? (it's just curiosity, my questions have answers now.) > Yes. 'Free' memory is basically wasted and so the kernel tries to limit > it, subject to having sufficient free memory to meet page-faults. Most > of your RAM should be wired, active or inactive. Inactive memory will > start at 0 and grow as active pages are released. OK, sounds clear. >> What should I do ? > Nothing. Why do you think you have a problem? As long as I was not sure what "inactive" means, I was not sure of what to think. My first guess was that "inactive" memory are like "active" memory but was not accessed for some time, and as such have more priority to be pages out to swap than "active" memory. So i tried to search for the real definition of what "inactive" memory is, and what I found was a little bit fuzzy. >> Do you have any tools to monitor memory usage of processes ? > ps(1) ps(1) is ok to check snapshots of process states, but not the evolution of the memory usages. I looked for a tool mainly to find processes with memory leaks. From owner-freebsd-stable@FreeBSD.ORG Wed Jul 26 12:52:55 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 061E416A4E6 for ; Wed, 26 Jul 2006 12:52:55 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail-gw4.york.ac.uk (mail-gw4.york.ac.uk [144.32.128.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D1E343D4C for ; Wed, 26 Jul 2006 12:52:53 +0000 (GMT) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from buffy.york.ac.uk (buffy-128.york.ac.uk [144.32.128.160]) by mail-gw4.york.ac.uk (8.13.6/8.13.6) with ESMTP id k6QCqo0T021157 for ; Wed, 26 Jul 2006 13:52:50 +0100 (BST) Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.13.6/8.13.6) with ESMTP id k6QCqoxm023668 for ; Wed, 26 Jul 2006 13:52:50 +0100 (BST) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: (from ga9@localhost) by buffy.york.ac.uk (8.13.6/8.13.6/Submit) id k6QCqn2w023667 for freebsd-stable@freebsd.org; Wed, 26 Jul 2006 13:52:49 +0100 (BST) (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin.atkinson@ury.york.ac.uk using -f From: Gavin Atkinson To: freebsd-stable@freebsd.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 26 Jul 2006 13:52:48 +0100 Message-Id: <1153918368.22691.34.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin.atkinson@ury.york.ac.uk Subject: Filesystem full: out of inodes - possibly ataraid bug? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 12:52:55 -0000 Hi all, I'm seeing a strange problem on two of my servers (both 6.0-RELEASE). Both seem to have corrupted their filesystems in such a way that no more files can be created because they are apparently out of inodes, even though "df -i" suggests otherwise... A reboot doesn't fix this: system1: system1# touch /usr/test /usr: create/symlink failed, no inodes free touch: /usr/test: No space left on device system1# uptime 12:42PM up 6 mins, 1 user, load averages: 0.00, 0.07, 0.05 system1# df -i Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mounted on /dev/ar0s1a 594926 64174 483158 12% 931 76123 1% / devfs 1 1 0 100% 0 0 100% /dev /dev/ar0s1h 47164554 4 43391386 0% 2 6099964 0% /spare /dev/ar0s1d 507630 22 466998 0% 11 65779 0% /tmp /dev/ar0s1g 15231278 322924 13689852 2% 18411 1959955 1% /usr /dev/ar0s1f 6090094 1626 5601262 0% 158 800608 0% /var /dev/ar0s1e 2026030 6 1863942 0% 3 282619 0% /var/tmp system1# tail -20 /var/log/messages Jul 26 12:42:03 system1 kernel: pid 539 (touch), uid 0 inumber 2 on /usr: out of inodes system1# uname -a FreeBSD xxx 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Wed Nov 2 19:07:38 UTC 2005 root@rat.samsco.home:/usr/obj/usr/src/sys/GENERIC amd64 system2: root@system2:/root# touch /test /: create/symlink failed, no inodes free touch: /test: No space left on device root@system2:/root# df -i / Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mounted on /dev/ar0s1a 495726 132474 323594 29% 1519 62735 2% / root@system2:/root# uname -a FreeBSD xxx 6.0-RELEASE-p5 FreeBSD 6.0-RELEASE-p5 #3: Thu Mar 2 18:26:48 GMT 2006 root@xxx:/usr/obj/usr/src/sys/XXX i386 The only connection between these two systems is that both are mirrored using ataraid - system1 uses FreeBSD PseudoRAID which is currently running in DEGRADED mode (another disk is on order), and system2 has an Adaptec 1200A soft-RAID card (Promise chipset), which lost a disk (but has since been repaired) at some point in the past. With system2, the problems started at the same time as the disk replacement, I have no idea if the times correlate with system1 though. I run many FreeBSD machines without ataraid, and several with ataraid that have never lost a disk, and none of these systems have had any issues. Hence me wondering if some aspect of ataraid is flawed when it comes to handling degraded arrays. With system1, background fscks during reboot fail with: Jul 21 10:24:23 system1 kernel: pid 525 (fsck_ufs), uid 0 inumber 3 on /usr: out of inodes A full fsck (by setting background_fsck="NO" and fsck_y_enable="YES" in /etc/rc.conf and reboot) fixed the problems. I can't take system2 down to perform a full fsck at the moment. At the moment, system2 can't be taken to 6.1-R due to the NFS slowdown bug. I will take system1 to 6.1-R, although I guess it won't make any difference as presumably the damage is already done. I can provide dumps and images of the affected filesystems to trusted developers. Gavin From owner-freebsd-stable@FreeBSD.ORG Wed Jul 26 13:17:19 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 05BB216A4DD for ; Wed, 26 Jul 2006 13:17:19 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC07843D53 for ; Wed, 26 Jul 2006 13:17:17 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (szcdsd@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id k6QDHAOd091313 for ; Wed, 26 Jul 2006 15:17:15 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id k6QDH9rH091312; Wed, 26 Jul 2006 15:17:09 +0200 (CEST) (envelope-from olli) Date: Wed, 26 Jul 2006 15:17:09 +0200 (CEST) Message-Id: <200607261317.k6QDH9rH091312@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG In-Reply-To: X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.0-20051224 ("Ronay") (UNIX) (FreeBSD/4.11-STABLE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Wed, 26 Jul 2006 15:17:15 +0200 (CEST) Cc: Subject: Re: Memory management X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 13:17:19 -0000 Stephane Dupille wrote: > Peter Jeremy écrit : > > > As time passing by, the memory fills up. When the machine starts, > > > memory is occupied to 30 %, and after two or three weeks memory is > > > occupied to 100 % and it begins to use swap. > > How are you monitoring memory usage? > > Using top, mainly. And ps, swapinfo, vmstat... > > > Do you mean 'swap' or 'page'? > > swap. Note that it is normal that processes get swapped out if they haven't been in the run queue for a very long time and "free" memory has reached near zero (which is also normal). That's a feature, because it improves efficiency in most situations, because more RAM is available to processes which really need it. For example, if you use X11 and don't log into syscons' virtual terminals (/dev/vty*), you will notice that the getty(8) processes will be swapped out after some time when there is not many "free" memory left: PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 382 root 3 0 996K 0K ttyin 0:00 0.00% 0.00% 383 root 3 0 996K 0K ttyin 0:00 0.00% 0.00% 384 root 3 0 996K 0K ttyin 0:00 0.00% 0.00% 385 root 3 0 996K 0K ttyin 0:00 0.00% 0.00% 386 root 3 0 996K 0K ttyin 0:00 0.00% 0.00% If you want to check whether there's a _real_ shortage of RAM (or a memory leak somewhere), a good way is to watch the "po" and "sr" columns in the output of "vmstat 5": procs memory page disks faults cpu r b w avm fre flt re pi po fr sr ad0 da0 in sy cs us sy id 1 0 0 39960 44944 62 0 0 0 61 3 0 0 157 6 36 2 1 97 0 0 0 39960 44944 2 0 0 0 0 0 0 0 1132 19 8 0 0 100 0 0 0 39960 44944 1 0 0 0 0 0 0 1 1132 19 8 0 0 100 0 0 0 34300 44944 1 0 0 0 0 0 0 0 1132 23 9 0 0 100 The "po" (page-out) column indicates paging activity, i.e. data is moved to the swap. The "sr" (scan-rate) column measures the speed at which inactive pages are scanned for becomeing cache or "free" pages; this number is a good measure of the "pressure" on the VM system. If both numbers are almost always near zero, you don't have to worry at all. If the numbers are constantly high, you either have a leak somewhere that you need to discover, or you need to add more RAM to your machine. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. From owner-freebsd-stable@FreeBSD.ORG Wed Jul 26 13:25:09 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6EA6116A4DD for ; Wed, 26 Jul 2006 13:25:09 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 834F443D62 for ; Wed, 26 Jul 2006 13:25:04 +0000 (GMT) (envelope-from freebsd-listen@fabiankeil.de) Received: (qmail 26250 invoked from network); 26 Jul 2006 13:25:02 -0000 Received: from unknown (HELO localhost) (775067@[217.50.135.234]) (envelope-sender ) by smtprelay02.ispgateway.de (qmail-ldap-1.03) with SMTP for ; 26 Jul 2006 13:25:02 -0000 Date: Wed, 26 Jul 2006 15:24:40 +0200 From: Fabian Keil To: peter.thoenen@yahoo.com Message-ID: <20060726152440.647fca4e@localhost> In-Reply-To: <20060715185948.117e9024@localhost> References: <20060715132007.61a5dbf5@localhost> <20060715160110.45064.qmail@web51902.mail.yahoo.com> <20060715185948.117e9024@localhost> X-Mailer: Sylpheed-Claws 2.3.1 (GTK+ 2.8.19; i386-portbld-freebsd6.1) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2006-08-19.asc Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_YW5EOluSz=nTM0Je0IZXF/V"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: Robert Watson , freebsd-stable@freebsd.org Subject: Re: FreeBSD 6.1 Tor issues (Once More, with Feeling) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 13:25:09 -0000 --Sig_YW5EOluSz=nTM0Je0IZXF/V Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Fabian Keil wrote: > Peter Thoenen wrote: >=20 > > To you have pf running? If so can you turn it off for a bit a see if > > you still crash. On my box I was getting all sorts of witness kbd > > backtraces on pf and since turning pf off (maybe a week ago), > > haven't crashed yet. Going to let it keep running unmetered for > > another 2 weeks and see if I crash or not. How is it going, Peter, still running? =20 > I'm running Tor jailed and use PF for NAT, port forwarding and > filtering: http://tor.fabiankeil.de/pf-stats/ >=20 > So far I didn't see a single PF related complaint from witness, > but I'll try disabling PF in a few days anyway. It took a little longer than I thought, but I finally disabled PF today and switched to natd. > At the moment I'm still testing if enabling polling really > increases the uptime. I'm still not sure, however polling made it possible to use fxp0 without acpi, the hangs still occur and the serial console still becomes unresponsive though. On another wild guess I switched Tor's threading library from libpthread to libthr. While it doesn't seem to affect the uptime, it makes Tor's cpu usage visible in top, so maybe it would be a good default for tor-devel? Fabian --=20 http://www.fabiankeil.de/ --Sig_YW5EOluSz=nTM0Je0IZXF/V Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEx20sjV8GA4rMKUQRAg+OAKDewVEt3vPfCnj2m2JecxveD9hujACg5DEN zvNLxgyM1cSY1vwvT2uXM2Q= =CI5T -----END PGP SIGNATURE----- --Sig_YW5EOluSz=nTM0Je0IZXF/V-- From owner-freebsd-stable@FreeBSD.ORG Wed Jul 26 14:41:01 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D46D016A4DD for ; Wed, 26 Jul 2006 14:41:01 +0000 (UTC) (envelope-from henrik@brixandersen.dk) Received: from ns2.pil.dk (ns2.pil.dk [195.41.47.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 679B143D46 for ; Wed, 26 Jul 2006 14:41:01 +0000 (GMT) (envelope-from henrik@brixandersen.dk) Received: from osgiliath.brixandersen.dk (osgiliath.brixandersen.dk [87.53.223.189]) by ns2.pil.dk (Postfix) with ESMTP id E52F17BA0E4 for ; Wed, 26 Jul 2006 16:40:59 +0200 (CEST) Received: by osgiliath.brixandersen.dk (Postfix, from userid 1000) id 30F73761; Wed, 26 Jul 2006 16:40:59 +0200 (CEST) Date: Wed, 26 Jul 2006 16:40:58 +0200 From: Henrik Brix Andersen To: freebsd-stable@freebsd.org Message-ID: <20060726144058.GD3077@osgiliath.opasia.dk> Mail-Followup-To: freebsd-stable@freebsd.org References: <20060720224632.GB31459@osgiliath.brixandersen.dk> <44C00B40.2010901@errno.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZARJHfwaSJQLOEUz" Content-Disposition: inline In-Reply-To: <44C00B40.2010901@errno.com> X-PGP-Key: http://dev.gentoo.org/~brix/files/HenrikBrixAndersen.asc User-Agent: Mutt/1.5.11 Subject: Re: "scan stuck" with if_iwi(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 14:41:01 -0000 --ZARJHfwaSJQLOEUz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 20, 2006 at 04:01:20PM -0700, Sam Leffler wrote: > The basic problem is your card is losing sync w/ the ap. I don't know > what the local conditions are but I've seen this a lot w/ iwi; there's > nothing we can do in the driver if you want to be able to roam. Update: this was just fixed in iwi(4) in -CURRENT (by increasing the beacon miss threshold for the iwi(4) driver from 7 to 10). Should 10 not be enough, it is now also possible to set the beacon miss threshold using ifconfig. Thanks to Sam for helping and for applying my patches to -CURRENT. This functionality should be MFC'd in two weeks. Regards, Brix --=20 Henrik Brix Andersen --ZARJHfwaSJQLOEUz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (GNU/Linux) Comment: GnuPG signed iD8DBQFEx376v+Q4flTiePgRAqMaAJ9dSL7wByLrSNwxnPjdTuiNW0jlHgCfWDAQ fqaQcdJQq33VffZp0ENw3YQ= =iOpJ -----END PGP SIGNATURE----- --ZARJHfwaSJQLOEUz-- From owner-freebsd-stable@FreeBSD.ORG Wed Jul 26 15:04:20 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEE3916A4DF for ; Wed, 26 Jul 2006 15:04:20 +0000 (UTC) (envelope-from woo@alfredpub.com) Received: from grayce.net (92.Red-88-11-240.dynamicIP.rima-tde.net [88.11.240.92]) by mx1.FreeBSD.org (Postfix) with SMTP id 9C66F43D46 for ; Wed, 26 Jul 2006 15:04:19 +0000 (GMT) (envelope-from woo@alfredpub.com) Message-ID: <000001c6b0c4$3b5fcad0$3deba8c0@gzl43> From: "Felicienne Woolley" To: freebsd-stable@freebsd.org Date: Wed, 26 Jul 2006 08:00:28 -0700 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: lauydVjlAGRA X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Felicienne Woolley List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 15:04:21 -0000 =20 VAjLIlUM from 1 , 25 $ CIjALIlS from 3 , 75 $ AMjBlIEN VlljAGRA from 3 , 35 $ =20 http://www.sklodamisaron.com =20 , , , , chorus of groans. Right. On the way in here I noticed that right next door is a drinking parlor by the name of Dust on Your Tonsils. I can only assume that is a little joke and they intend to wash the dust From owner-freebsd-stable@FreeBSD.ORG Wed Jul 26 16:13:31 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8DCEC16A4EA for ; Wed, 26 Jul 2006 16:13:31 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 344E743D5E for ; Wed, 26 Jul 2006 16:10:19 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id k6QGA3S5086079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 26 Jul 2006 09:10:05 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <44C793DB.5090900@errno.com> Date: Wed, 26 Jul 2006 09:10:03 -0700 From: Sam Leffler User-Agent: Thunderbird 1.5.0.4 (X11/20060724) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20060720224632.GB31459@osgiliath.brixandersen.dk> <44C00B40.2010901@errno.com> <20060726144058.GD3077@osgiliath.opasia.dk> In-Reply-To: <20060726144058.GD3077@osgiliath.opasia.dk> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: "scan stuck" with if_iwi(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 16:13:31 -0000 Henrik Brix Andersen wrote: > On Thu, Jul 20, 2006 at 04:01:20PM -0700, Sam Leffler wrote: >> The basic problem is your card is losing sync w/ the ap. I don't know >> what the local conditions are but I've seen this a lot w/ iwi; there's >> nothing we can do in the driver if you want to be able to roam. > > Update: this was just fixed in iwi(4) in -CURRENT (by increasing the > beacon miss threshold for the iwi(4) driver from 7 to 10). Should 10 > not be enough, it is now also possible to set the beacon miss > threshold using ifconfig. > > Thanks to Sam for helping and for applying my patches to > -CURRENT. This functionality should be MFC'd in two weeks. Thanks for your help but understand this is not necessarily a solution; just the addition of a knob. The linux driver already used 7 consecutive beacon misses to trigger roaming so I'm not sure why 10 is an improvement but given that adding 300ms (typical) lag makes you happy I wasn't going to argue :) Sam From owner-freebsd-stable@FreeBSD.ORG Wed Jul 26 16:13:38 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9318416A4FE for ; Wed, 26 Jul 2006 16:13:38 +0000 (UTC) (envelope-from ducrot@poupinou.org) Received: from poup.poupinou.org (poup.poupinou.org [195.101.94.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B5A543E0A for ; Wed, 26 Jul 2006 16:10:20 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from ducrot by poup.poupinou.org with local (Exim) id 1G5lxI-0004x4-00; Wed, 26 Jul 2006 18:09:52 +0200 Date: Wed, 26 Jul 2006 18:09:52 +0200 To: Mike Jakubik Message-ID: <20060726160952.GW17014@poupinou.org> References: <44C63DFD.5040401@rogers.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44C63DFD.5040401@rogers.com> User-Agent: Mutt/1.5.9i From: Bruno Ducrot Cc: stable@freebsd.org Subject: Re: Monitoring temperature with acpi (sysctls) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 16:13:38 -0000 On Tue, Jul 25, 2006 at 11:51:25AM -0400, Mike Jakubik wrote: > I need to be able to get the cpu and fan information from my > motherboard, however none of the monitoring utilities in the ports seems > to support my motherboard (Supermicro PDSMi, Intel E7230 (Mukilteo) > Chipset). On my older VIA based motherboards and some Nvidia, i can get > this information using ACPI and the hw.acpi.thermal sysctl. This however > is not available on this motherboard. Would this be a shortcoming of the > motherboards ACPI implementation, or a lack of support by freebsd? Does this one support IPMI? -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. From owner-freebsd-stable@FreeBSD.ORG Wed Jul 26 16:30:20 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B732F16A4DA for ; Wed, 26 Jul 2006 16:30:20 +0000 (UTC) (envelope-from henrik@brixandersen.dk) Received: from ns2.pil.dk (ns2.pil.dk [195.41.47.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 441BA43D46 for ; Wed, 26 Jul 2006 16:30:19 +0000 (GMT) (envelope-from henrik@brixandersen.dk) Received: from osgiliath.brixandersen.dk (osgiliath.brixandersen.dk [87.53.223.189]) by ns2.pil.dk (Postfix) with ESMTP id E38C47BA837 for ; Wed, 26 Jul 2006 18:30:18 +0200 (CEST) Received: by osgiliath.brixandersen.dk (Postfix, from userid 1000) id 526A1761; Wed, 26 Jul 2006 18:30:18 +0200 (CEST) Date: Wed, 26 Jul 2006 18:30:18 +0200 From: Henrik Brix Andersen To: freebsd-stable@freebsd.org Message-ID: <20060726163017.GB5856@osgiliath.opasia.dk> Mail-Followup-To: freebsd-stable@freebsd.org References: <20060720224632.GB31459@osgiliath.brixandersen.dk> <44C00B40.2010901@errno.com> <20060726144058.GD3077@osgiliath.opasia.dk> <44C793DB.5090900@errno.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline In-Reply-To: <44C793DB.5090900@errno.com> X-PGP-Key: http://dev.gentoo.org/~brix/files/HenrikBrixAndersen.asc User-Agent: Mutt/1.5.11 Subject: Re: "scan stuck" with if_iwi(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 16:30:20 -0000 --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 26, 2006 at 09:10:03AM -0700, Sam Leffler wrote: > Thanks for your help but understand this is not necessarily a solution; > just the addition of a knob. I know. > The linux driver already used 7 consecutive beacon misses to trigger > roaming so I'm not sure why 10 is an improvement but given that > adding 300ms (typical) lag makes you happy I wasn't going to argue > :) Actually, it seems the linux driver uses a threshold of 8 missed beacons for roaming and a threshold of 24 for disassociation. But you're correct - this only solves the issue of being disassociated every 3 minutes; it doesn't solve the problem behind "scan stuck", but this problem is not present here anymore since the station is not disassociated all the time. I'll try to address the scan stuck problem when I find some more time. Regards, Brix --=20 Henrik Brix Andersen --YiEDa0DAkWCtVeE4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (GNU/Linux) Comment: GnuPG signed iD8DBQFEx5iZv+Q4flTiePgRAtr6AKCgEbM70nemTUuSyI09G80U88kGXwCdGOcf sGCSoPdh0GC9F3Jq3w40WYg= =SQxB -----END PGP SIGNATURE----- --YiEDa0DAkWCtVeE4-- From owner-freebsd-stable@FreeBSD.ORG Wed Jul 26 17:05:36 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1FC6A16A5DF for ; Wed, 26 Jul 2006 17:05:36 +0000 (UTC) (envelope-from sven@dmv.com) Received: from smtp-gw-cl-d.dmv.com (smtp-gw-cl-d.dmv.com [216.240.97.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76B3C43D53 for ; Wed, 26 Jul 2006 17:05:35 +0000 (GMT) (envelope-from sven@dmv.com) Received: from mail-gw-cl-a.dmv.com (mail-gw-cl-a.dmv.com [216.240.97.38]) by smtp-gw-cl-d.dmv.com (8.12.10/8.12.10) with ESMTP id k6QH5Vk1010140; Wed, 26 Jul 2006 13:05:31 -0400 (EDT) (envelope-from sven@dmv.com) Received: from [64.45.134.154] (dogpound.dyndns.org [64.45.134.154]) (authenticated bits=0) by mail-gw-cl-a.dmv.com (8.12.9/8.12.9) with ESMTP id k6QH5QDs003263; Wed, 26 Jul 2006 13:05:30 -0400 (EDT) (envelope-from sven@dmv.com) Message-ID: <44C7A147.9010106@dmv.com> Date: Wed, 26 Jul 2006 13:07:19 -0400 From: Sven Willenberger User-Agent: Thunderbird 1.5.0.4 (X11/20060601) MIME-Version: 1.0 To: Feargal Reilly References: <20060721140005.5365e4b7@mablung.edhellond.fbi.ie> <200607241514.k6OFERos052696@lurza.secnetix.de> <20060724164832.11683f08@mablung.edhellond.fbi.ie> In-Reply-To: <20060724164832.11683f08@mablung.edhellond.fbi.ie> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.48 on 216.240.97.42 X-Scanned-By: MIMEDefang 2.48 on 216.240.97.38 Cc: freebsd-stable@freebsd.org Subject: Re: filesystem full error with inumber X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 17:05:36 -0000 Feargal Reilly presumably uttered the following on 07/24/06 11:48: > On Mon, 24 Jul 2006 17:14:27 +0200 (CEST) > Oliver Fromme wrote: > >> Nobody else has answered so far, so I try to give it a shot ... >> >> The "filesystem full" error can happen in three cases: >> 1. The file system is running out of data space. >> 2. The file system is running out of inodes. >> 3. The file system is running out of non-fragmented blocks. >> >> The third case can only happen on extremely fragmented >> file systems which happens very rarely, but maybe it's >> a possible cause of your problem. > > I rebooted that server, and df then reported that disk at 108%, > so it appears that df was reporting incorrect figures prior to > the reboot. Having cleaned up, it appears by my best > calculations to be showing correct figures now. > >> > kern.maxfiles: 20000 >> > kern.openfiles: 3582 >> >> Those have nothing to do with "filesystem full". >> > > Yeah, that's what I figured. > >> > Looking again at dumpfs, it appears to say that this is >> > formatted with a block size of 8K, and a fragment size of >> > 2K, but tuning(7) says: [...] >> > Reading this makes me think that when this server was >> > installed, the block size was dropped from the 16K default >> > to 8K for performance reasons, but the fragment size was >> > not modified accordingly. >> > >> > Would this be the root of my problem? >> >> I think a bsize/fsize ratio of 4/1 _should_ work, but it's >> not widely used, so there might be bugs hidden somewhere. >> > > Such as df not reporting the actual data usage, which is now my > best working theory. I don't know what df bases it's figures on, > perhaps it either slowly got out of sync, or more likely, got > things wrong once the disk filled up. > > I'll monitor it to see if this happens again, but hopefully > won't keep that configuration around for too much longer anyway. > > Thanks, > -fr. > One of my machines that I recently upgraded to 6.1 (6.1-RELEASE-p3) is also exhibiting df reporting wrong data usage numbers. Notice the negative "Used" numbers below: > df -h Filesystem Size Used Avail Capacity Mounted on /dev/da0s1a 496M 63M 393M 14% / devfs 1.0K 1.0K 0B 100% /dev /dev/da0s1e 989M -132M 1.0G -14% /tmp /dev/da0s1f 15G 478M 14G 3% /usr /dev/da0s1d 15G -1.0G 14G -8% /var /dev/md0 496M 228K 456M 0% /var/spool/MIMEDefang devfs 1.0K 1.0K 0B 100% /var/named/dev Sven From owner-freebsd-stable@FreeBSD.ORG Wed Jul 26 18:07:38 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A79F16A4DA for ; Wed, 26 Jul 2006 18:07:38 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DFD443D53 for ; Wed, 26 Jul 2006 18:07:37 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id k6QI7aIG086982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 26 Jul 2006 11:07:37 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <44C7AF68.3090109@errno.com> Date: Wed, 26 Jul 2006 11:07:36 -0700 From: Sam Leffler User-Agent: Thunderbird 1.5.0.4 (X11/20060724) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20060720224632.GB31459@osgiliath.brixandersen.dk> <44C00B40.2010901@errno.com> <20060726144058.GD3077@osgiliath.opasia.dk> <44C793DB.5090900@errno.com> <20060726163017.GB5856@osgiliath.opasia.dk> In-Reply-To: <20060726163017.GB5856@osgiliath.opasia.dk> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: "scan stuck" with if_iwi(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 18:07:38 -0000 Henrik Brix Andersen wrote: > On Wed, Jul 26, 2006 at 09:10:03AM -0700, Sam Leffler wrote: >> Thanks for your help but understand this is not necessarily a solution; >> just the addition of a knob. > > I know. Sure, it was for others. > >> The linux driver already used 7 consecutive beacon misses to trigger >> roaming so I'm not sure why 10 is an improvement but given that >> adding 300ms (typical) lag makes you happy I wasn't going to argue >> :) > > Actually, it seems the linux driver uses a threshold of 8 missed > beacons for roaming and a threshold of 24 for disassociation. Which version are you looking at? The numbers in iwi are from the code in linux-2.6.17; maybe it's been changed again in the code on sourceforge? The one thing the linux driver does differently is scan for a new ap _before_ roaming which the current net80211 code cannot do. Unfortunately the code to do that has been sitting outside the tree for a long time and it's unclear if it'll ever come in... > > But you're correct - this only solves the issue of being disassociated > every 3 minutes; it doesn't solve the problem behind "scan stuck", but > this problem is not present here anymore since the station is not > disassociated all the time. > > I'll try to address the scan stuck problem when I find some more time. Thank you. Sam From owner-freebsd-stable@FreeBSD.ORG Wed Jul 26 18:11:29 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE3F416A4DA for ; Wed, 26 Jul 2006 18:11:29 +0000 (UTC) (envelope-from ohartman@mail.uni-mainz.de) Received: from mailgate1.zdv.Uni-Mainz.DE (mailgate1.zdv.Uni-Mainz.DE [134.93.178.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6455E43D46 for ; Wed, 26 Jul 2006 18:11:28 +0000 (GMT) (envelope-from ohartman@mail.uni-mainz.de) Received: from [192.168.1.128] (e178003216.adsl.alicedsl.de [85.178.3.216]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate1.zdv.Uni-Mainz.DE (Postfix) with ESMTP id 870B230046AD; Wed, 26 Jul 2006 20:11:27 +0200 (CEST) Message-ID: <44C7B04B.8050102@mail.uni-mainz.de> Date: Wed, 26 Jul 2006 20:11:23 +0200 From: "O. Hartmann" User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: Bruno Ducrot References: <44C63DFD.5040401@rogers.com> <20060726160952.GW17014@poupinou.org> In-Reply-To: <20060726160952.GW17014@poupinou.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-mainz.de Cc: Mike Jakubik , stable@freebsd.org Subject: Re: Monitoring temperature with acpi (sysctls) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 18:11:29 -0000 Bruno Ducrot wrote: > On Tue, Jul 25, 2006 at 11:51:25AM -0400, Mike Jakubik wrote: > >> I need to be able to get the cpu and fan information from my >> motherboard, however none of the monitoring utilities in the ports seems >> to support my motherboard (Supermicro PDSMi, Intel E7230 (Mukilteo) >> Chipset). On my older VIA based motherboards and some Nvidia, i can get >> this information using ACPI and the hw.acpi.thermal sysctl. This however >> is not available on this motherboard. Would this be a shortcoming of the >> motherboards ACPI implementation, or a lack of support by freebsd? >> > > Does this one support IPMI? > > ASUS A8N32-SLI Deluxe not ... ipmi driver in kernel installed, but finds no device. From owner-freebsd-stable@FreeBSD.ORG Wed Jul 26 18:15:40 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 258A616A4DA for ; Wed, 26 Jul 2006 18:15:40 +0000 (UTC) (envelope-from henrik@brixandersen.dk) Received: from ns2.pil.dk (ns2.pil.dk [195.41.47.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 16C2543D6E for ; Wed, 26 Jul 2006 18:15:36 +0000 (GMT) (envelope-from henrik@brixandersen.dk) Received: from osgiliath.brixandersen.dk (osgiliath.brixandersen.dk [87.53.223.189]) by ns2.pil.dk (Postfix) with ESMTP id 82F317BA733 for ; Wed, 26 Jul 2006 20:15:35 +0200 (CEST) Received: by osgiliath.brixandersen.dk (Postfix, from userid 1000) id 13C5D761; Wed, 26 Jul 2006 20:15:35 +0200 (CEST) Date: Wed, 26 Jul 2006 20:15:34 +0200 From: Henrik Brix Andersen To: freebsd-stable@freebsd.org Message-ID: <20060726181534.GD5856@osgiliath.opasia.dk> Mail-Followup-To: freebsd-stable@freebsd.org References: <20060720224632.GB31459@osgiliath.brixandersen.dk> <44C00B40.2010901@errno.com> <20060726144058.GD3077@osgiliath.opasia.dk> <44C793DB.5090900@errno.com> <20060726163017.GB5856@osgiliath.opasia.dk> <44C7AF68.3090109@errno.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tjCHc7DPkfUGtrlw" Content-Disposition: inline In-Reply-To: <44C7AF68.3090109@errno.com> X-PGP-Key: http://dev.gentoo.org/~brix/files/HenrikBrixAndersen.asc User-Agent: Mutt/1.5.11 Subject: Re: "scan stuck" with if_iwi(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 18:15:40 -0000 --tjCHc7DPkfUGtrlw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 26, 2006 at 11:07:36AM -0700, Sam Leffler wrote: > Sure, it was for others. Ah :) > Which version are you looking at? The numbers in iwi are from the code > in linux-2.6.17; maybe it's been changed again in the code on > sourceforge? I was looking in the ipw2200.h header file from ipw2200-1.1.2 - but the values are the same in version 1.1.1 of the driver, which is present in linux-2.6.17. #define IPW_MB_ROAMING_THRESHOLD_DEFAULT 8 #define IPW_MB_DISASSOCIATE_THRESHOLD_DEFAULT 3*IPW_MB_ROAMING_TH= RESHOLD_DEFAULT > The one thing the linux driver does differently is scan for a new ap > _before_ roaming which the current net80211 code cannot do. > Unfortunately the code to do that has been sitting outside the tree > for a long time and it's unclear if it'll ever come in... Oh? Sounds interesting, where can I find these patches? Regards, Brix --=20 Henrik Brix Andersen --tjCHc7DPkfUGtrlw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (GNU/Linux) Comment: GnuPG signed iD8DBQFEx7FGv+Q4flTiePgRApi+AJ9nL2MGpRYjVKHbh37zSvO0CI0WugCeLrWQ sjtZgLiZBO3sjupJmLi8t7Y= =Fz65 -----END PGP SIGNATURE----- --tjCHc7DPkfUGtrlw-- From owner-freebsd-stable@FreeBSD.ORG Wed Jul 26 18:47:08 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8816316A4DA for ; Wed, 26 Jul 2006 18:47:08 +0000 (UTC) (envelope-from jandrese@mitre.org) Received: from smtp-bedford.mitre.org (smtpproxy1.mitre.org [192.160.51.76]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24E2143D55 for ; Wed, 26 Jul 2006 18:47:06 +0000 (GMT) (envelope-from jandrese@mitre.org) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with SMTP id k6QIl6iA022974 for ; Wed, 26 Jul 2006 14:47:06 -0400 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id 01A12BEFB for ; Wed, 26 Jul 2006 14:47:05 -0400 (EDT) Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with ESMTP id k6QIl5nN022966 for ; Wed, 26 Jul 2006 14:47:05 -0400 Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 14:47:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Jul 2006 14:47:04 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: wine: ld-elf.so.1 not found Thread-Index: Acaw4+OFVqW7sJGGQlm3Ac3lA2RNtQ== From: "Andresen, Jason" To: X-OriginalArrivalTime: 26 Jul 2006 18:47:05.0739 (UTC) FILETIME=[E4169DB0:01C6B0E3] Subject: wine: ld-elf.so.1 not found X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 18:47:08 -0000 I'm having a very strange problem with Wine. It apparently refuses to see ld when starting: (72 ~): wine ELF interpreter /libexec/ld-elf.so.1 not found Even though it's obviously on the system: (74 ~): ls /libexec ld-elf.so.1 ld-elf.so.1.old Ktrace doesn't really provide much of anything helpful since even ld won't start: (77 ~): ktrace wine ELF interpreter /libexec/ld-elf.so.1 not found [1] 90037 abort ktrace wine 134 (78 ~): kdump 90037 ktrace RET ktrace 0 90037 ktrace CALL execve(0xbfbfe170,0xbfbfe698,0xbfbfe6a0) 90037 ktrace NAMI "/bin/wine" 90037 ktrace RET execve -1 errno 2 No such file or directory 90037 ktrace CALL execve(0xbfbfe170,0xbfbfe698,0xbfbfe6a0) 90037 ktrace NAMI "/sbin/wine" 90037 ktrace RET execve -1 errno 2 No such file or directory 90037 ktrace CALL execve(0xbfbfe170,0xbfbfe698,0xbfbfe6a0) 90037 ktrace NAMI "/usr/bin/wine" 90037 ktrace RET execve -1 errno 2 No such file or directory 90037 ktrace CALL execve(0xbfbfe170,0xbfbfe698,0xbfbfe6a0) 90037 ktrace NAMI "/usr/games/wine" 90037 ktrace RET execve -1 errno 2 No such file or directory 90037 ktrace CALL execve(0xbfbfe170,0xbfbfe698,0xbfbfe6a0) 90037 ktrace NAMI "/usr/sbin/wine" 90037 ktrace RET execve -1 errno 2 No such file or directory 90037 ktrace CALL execve(0xbfbfe170,0xbfbfe698,0xbfbfe6a0) 90037 ktrace NAMI "/usr/local/bin/wine" 90037 ktrace NAMI "/libexec/ld-elf.so.1" I'm a bit behind on the releases, but this just seem so odd regardless: (79 ~): uname -a FreeBSD escaflowne.ceyah.org 6.0-RELEASE FreeBSD 6.0-RELEASE #1: Tue Jun 20 11:19:53 EDT 2006 root@escaflowne.ceyah.org:/backup/obj/data/src/sys/ESCAFLOWNE i386 Recompiling Wine makes no difference, and it is the only application on my system that appears to be affected. I'm using Wine 0.9.17,1. I'm really stumped as to what the problem is. From owner-freebsd-stable@FreeBSD.ORG Wed Jul 26 18:49:07 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6FEBA16A4E6 for ; Wed, 26 Jul 2006 18:49:07 +0000 (UTC) (envelope-from daved@tamu.edu) Received: from sr-5-int.cis.tamu.edu (smtp-relay.tamu.edu [165.91.22.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59FA143D4C for ; Wed, 26 Jul 2006 18:49:06 +0000 (GMT) (envelope-from daved@tamu.edu) Received: from localhost (localhost.tamu.edu [127.0.0.1]) by sr-5-int.cis.tamu.edu (Postfix) with ESMTP id A6B99CB0; Wed, 26 Jul 2006 13:49:05 -0500 (CDT) Received: from [128.194.169.56] (dhcp-qip-128-194-169-56.net.tamu.edu [128.194.169.56]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by sr-5-int.cis.tamu.edu (Postfix) with ESMTP id 1D942CA9; Wed, 26 Jul 2006 13:49:05 -0500 (CDT) In-Reply-To: <20060726160952.GW17014@poupinou.org> References: <44C63DFD.5040401@rogers.com> <20060726160952.GW17014@poupinou.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1--461118532; protocol="application/pkcs7-signature" Message-Id: <016E6A0B-E3E4-4444-BD27-24E75C784788@tamu.edu> From: David Duchscher Date: Wed, 26 Jul 2006 13:49:00 -0500 To: Bruno Ducrot X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: amavisd-new at tamu.edu X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Mike Jakubik , stable@freebsd.org Subject: Re: Monitoring temperature with acpi (sysctls) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 18:49:07 -0000 --Apple-Mail-1--461118532 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Jul 26, 2006, at 11:09 AM, Bruno Ducrot wrote: > On Tue, Jul 25, 2006 at 11:51:25AM -0400, Mike Jakubik wrote: >> I need to be able to get the cpu and fan information from my >> motherboard, however none of the monitoring utilities in the ports >> seems >> to support my motherboard (Supermicro PDSMi, Intel E7230 (Mukilteo) >> Chipset). On my older VIA based motherboards and some Nvidia, i >> can get >> this information using ACPI and the hw.acpi.thermal sysctl. This >> however >> is not available on this motherboard. Would this be a shortcoming >> of the >> motherboards ACPI implementation, or a lack of support by freebsd? > > Does this one support IPMI? Yes, the Supermicro PDSMi supports the IPMI 2.0 module and I can confirm that it works with the IPMI ported driver from current on 6.1. The module is optional so you will have to purchase one for the system, around 0. You will also need the latest BIOS loaded on the motherboard for it to work. http://www.supermicro.com/products/accessories/addon/AOC-IPMI20-E.cfm -- DaveD --Apple-Mail-1--461118532-- From owner-freebsd-stable@FreeBSD.ORG Wed Jul 26 19:00:44 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7ACA116A60B for ; Wed, 26 Jul 2006 19:00:44 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail04.syd.optusnet.com.au (mail04.syd.optusnet.com.au [211.29.132.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED7FA43DAE for ; Wed, 26 Jul 2006 19:00:27 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail04.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k6QJ0GkN002242 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 27 Jul 2006 05:00:18 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.6/8.13.6) with ESMTP id k6QJ0Gw9063817; Thu, 27 Jul 2006 05:00:16 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.6/8.13.6/Submit) id k6QJ0Gd4063816; Thu, 27 Jul 2006 05:00:16 +1000 (EST) (envelope-from peter) Date: Thu, 27 Jul 2006 05:00:15 +1000 From: Peter Jeremy To: Sven Willenberger Message-ID: <20060726190015.GF740@turion.vk2pj.dyndns.org> References: <20060721140005.5365e4b7@mablung.edhellond.fbi.ie> <200607241514.k6OFERos052696@lurza.secnetix.de> <20060724164832.11683f08@mablung.edhellond.fbi.ie> <44C7A147.9010106@dmv.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eNMatiwYGLtwo1cJ" Content-Disposition: inline In-Reply-To: <44C7A147.9010106@dmv.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: freebsd-stable@freebsd.org Subject: Re: filesystem full error with inumber X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 19:00:44 -0000 --eNMatiwYGLtwo1cJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, 2006-Jul-26 13:07:19 -0400, Sven Willenberger wrote: >One of my machines that I recently upgraded to 6.1 (6.1-RELEASE-p3) is also >exhibiting df reporting wrong data usage numbers. What did you upgrade from? Is this UFS1 or UFS2? Does a full fsck fix the problem? --=20 Peter Jeremy --eNMatiwYGLtwo1cJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEx7u//opHv/APuIcRApwPAKC5yNNHuWHyiBk78Z5vR6wqbWh6dwCeOXTp Jlm65QkMw8mhdTdraM+8Ltw= =TI+G -----END PGP SIGNATURE----- --eNMatiwYGLtwo1cJ-- From owner-freebsd-stable@FreeBSD.ORG Wed Jul 26 19:23:09 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1504716A4DF for ; Wed, 26 Jul 2006 19:23:09 +0000 (UTC) (envelope-from sven@dmv.com) Received: from smtp-gw-cl-d.dmv.com (smtp-gw-cl-d.dmv.com [216.240.97.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7A1143D6E for ; Wed, 26 Jul 2006 19:23:02 +0000 (GMT) (envelope-from sven@dmv.com) Received: from mail-gw-cl-b.dmv.com (mail-gw-cl-b.dmv.com [216.240.97.39]) by smtp-gw-cl-d.dmv.com (8.12.10/8.12.10) with ESMTP id k6QJMxk1014820; Wed, 26 Jul 2006 15:23:00 -0400 (EDT) (envelope-from sven@dmv.com) Received: from [64.45.134.154] (dogpound.dyndns.org [64.45.134.154]) (authenticated bits=0) by mail-gw-cl-b.dmv.com (8.12.9/8.12.9) with ESMTP id k6QJMxk9089961; Wed, 26 Jul 2006 15:22:59 -0400 (EDT) (envelope-from sven@dmv.com) Message-ID: <44C7C185.2050601@dmv.com> Date: Wed, 26 Jul 2006 15:24:53 -0400 From: Sven Willenberger User-Agent: Thunderbird 1.5.0.4 (X11/20060601) MIME-Version: 1.0 To: Peter Jeremy References: <20060721140005.5365e4b7@mablung.edhellond.fbi.ie> <200607241514.k6OFERos052696@lurza.secnetix.de> <20060724164832.11683f08@mablung.edhellond.fbi.ie> <44C7A147.9010106@dmv.com> <20060726190015.GF740@turion.vk2pj.dyndns.org> In-Reply-To: <20060726190015.GF740@turion.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.48 on 216.240.97.42 X-Scanned-By: MIMEDefang 2.48 on 216.240.97.39 Cc: freebsd-stable@freebsd.org Subject: Re: filesystem full error with inumber X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 19:23:09 -0000 Peter Jeremy presumably uttered the following on 07/26/06 15:00: > On Wed, 2006-Jul-26 13:07:19 -0400, Sven Willenberger wrote: >> One of my machines that I recently upgraded to 6.1 (6.1-RELEASE-p3) is also >> exhibiting df reporting wrong data usage numbers. > > What did you upgrade from? > Is this UFS1 or UFS2? > Does a full fsck fix the problem? > This was an upgrade from a 5.x system (UFS2); a full fsck did in fact fix the problem (for now). Thanks, Sven From owner-freebsd-stable@FreeBSD.ORG Wed Jul 26 19:43:04 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 79EA616A535 for ; Wed, 26 Jul 2006 19:43:04 +0000 (UTC) (envelope-from phoenix.lists@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFA0443D46 for ; Wed, 26 Jul 2006 19:43:03 +0000 (GMT) (envelope-from phoenix.lists@gmail.com) Received: by nf-out-0910.google.com with SMTP id n29so832950nfc for ; Wed, 26 Jul 2006 12:43:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:organization:to:subject:date:user-agent:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=iHoqAXGDZNIxe5rUQ7Jfosa6e5qrGV4QccXNj1az/b++Y6ixS58ce9bV7eXAC2SMSDxM6ZlMqcjLUEAFHe+qdGDy66HLp+WkST+BA+INPamnL5he+ZCMVOX4YmqW8Hq67SX7tXiy//R62WiPYTS3Agz+yUwkWhTSXxUCBBnDvLk= Received: by 10.49.41.18 with SMTP id t18mr1087152nfj; Wed, 26 Jul 2006 12:43:01 -0700 (PDT) Received: from sp0-host.localdomain ( [85.202.171.205]) by mx.gmail.com with ESMTP id x27sm389963nfb.2006.07.26.12.43.01; Wed, 26 Jul 2006 12:43:01 -0700 (PDT) From: "Lists For Simon Phoenix (phoenix.lists@gmail.com)" Organization: Phoenix Lab. To: stable@freebsd.org Date: Wed, 26 Jul 2006 22:42:53 +0300 User-Agent: KMail/1.9.3 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607262242.54083.phoenix.lists@gmail.com> Cc: Subject: Re: Monitoring temperature with acpi (sysctls) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 19:43:04 -0000 O. Hartmann wrote: > > I need to be able to get the cpu and fan information from my > > motherboard, however none of the monitoring utilities in the ports > > seems to support my motherboard (Supermicro PDSMi, Intel E7230 > > (Mukilteo) Chipset). On my older VIA based motherboards and some > > Nvidia, i can get this information using ACPI and the hw.acpi.thermal > > sysctl. This however is not available on this motherboard. Would this > > be a shortcoming of the motherboards ACPI implementation, or a lack of > > support by freebsd? > > > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > Similar problem to me here with a ASUS A8N32-SLI Deluxe. The older > versions of this motherboard type like A8N-SLI Deluxe and maybe A8N-SLI > Premium had thermal zones in ACPI output, but not the A8N32-SLI. No > temperature, no fanspeed, no thermal zones. ASUS P800 SE i865e chipset - problems too. From owner-freebsd-stable@FreeBSD.ORG Wed Jul 26 20:28:17 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE4AB16A4DA for ; Wed, 26 Jul 2006 20:28:17 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D92543D58 for ; Wed, 26 Jul 2006 20:28:13 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id k6QKSCWU087846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 26 Jul 2006 13:28:12 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <44C7D05C.8000408@errno.com> Date: Wed, 26 Jul 2006 13:28:12 -0700 From: Sam Leffler User-Agent: Thunderbird 1.5.0.4 (X11/20060724) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20060720224632.GB31459@osgiliath.brixandersen.dk> <44C00B40.2010901@errno.com> <20060726144058.GD3077@osgiliath.opasia.dk> <44C793DB.5090900@errno.com> <20060726163017.GB5856@osgiliath.opasia.dk> <44C7AF68.3090109@errno.com> <20060726181534.GD5856@osgiliath.opasia.dk> In-Reply-To: <20060726181534.GD5856@osgiliath.opasia.dk> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: "scan stuck" with if_iwi(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 20:28:17 -0000 Henrik Brix Andersen wrote: > On Wed, Jul 26, 2006 at 11:07:36AM -0700, Sam Leffler wrote: >> Sure, it was for others. > > Ah :) > >> Which version are you looking at? The numbers in iwi are from the code >> in linux-2.6.17; maybe it's been changed again in the code on >> sourceforge? > > I was looking in the ipw2200.h header file from ipw2200-1.1.2 - but > the values are the same in version 1.1.1 of the driver, which is > present in linux-2.6.17. > > #define IPW_MB_ROAMING_THRESHOLD_DEFAULT 8 > #define IPW_MB_DISASSOCIATE_THRESHOLD_DEFAULT 3*IPW_MB_ROAMING_THRESHOLD_DEFAULT If I recall the first is used to trigger a bg scan to look for a better ap. If that fails and the 2nd number is seen then the driver shuts down. So I guess this amounts to disconnecting from the current ap on the 2nd number but I'm not sure how you can do the bg scan and still get the firmware to keep counting up to the larger number (it resets it's internal counter on channel change from what I recall). But it's been a while. Regardless you've got a knob now so you can set it to whatever you want. You shouldn't be missing beacons in such large numbers; it's a likely indicator of some other problem but since we don't know what exactly a bmiss means it's hard to say (e.g. the firmware may report a bmiss when the rssi of the received beacon frame is below a threshold in which case there may be a problem with the threshold setting). > >> The one thing the linux driver does differently is scan for a new ap >> _before_ roaming which the current net80211 code cannot do. >> Unfortunately the code to do that has been sitting outside the tree >> for a long time and it's unclear if it'll ever come in... > > Oh? Sounds interesting, where can I find these patches? The work has always been in perforce.freebsd.org; look in the sam_wifi branch. The code will not hit head until folks show up to fix legacy drivers that use net80211. I got stuck holding the bag when I committed the wpa support and it ain't going to happen again. Sam From owner-freebsd-stable@FreeBSD.ORG Wed Jul 26 21:53:46 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6247016A4DA for ; Wed, 26 Jul 2006 21:53:46 +0000 (UTC) (envelope-from thompsa@freebsd.org) Received: from grunt7.ihug.co.nz (grunt7.ihug.co.nz [203.109.254.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id 03E9B43D49 for ; Wed, 26 Jul 2006 21:53:45 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: from 203-109-251-39.static.bliink.ihug.co.nz (heff.fud.org.nz) [203.109.251.39] by grunt7.ihug.co.nz with esmtp (Exim 3.35 #1 (Debian)) id 1G5rK3-00027h-00; Thu, 27 Jul 2006 09:53:43 +1200 Received: by heff.fud.org.nz (Postfix, from userid 1001) id 3243B1CC1F; Thu, 27 Jul 2006 09:53:41 +1200 (NZST) Date: Thu, 27 Jul 2006 09:53:41 +1200 From: Andrew Thompson To: Sam Leffler Message-ID: <20060726215341.GA7763@heff.fud.org.nz> References: <20060720224632.GB31459@osgiliath.brixandersen.dk> <44C00B40.2010901@errno.com> <20060726144058.GD3077@osgiliath.opasia.dk> <44C793DB.5090900@errno.com> <20060726163017.GB5856@osgiliath.opasia.dk> <44C7AF68.3090109@errno.com> <20060726181534.GD5856@osgiliath.opasia.dk> <44C7D05C.8000408@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44C7D05C.8000408@errno.com> User-Agent: Mutt/1.5.11 Cc: freebsd-stable@freebsd.org Subject: Re: "scan stuck" with if_iwi(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 21:53:46 -0000 On Wed, Jul 26, 2006 at 01:28:12PM -0700, Sam Leffler wrote: > Henrik Brix Andersen wrote: > > > > Oh? Sounds interesting, where can I find these patches? > > The work has always been in perforce.freebsd.org; look in the sam_wifi > branch. The code will not hit head until folks show up to fix legacy > drivers that use net80211. I got stuck holding the bag when I committed > the wpa support and it ain't going to happen again. > Do you have a list of drivers that are stalling this? Andrew From owner-freebsd-stable@FreeBSD.ORG Wed Jul 26 22:38:10 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE84F16A4DA for ; Wed, 26 Jul 2006 22:38:10 +0000 (UTC) (envelope-from mikej@rogers.com) Received: from H43.C18.B96.tor.eicat.ca (H43.C18.B96.tor.eicat.ca [66.96.18.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id DEE3743D58 for ; Wed, 26 Jul 2006 22:38:09 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from [127.0.0.1] (desktop.home.local [172.16.0.200]) by spamtoaster.home.local (Postfix) with ESMTP id B0CFB11557; Wed, 26 Jul 2006 12:40:16 -0400 (EDT) Message-ID: <44C79B1A.6060705@rogers.com> Date: Wed, 26 Jul 2006 12:40:58 -0400 From: Mike Jakubik User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Bruno Ducrot References: <44C63DFD.5040401@rogers.com> <20060726160952.GW17014@poupinou.org> In-Reply-To: <20060726160952.GW17014@poupinou.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SpamToaster-Information: This messages has been scanned by SpamToaster http://www.digitalprogression.ca X-SpamToaster: Found to be clean X-SpamToaster-SpamCheck: not spam, SpamAssassin (not cached, score=-2.49, required 3.5, ALL_TRUSTED -1.80, AWL 0.00, BAYES_00 -2.60, DK_POLICY_SIGNSOME 0.00, DNS_FROM_RFC_ABUSE 0.20, DNS_FROM_RFC_POST 1.71) X-SpamToaster-From: mikej@rogers.com X-Spam-Status: No Cc: stable@freebsd.org Subject: Re: Monitoring temperature with acpi (sysctls) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 22:38:11 -0000 Bruno Ducrot wrote: > On Tue, Jul 25, 2006 at 11:51:25AM -0400, Mike Jakubik wrote: > >> I need to be able to get the cpu and fan information from my >> motherboard, however none of the monitoring utilities in the ports seems >> to support my motherboard (Supermicro PDSMi, Intel E7230 (Mukilteo) >> Chipset). On my older VIA based motherboards and some Nvidia, i can get >> this information using ACPI and the hw.acpi.thermal sysctl. This however >> is not available on this motherboard. Would this be a shortcoming of the >> motherboards ACPI implementation, or a lack of support by freebsd? >> > > Does this one support IPMI? > > Yes, but with an optional $54 add-on card. From owner-freebsd-stable@FreeBSD.ORG Wed Jul 26 22:38:11 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E275416A4DD; Wed, 26 Jul 2006 22:38:10 +0000 (UTC) (envelope-from mikej@rogers.com) Received: from H43.C18.B96.tor.eicat.ca (H43.C18.B96.tor.eicat.ca [66.96.18.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id DEC8443D55; Wed, 26 Jul 2006 22:38:09 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from [127.0.0.1] (desktop.home.local [172.16.0.200]) by spamtoaster.home.local (Postfix) with ESMTP id ADD2C11673; Wed, 26 Jul 2006 18:31:14 -0400 (EDT) Message-ID: <44C7ED5F.6060902@rogers.com> Date: Wed, 26 Jul 2006 18:31:59 -0400 From: Mike Jakubik User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SpamToaster-Information: This messages has been scanned by SpamToaster http://www.digitalprogression.ca X-SpamToaster: Found to be clean X-SpamToaster-SpamCheck: not spam, SpamAssassin (not cached, score=-2.49, required 3.5, ALL_TRUSTED -1.80, BAYES_00 -2.60, DK_POLICY_SIGNSOME 0.00, DNS_FROM_RFC_ABUSE 0.20, DNS_FROM_RFC_POST 1.71) X-SpamToaster-From: mikej@rogers.com X-Spam-Status: No Cc: phk@freebsd.org, John Baldwin Subject: MFC of kern_resource.c (calru changes) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 22:38:11 -0000 Are there any plans to MFC the last few commits to kern_resource.c to -STABLE? I have a number of machines which flood the logs with "calcru: negative runtime" messages every time w, ps or top is used, so im hoping these may fix the issue. From owner-freebsd-stable@FreeBSD.ORG Wed Jul 26 22:38:11 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F371B16A4E9 for ; Wed, 26 Jul 2006 22:38:10 +0000 (UTC) (envelope-from mikej@rogers.com) Received: from H43.C18.B96.tor.eicat.ca (H43.C18.B96.tor.eicat.ca [66.96.18.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id DEB1B43D49 for ; Wed, 26 Jul 2006 22:38:09 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from [127.0.0.1] (desktop.home.local [172.16.0.200]) by spamtoaster.home.local (Postfix) with ESMTP id 74BD911469; Wed, 26 Jul 2006 14:52:10 -0400 (EDT) Message-ID: <44C7BA05.7020508@rogers.com> Date: Wed, 26 Jul 2006 14:52:53 -0400 From: Mike Jakubik User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: David Duchscher References: <44C63DFD.5040401@rogers.com> <20060726160952.GW17014@poupinou.org> <016E6A0B-E3E4-4444-BD27-24E75C784788@tamu.edu> In-Reply-To: <016E6A0B-E3E4-4444-BD27-24E75C784788@tamu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SpamToaster-Information: This messages has been scanned by SpamToaster http://www.digitalprogression.ca X-SpamToaster: Found to be clean X-SpamToaster-SpamCheck: not spam, SpamAssassin (not cached, score=-2.49, required 3.5, ALL_TRUSTED -1.80, BAYES_00 -2.60, DK_POLICY_SIGNSOME 0.00, DNS_FROM_RFC_ABUSE 0.20, DNS_FROM_RFC_POST 1.71) X-SpamToaster-From: mikej@rogers.com X-Spam-Status: No Cc: stable@freebsd.org, Bruno Ducrot Subject: Re: Monitoring temperature with acpi (sysctls) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 22:38:11 -0000 David Duchscher wrote: > > On Jul 26, 2006, at 11:09 AM, Bruno Ducrot wrote: >> Does this one support IPMI? > > Yes, the Supermicro PDSMi supports the IPMI 2.0 module and I can > confirm that it works with the IPMI ported driver from current on > 6.1. The module is optional so you will have to purchase one for > the system, around 0. You will also need the latest BIOS loaded on > the motherboard for it to work. > > http://www.supermicro.com/products/accessories/addon/AOC-IPMI20-E.cfm I don't want to spend $50 extra per system, just so i can read the temperature, and not even use any of the IPMI functions. I need a simple and scriptable way to get the values, acpi sysctls are ideal for this. From owner-freebsd-stable@FreeBSD.ORG Wed Jul 26 23:46:20 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D2ED216A4DA for ; Wed, 26 Jul 2006 23:46:20 +0000 (UTC) (envelope-from jhs@flat.berklix.net) Received: from thin.berklix.org (thin.berklix.org [194.246.123.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 591D243D49 for ; Wed, 26 Jul 2006 23:46:19 +0000 (GMT) (envelope-from jhs@flat.berklix.net) Received: from js.berklix.net (p549A7615.dip.t-dialin.net [84.154.118.21]) (authenticated bits=128) by thin.berklix.org (8.12.11/8.12.11) with ESMTP id k6QNjxvA042392; Thu, 27 Jul 2006 01:46:00 +0200 (CEST) (envelope-from jhs@flat.berklix.net) Received: from fire.jhs.private (fire.jhs.private [192.168.91.41]) by js.berklix.net (8.12.11/8.12.11) with ESMTP id k6QNjGN1003487; Thu, 27 Jul 2006 01:45:57 +0200 (CEST) (envelope-from jhs@flat.berklix.net) Received: from fire.jhs.private (localhost.jhs.private [127.0.0.1]) by fire.jhs.private (8.13.1/8.13.1) with ESMTP id k6QNjGv2012721; Thu, 27 Jul 2006 01:45:16 +0200 (CEST) (envelope-from jhs@fire.jhs.private) Message-Id: <200607262345.k6QNjGv2012721@fire.jhs.private> To: Sven Willenberger In-Reply-To: Message from Sven Willenberger of "Wed, 26 Jul 2006 13:07:19 EDT." <44C7A147.9010106@dmv.com> Date: Thu, 27 Jul 2006 01:45:16 +0200 From: "Julian H. Stacey" Cc: freebsd-stable@freebsd.org, Feargal Reilly Subject: Re: filesystem full error with inumber X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 23:46:21 -0000 Sven Willenberger wrote: > > > Feargal Reilly presumably uttered the following on 07/24/06 11:48: > > On Mon, 24 Jul 2006 17:14:27 +0200 (CEST) > > Oliver Fromme wrote: > > > >> Nobody else has answered so far, so I try to give it a shot ... > >> > >> The "filesystem full" error can happen in three cases: > >> 1. The file system is running out of data space. > >> 2. The file system is running out of inodes. > >> 3. The file system is running out of non-fragmented blocks. > >> > >> The third case can only happen on extremely fragmented > >> file systems which happens very rarely, but maybe it's > >> a possible cause of your problem. > > > > I rebooted that server, and df then reported that disk at 108%, > > so it appears that df was reporting incorrect figures prior to > > the reboot. Having cleaned up, it appears by my best > > calculations to be showing correct figures now. > > > >> > kern.maxfiles: 20000 > >> > kern.openfiles: 3582 > >> > >> Those have nothing to do with "filesystem full". > >> > > > > Yeah, that's what I figured. > > > >> > Looking again at dumpfs, it appears to say that this is > >> > formatted with a block size of 8K, and a fragment size of > >> > 2K, but tuning(7) says: [...] > >> > Reading this makes me think that when this server was > >> > installed, the block size was dropped from the 16K default > >> > to 8K for performance reasons, but the fragment size was > >> > not modified accordingly. > >> > > >> > Would this be the root of my problem? > >> > >> I think a bsize/fsize ratio of 4/1 _should_ work, but it's > >> not widely used, so there might be bugs hidden somewhere. > >> > > > > Such as df not reporting the actual data usage, which is now my > > best working theory. I don't know what df bases it's figures on, > > perhaps it either slowly got out of sync, or more likely, got > > things wrong once the disk filled up. > > > > I'll monitor it to see if this happens again, but hopefully > > won't keep that configuration around for too much longer anyway. > > > > Thanks, > > -fr. > > > > One of my machines that I recently upgraded to 6.1 (6.1-RELEASE-p3) is also > exhibiting df reporting wrong data usage numbers. Notice the negative "Used" numbers > below: Negative isnt an example of programming error, just that the system is now using the last bit only root can use. for insight try for example man tunefs reboot boot -s tunefs -m 2 /dev/da0s1e then decide what level of m you want default is 8 to 10 I recall. > > > df -h > Filesystem Size Used Avail Capacity Mounted on > /dev/da0s1a 496M 63M 393M 14% / > devfs 1.0K 1.0K 0B 100% /dev > /dev/da0s1e 989M -132M 1.0G -14% /tmp > /dev/da0s1f 15G 478M 14G 3% /usr > /dev/da0s1d 15G -1.0G 14G -8% /var > /dev/md0 496M 228K 456M 0% /var/spool/MIMEDefang > devfs 1.0K 1.0K 0B 100% /var/named/dev > > Sven -- Julian Stacey. Consultant Unix Net & Sys. Eng., Munich. http://berklix.com Mail in Ascii, HTML=spam. Ihr Rauch = mein allergischer Kopfschmerz. From owner-freebsd-stable@FreeBSD.ORG Thu Jul 27 00:09:22 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E508216A4E0 for ; Thu, 27 Jul 2006 00:09:22 +0000 (UTC) (envelope-from jd@ugcs.caltech.edu) Received: from groat.ugcs.caltech.edu (groat.ugcs.caltech.edu [131.215.176.110]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F98843D49 for ; Thu, 27 Jul 2006 00:09:22 +0000 (GMT) (envelope-from jd@ugcs.caltech.edu) Received: by groat.ugcs.caltech.edu (Postfix, from userid 3640) id 248E55880B; Wed, 26 Jul 2006 17:09:20 -0700 (PDT) Date: Wed, 26 Jul 2006 17:09:20 -0700 From: Paul Allen To: "Julian H. Stacey" Message-ID: <20060727000920.GH12597@groat.ugcs.caltech.edu> References: <44C7A147.9010106@dmv.com> <200607262345.k6QNjGv2012721@fire.jhs.private> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200607262345.k6QNjGv2012721@fire.jhs.private> Sender: jd@ugcs.caltech.edu Cc: Sven Willenberger , freebsd-stable@freebsd.org, Feargal Reilly Subject: Re: filesystem full error with inumber X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 00:09:23 -0000 >From "Julian H. Stacey" , Thu, Jul 27, 2006 at 01:45:16AM +0200: > Negative isnt an example of programming error, just that the system > is now using the last bit only root can use. > > for insight try for example > man tunefs > reboot > boot -s > tunefs -m 2 /dev/da0s1e > then decide what level of m you want default is 8 to 10 I recall. > > > > > > df -h > > Filesystem Size Used Avail Capacity Mounted on > > /dev/da0s1a 496M 63M 393M 14% / > > devfs 1.0K 1.0K 0B 100% /dev > > /dev/da0s1e 989M -132M 1.0G -14% /tmp > > /dev/da0s1f 15G 478M 14G 3% /usr > > /dev/da0s1d 15G -1.0G 14G -8% /var > > /dev/md0 496M 228K 456M 0% /var/spool/MIMEDefang > > devfs 1.0K 1.0K 0B 100% /var/named/dev > > > > Sven Julian: if you looked more closely you would see that the negative numbers appear not in the available category but in the 'USED'. This has nothing to do with root reserve. It may have something to do with background fsck though but it is rather inconsistent. 989 - (-132) == 1G 15G - (-1.0G) != 14G From owner-freebsd-stable@FreeBSD.ORG Thu Jul 27 02:17:57 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C34116A4DA for ; Thu, 27 Jul 2006 02:17:57 +0000 (UTC) (envelope-from leafy7382@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0AC1443D53 for ; Thu, 27 Jul 2006 02:17:56 +0000 (GMT) (envelope-from leafy7382@gmail.com) Received: by py-out-1112.google.com with SMTP id b36so37488pyb for ; Wed, 26 Jul 2006 19:17:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=uRtceY8AWALk4q6FVLMV8b4lRIFd68DBPMlmnvkEDcq7nhDx3iRT3tz57Lhzexr7ZdHDy09UgHiQ/xQ2nMUHqXt2LC6vFtXQ2m+xA18wfpQmYGNcshJBcyV3PymBYGWK/hgnWPVgKA1qb6H2SbsZ+gKxJj8WFBfGHkb3PWeLKfo= Received: by 10.35.27.2 with SMTP id e2mr12298688pyj; Wed, 26 Jul 2006 19:17:56 -0700 (PDT) Received: by 10.35.125.14 with HTTP; Wed, 26 Jul 2006 19:17:56 -0700 (PDT) Message-ID: Date: Thu, 27 Jul 2006 10:17:56 +0800 From: "Jiawei Ye" To: "Mike Jakubik" In-Reply-To: <44C7BA05.7020508@rogers.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44C63DFD.5040401@rogers.com> <20060726160952.GW17014@poupinou.org> <016E6A0B-E3E4-4444-BD27-24E75C784788@tamu.edu> <44C7BA05.7020508@rogers.com> Cc: David Duchscher , stable@freebsd.org, Bruno Ducrot Subject: Re: Monitoring temperature with acpi (sysctls) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 02:17:57 -0000 On 7/27/06, Mike Jakubik wrote: > I don't want to spend $50 extra per system, just so i can read the > temperature, and not even use any of the IPMI functions. I need a simple > and scriptable way to get the values, acpi sysctls are ideal for this. What about using SMBus? Is it available on your system? xmbmon reads temperatures off the SMBus IIRC. Jiawei Ye -- "Without the userland, the kernel is useless." --inspired by The Tao of Programming From owner-freebsd-stable@FreeBSD.ORG Thu Jul 27 05:47:44 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A3F1216A4DA for ; Thu, 27 Jul 2006 05:47:44 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.FreeBSD.org (Postfix) with SMTP id BB3A943D5A for ; Thu, 27 Jul 2006 05:47:43 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 17460 invoked by uid 399); 27 Jul 2006 05:47:43 -0000 Received: from localhost (HELO ?192.168.0.3?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 27 Jul 2006 05:47:43 -0000 Message-ID: <44C8537C.10103@FreeBSD.org> Date: Wed, 26 Jul 2006 22:47:40 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5.0.4 (X11/20060604) MIME-Version: 1.0 To: Mike Jakubik References: <44C7ED5F.6060902@rogers.com> In-Reply-To: <44C7ED5F.6060902@rogers.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, phk@freebsd.org, John Baldwin Subject: Re: MFC of kern_resource.c (calru changes) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 05:47:44 -0000 Mike Jakubik wrote: > Are there any plans to MFC the last few commits to kern_resource.c to > -STABLE? I have a number of machines which flood the logs with "calcru: > negative runtime" messages every time w, ps or top is used, so im hoping > these may fix the issue. Well, one way to help make sure that happens is to test it yourself, and report to the developers. Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Thu Jul 27 06:24:43 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 05AE716A4DA for ; Thu, 27 Jul 2006 06:24:43 +0000 (UTC) (envelope-from mikej@rogers.com) Received: from H43.C18.B96.tor.eicat.ca (H43.C18.B96.tor.eicat.ca [66.96.18.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F9CD43D49 for ; Thu, 27 Jul 2006 06:24:42 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from [127.0.0.1] (desktop.home.local [172.16.0.200]) by H43.C18.B96.tor.eicat.ca (Postfix) with ESMTP id 21B7711469; Thu, 27 Jul 2006 02:24:34 -0400 (EDT) Message-ID: <44C85C4F.7030902@rogers.com> Date: Thu, 27 Jul 2006 02:25:19 -0400 From: Mike Jakubik User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Jiawei Ye References: <44C63DFD.5040401@rogers.com> <20060726160952.GW17014@poupinou.org> <016E6A0B-E3E4-4444-BD27-24E75C784788@tamu.edu> <44C7BA05.7020508@rogers.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SpamToaster-Information: This messages has been scanned by SpamToaster http://www.digitalprogression.ca X-SpamToaster: Found to be clean X-SpamToaster-SpamCheck: not spam, SpamAssassin (not cached, score=-2.49, required 3.5, ALL_TRUSTED -1.80, BAYES_00 -2.60, DK_POLICY_SIGNSOME 0.00, DNS_FROM_RFC_ABUSE 0.20, DNS_FROM_RFC_POST 1.71) X-SpamToaster-From: mikej@rogers.com X-Spam-Status: No Cc: David Duchscher , stable@freebsd.org, Bruno Ducrot Subject: Re: Monitoring temperature with acpi (sysctls) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 06:24:43 -0000 Jiawei Ye wrote: > On 7/27/06, Mike Jakubik wrote: >> I don't want to spend $50 extra per system, just so i can read the >> temperature, and not even use any of the IPMI functions. I need a simple >> and scriptable way to get the values, acpi sysctls are ideal for this. > What about using SMBus? Is it available on your system? xmbmon reads > temperatures off the SMBus IIRC. I tried that, unfortunately it does not work. All i want to know is if this a shortcoming of freebsd or the motherboard, if its the later, i will contact the manufacturer. From owner-freebsd-stable@FreeBSD.ORG Thu Jul 27 07:36:25 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E4FC016A4DD for ; Thu, 27 Jul 2006 07:36:24 +0000 (UTC) (envelope-from feargal@helgrim.com) Received: from mail09.svc.cra.dublin.eircom.net (mail09.svc.cra.dublin.eircom.net [159.134.118.25]) by mx1.FreeBSD.org (Postfix) with SMTP id 3CE0843D46 for ; Thu, 27 Jul 2006 07:36:23 +0000 (GMT) (envelope-from feargal@helgrim.com) Received: (qmail 9717 messnum 2875505 invoked from network[82.141.233.46/unknown]); 27 Jul 2006 07:36:22 -0000 Received: from unknown (HELO alatar.edhellond.fbi.ie) (82.141.233.46) by mail09.svc.cra.dublin.eircom.net (qp 9717) with SMTP; 27 Jul 2006 07:36:22 -0000 Received: from mablung.edhellond.fbi.ie (mablung.edhellond.fbi.ie [192.168.0.14]) by alatar.edhellond.fbi.ie (8.13.1/8.13.1) with ESMTP id k6R7aKlg039445 for ; Thu, 27 Jul 2006 07:36:21 GMT (envelope-from feargal@helgrim.com) Date: Thu, 27 Jul 2006 08:36:20 +0100 From: Feargal Reilly To: freebsd-stable@freebsd.org Message-ID: <20060727083620.75d10af2@mablung.edhellond.fbi.ie> In-Reply-To: <44C7A147.9010106@dmv.com> References: <20060721140005.5365e4b7@mablung.edhellond.fbi.ie> <200607241514.k6OFERos052696@lurza.secnetix.de> <20060724164832.11683f08@mablung.edhellond.fbi.ie> <44C7A147.9010106@dmv.com> Organization: www.helgrim.com X-Mailer: Sylpheed-Claws 2.1.1 (GTK+ 2.8.7; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig__OO9Hn/Hx63q2El2JS_hFj3"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Subject: Re: filesystem full error with inumber X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 07:36:25 -0000 --Sig__OO9Hn/Hx63q2El2JS_hFj3 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 26 Jul 2006 13:07:19 -0400 Sven Willenberger wrote: >=20 > Feargal Reilly presumably uttered the following on 07/24/06 > 11:48: > >> > Looking again at dumpfs, it appears to say that this is > >> > formatted with a block size of 8K, and a fragment size of > >> > 2K, but tuning(7) says: [...] > >> > Reading this makes me think that when this server was > >> > installed, the block size was dropped from the 16K > >> > default to 8K for performance reasons, but the fragment > >> > size was not modified accordingly. > >> >=20 > >> > Would this be the root of my problem? > >> > >> I think a bsize/fsize ratio of 4/1 _should_ work, but it's > >> not widely used, so there might be bugs hidden somewhere. > >> > >=20 > > Such as df not reporting the actual data usage, which is now > > my best working theory. I don't know what df bases it's > > figures on, perhaps it either slowly got out of sync, or > > more likely, got things wrong once the disk filled up. > >=20 > > One of my machines that I recently upgraded to 6.1 > (6.1-RELEASE-p3) is also exhibiting df reporting wrong data > usage numbers. Notice the negative "Used" numbers below: >=20 > > df -h > Filesystem Size Used Avail Capacity Mounted on > /dev/da0s1a 496M 63M 393M 14% / > devfs 1.0K 1.0K 0B 100% /dev > /dev/da0s1e 989M -132M 1.0G -14% /tmp > /dev/da0s1f 15G 478M 14G 3% /usr > /dev/da0s1d 15G -1.0G 14G -8% /var > /dev/md0 496M 228K 456M > 0% /var/spool/MIMEDefang devfs 1.0K 1.0K > 0B 100% /var/named/dev >=20 > Sven For the record, my problems occured with 5.4-PRERELEASE #1 which, for reasons beyond my control, I had not yet been unable to upgrade. What bsize/fsize ratio are you using? Mine was 4/1 instead of the more usual 8/1. BTW, anybody know what the best method be for double-checking df's figures would be? du? --=20 Feargal Reilly. PGP Key: 0x847DE4C8 (expires: 2006-11-30) Web: http://www.helgrim.com/ | ICQ: 109837009 | YIM: ectoraige Visit http://ie.bsd.net/ - BSDs presence in Ireland --Sig__OO9Hn/Hx63q2El2JS_hFj3 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFEyGz0Hfl+zYR95MgRAvkXAJ4jvRZNpeBkzBNqnINp7vU9maVq4wCfWNLZ boGlsEp+p3D3Idu1j0lGPCk= =nRlm -----END PGP SIGNATURE----- --Sig__OO9Hn/Hx63q2El2JS_hFj3-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 27 07:48:37 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 41CA916A4DA for ; Thu, 27 Jul 2006 07:48:37 +0000 (UTC) (envelope-from ducrot@poupinou.org) Received: from poup.poupinou.org (poup.poupinou.org [195.101.94.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8C1943D46 for ; Thu, 27 Jul 2006 07:48:36 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from ducrot by poup.poupinou.org with local (Exim) id 1G60bf-0006wJ-00; Thu, 27 Jul 2006 09:48:31 +0200 Date: Thu, 27 Jul 2006 09:48:31 +0200 To: Mike Jakubik Message-ID: <20060727074831.GX17014@poupinou.org> References: <44C63DFD.5040401@rogers.com> <20060726160952.GW17014@poupinou.org> <016E6A0B-E3E4-4444-BD27-24E75C784788@tamu.edu> <44C7BA05.7020508@rogers.com> <44C85C4F.7030902@rogers.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44C85C4F.7030902@rogers.com> User-Agent: Mutt/1.5.9i From: Bruno Ducrot Cc: David Duchscher , stable@freebsd.org, Jiawei Ye Subject: Re: Monitoring temperature with acpi (sysctls) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 07:48:37 -0000 On Thu, Jul 27, 2006 at 02:25:19AM -0400, Mike Jakubik wrote: > Jiawei Ye wrote: > >On 7/27/06, Mike Jakubik wrote: > >>I don't want to spend $50 extra per system, just so i can read the > >>temperature, and not even use any of the IPMI functions. I need a simple > >>and scriptable way to get the values, acpi sysctls are ideal for this. > >What about using SMBus? Is it available on your system? xmbmon reads > >temperatures off the SMBus IIRC. > > I tried that, unfortunately it does not work. All i want to know is if > this a shortcoming of freebsd or the motherboard, if its the later, i > will contact the manufacturer. Could you please try (if you have a working smb device) # smbmsg -p -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. From owner-freebsd-stable@FreeBSD.ORG Thu Jul 27 08:29:32 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A544A16A4DF for ; Thu, 27 Jul 2006 08:29:32 +0000 (UTC) (envelope-from rsmith@xs4all.nl) Received: from smtp-vbr1.xs4all.nl (smtp-vbr1.xs4all.nl [194.109.24.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0788943D46 for ; Thu, 27 Jul 2006 08:29:31 +0000 (GMT) (envelope-from rsmith@xs4all.nl) Received: from slackbox.xs4all.nl (slackbox.xs4all.nl [213.84.242.160]) by smtp-vbr1.xs4all.nl (8.13.6/8.13.6) with ESMTP id k6R8TU7X001581 for ; Thu, 27 Jul 2006 10:29:30 +0200 (CEST) (envelope-from rsmith@xs4all.nl) Received: by slackbox.xs4all.nl (Postfix, from userid 1001) id 0D3EAB854; Thu, 27 Jul 2006 10:29:30 +0200 (CEST) Date: Thu, 27 Jul 2006 10:29:30 +0200 From: Roland Smith To: stable@freebsd.org Message-ID: <20060727082929.GA6458@slackbox.xs4all.nl> References: <44C63DFD.5040401@rogers.com> <20060726160952.GW17014@poupinou.org> <016E6A0B-E3E4-4444-BD27-24E75C784788@tamu.edu> <44C7BA05.7020508@rogers.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k1lZvvs/B4yU6o8G" Content-Disposition: inline In-Reply-To: <44C7BA05.7020508@rogers.com> X-GPG-Fingerprint: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 X-GPG-Key: http://www.xs4all.nl/~rsmith/pubkey.txt X-GPG-Notice: If this message is not signed, don't assume I sent it! User-Agent: Mutt/1.5.11 X-Virus-Scanned: by XS4ALL Virus Scanner Cc: Subject: Re: Monitoring temperature with acpi (sysctls) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 08:29:32 -0000 --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 26, 2006 at 02:52:53PM -0400, Mike Jakubik wrote: > David Duchscher wrote: > > > >On Jul 26, 2006, at 11:09 AM, Bruno Ducrot wrote: > >>Does this one support IPMI? > > > >Yes, the Supermicro PDSMi supports the IPMI 2.0 module and I can > >confirm that it works with the IPMI ported driver from current on > >6.1. The module is optional so you will have to purchase one for > >the system, around 0. You will also need the latest BIOS loaded on > >the motherboard for it to work. > > > >http://www.supermicro.com/products/accessories/addon/AOC-IPMI20-E.cfm >=20 > I don't want to spend $50 extra per system, just so i can read the=20 > temperature, and not even use any of the IPMI functions. I need a simple= =20 > and scriptable way to get the values, acpi sysctls are ideal for this. Have you tried ports/sysutils/mbmon? It can try to get the values in different ways, e.g. accessing the chip directly, smbus or isa. It is easily scriptable. I use it in combination with gnuplot in a shell-script to make a graph of the CPU and motherboard temperatures; http://www.xs4all.nl/~rsmith/freebsd/index.html#monitor=20 Roland --=20 R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) --k1lZvvs/B4yU6o8G Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEyHlpEnfvsMMhpyURAlIPAJ0SXp2eVA8+br4FIuXIRCf/2Vyi4wCfS9J4 hhYRV8TG0faZdSz3OxrCMxQ= =eJ8O -----END PGP SIGNATURE----- --k1lZvvs/B4yU6o8G-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 27 11:19:33 2006 Return-Path: X-Original-To: stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC31716A4DD for ; Thu, 27 Jul 2006 11:19:33 +0000 (UTC) (envelope-from erwin@mail.droso.net) Received: from mail.droso.net (koala.droso.net [193.88.12.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A5E543D58 for ; Thu, 27 Jul 2006 11:19:32 +0000 (GMT) (envelope-from erwin@mail.droso.net) Received: by mail.droso.net (Postfix, from userid 1001) id 2266722DB7; Thu, 27 Jul 2006 13:19:32 +0200 (CEST) Date: Thu, 27 Jul 2006 13:19:32 +0200 From: Erwin Lansing To: stable@FreeBSD.org Message-ID: <20060727111931.GB13326@droso.net> Mail-Followup-To: stable@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZmUaFz6apKcXQszQ" Content-Disposition: inline X-Operating-System: FreeBSD/i386 5.4-RELEASE User-Agent: Mutt/1.5.12-2006-07-14 Cc: Subject: SW_WATCHDOG panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 11:19:34 -0000 --ZmUaFz6apKcXQszQ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable While trying to debug why I couldn't use powerd(8) with two batteries in my IBM T41 (which seems related to kern/97383), I turned on SW_WATCHDOG only to get an almost immediate panic after turning it on with watchdog(8). Sources are from July 10 RELENG_6. Backtrace http://people.freebsd.org/~erwin/rabbit.txt If anyone wants to have a look, let me know if you need more information. Cheers, -erwin --=20 Erwin Lansing http://droso.org Security is like an onion. (o_ _o) It's made up of several layers \\\_\ /_/// erwin@FreeBSD.org And it makes you cry. <____) (____> erwin@aauug.dk --ZmUaFz6apKcXQszQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEyKFDqy9aWxUlaZARAk8kAKDOjpbpxcb6EGxwZ7K+b398+x0A/wCeML4M la8ye1V860zzJvfJ/wYb4B8= =BJ+C -----END PGP SIGNATURE----- --ZmUaFz6apKcXQszQ-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 27 13:28:18 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0313016A4E8 for ; Thu, 27 Jul 2006 13:28:18 +0000 (UTC) (envelope-from ohartman@uni-mainz.de) Received: from mailgate01.zdv.uni-mainz.de (mailgate01.zdv.Uni-Mainz.DE [134.93.178.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF8FE43D5C for ; Thu, 27 Jul 2006 13:28:14 +0000 (GMT) (envelope-from ohartman@uni-mainz.de) Received: from exfront02.zdv.uni-mainz.de ([134.93.176.56]) by mailgate01.zdv.uni-mainz.de with ESMTP; 27 Jul 2006 15:28:13 +0200 Received: from mail.uni-mainz.de ([134.93.176.56]) by exfront02.zdv.Uni-Mainz.DE with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 15:28:13 +0200 Received: from [130.133.86.198] ([130.133.86.198] RDNS failed) by mail.uni-mainz.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 15:28:13 +0200 Message-ID: <44C8BF52.20801@uni-mainz.de> Date: Thu, 27 Jul 2006 15:27:46 +0200 From: "O. Hartmann" User-Agent: Thunderbird 1.5.0.4 (X11/20060606) MIME-Version: 1.0 To: Jiawei Ye References: <44C63DFD.5040401@rogers.com> <20060726160952.GW17014@poupinou.org> <016E6A0B-E3E4-4444-BD27-24E75C784788@tamu.edu> <44C7BA05.7020508@rogers.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jul 2006 13:28:13.0311 (UTC) FILETIME=[82AF88F0:01C6B180] Cc: Mike Jakubik , stable@freebsd.org, Bruno Ducrot , David Duchscher Subject: Re: Monitoring temperature with acpi (sysctls) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 13:28:18 -0000 Jiawei Ye wrote: > On 7/27/06, Mike Jakubik wrote: >> I don't want to spend $50 extra per system, just so i can read the >> temperature, and not even use any of the IPMI functions. I need a simple >> and scriptable way to get the values, acpi sysctls are ideal for this. > What about using SMBus? Is it available on your system? xmbmon reads > temperatures off the SMBus IIRC. > > Jiawei Ye > But also not working on ASUS A8N32-SLI Deluxe or at my lab's ASUS P800! On ASUS A8N-SLI Deluxe xmbmon worked fine! SMBus never worked on any ASUS, don't know why. From owner-freebsd-stable@FreeBSD.ORG Thu Jul 27 13:32:26 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 04A6E16A4DA for ; Thu, 27 Jul 2006 13:32:26 +0000 (UTC) (envelope-from ohartman@uni-mainz.de) Received: from mailgate02.zdv.uni-mainz.de (mailgate02.zdv.Uni-Mainz.DE [134.93.178.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF51B43D58 for ; Thu, 27 Jul 2006 13:32:20 +0000 (GMT) (envelope-from ohartman@uni-mainz.de) Received: from exfront02.zdv.uni-mainz.de ([134.93.176.56]) by mailgate02.zdv.uni-mainz.de with ESMTP; 27 Jul 2006 15:32:19 +0200 Received: from mail.uni-mainz.de ([134.93.176.56]) by exfront02.zdv.Uni-Mainz.DE with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 15:32:19 +0200 Received: from [130.133.86.198] ([130.133.86.198] RDNS failed) by mail.uni-mainz.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 15:32:19 +0200 Message-ID: <44C8C04C.7070906@uni-mainz.de> Date: Thu, 27 Jul 2006 15:31:56 +0200 From: "O. Hartmann" User-Agent: Thunderbird 1.5.0.4 (X11/20060606) MIME-Version: 1.0 To: Roland Smith References: <44C63DFD.5040401@rogers.com> <20060726160952.GW17014@poupinou.org> <016E6A0B-E3E4-4444-BD27-24E75C784788@tamu.edu> <44C7BA05.7020508@rogers.com> <20060727082929.GA6458@slackbox.xs4all.nl> In-Reply-To: <20060727082929.GA6458@slackbox.xs4all.nl> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jul 2006 13:32:19.0205 (UTC) FILETIME=[153FFB50:01C6B181] Cc: stable@freebsd.org Subject: Re: Monitoring temperature with acpi (sysctls) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 13:32:26 -0000 Roland Smith wrote: > On Wed, Jul 26, 2006 at 02:52:53PM -0400, Mike Jakubik wrote: >> David Duchscher wrote: >>> On Jul 26, 2006, at 11:09 AM, Bruno Ducrot wrote: >>>> Does this one support IPMI? >>> Yes, the Supermicro PDSMi supports the IPMI 2.0 module and I can >>> confirm that it works with the IPMI ported driver from current on >>> 6.1. The module is optional so you will have to purchase one for >>> the system, around 0. You will also need the latest BIOS loaded on >>> the motherboard for it to work. >>> >>> http://www.supermicro.com/products/accessories/addon/AOC-IPMI20-E.cfm >> I don't want to spend $50 extra per system, just so i can read the >> temperature, and not even use any of the IPMI functions. I need a simple >> and scriptable way to get the values, acpi sysctls are ideal for this. > > Have you tried ports/sysutils/mbmon? > > It can try to get the values in different ways, e.g. accessing the chip > directly, smbus or isa. It is easily scriptable. I use it in combination > with gnuplot in a shell-script to make a graph of the CPU and > motherboard temperatures; > http://www.xs4all.nl/~rsmith/freebsd/index.html#monitor > > Roland I did and it only worked for my on an ASUS A8N-SLI Deluxe. ASUS A8N32-SLI Deluxe evidently uses another IO chip (or e newer revision) and on my lab's i386 ASUS P800 system I have the same problem, neither ACPI, smbus nor anything else seems to work or obtain temperature/fan speed. It's funny, on those boxes xmbmon/mbmon worked fine I also saw ACPI thermal zones and fan speed (expecially my older ASUS A8N-SLI Deluxe). From owner-freebsd-stable@FreeBSD.ORG Thu Jul 27 14:05:57 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF26A16A4DD for ; Thu, 27 Jul 2006 14:05:56 +0000 (UTC) (envelope-from rsmith@xs4all.nl) Received: from smtp-vbr16.xs4all.nl (smtp-vbr16.xs4all.nl [194.109.24.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CA0D43D6B for ; Thu, 27 Jul 2006 14:05:50 +0000 (GMT) (envelope-from rsmith@xs4all.nl) Received: from slackbox.xs4all.nl (slackbox.xs4all.nl [213.84.242.160]) by smtp-vbr16.xs4all.nl (8.13.6/8.13.6) with ESMTP id k6RE5m3n092218; Thu, 27 Jul 2006 16:05:49 +0200 (CEST) (envelope-from rsmith@xs4all.nl) Received: by slackbox.xs4all.nl (Postfix, from userid 1001) id 86E9BB854; Thu, 27 Jul 2006 16:05:48 +0200 (CEST) Date: Thu, 27 Jul 2006 16:05:48 +0200 From: Roland Smith To: "O. Hartmann" Message-ID: <20060727140548.GA14838@slackbox.xs4all.nl> References: <44C63DFD.5040401@rogers.com> <20060726160952.GW17014@poupinou.org> <016E6A0B-E3E4-4444-BD27-24E75C784788@tamu.edu> <44C7BA05.7020508@rogers.com> <20060727082929.GA6458@slackbox.xs4all.nl> <44C8C04C.7070906@uni-mainz.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/9DWx/yDrRhgMJTb" Content-Disposition: inline In-Reply-To: <44C8C04C.7070906@uni-mainz.de> X-GPG-Fingerprint: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 X-GPG-Key: http://www.xs4all.nl/~rsmith/pubkey.txt X-GPG-Notice: If this message is not signed, don't assume I sent it! User-Agent: Mutt/1.5.11 X-Virus-Scanned: by XS4ALL Virus Scanner Cc: stable@freebsd.org Subject: Re: Monitoring temperature with acpi (sysctls) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 14:05:57 -0000 --/9DWx/yDrRhgMJTb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 27, 2006 at 03:31:56PM +0200, O. Hartmann wrote: > Roland Smith wrote: > >On Wed, Jul 26, 2006 at 02:52:53PM -0400, Mike Jakubik wrote: > >>David Duchscher wrote: > >>>On Jul 26, 2006, at 11:09 AM, Bruno Ducrot wrote: > >>>>Does this one support IPMI? > >>>Yes, the Supermicro PDSMi supports the IPMI 2.0 module and I can > >>>confirm that it works with the IPMI ported driver from current on > >>>6.1. The module is optional so you will have to purchase one for > >>>the system, around 0. You will also need the latest BIOS loaded on > >>>the motherboard for it to work. > >>> > >>>http://www.supermicro.com/products/accessories/addon/AOC-IPMI20-E.cfm > >>I don't want to spend $50 extra per system, just so i can read the=20 > >>temperature, and not even use any of the IPMI functions. I need a simpl= e=20 > >>and scriptable way to get the values, acpi sysctls are ideal for this. > > > >Have you tried ports/sysutils/mbmon? > > > >It can try to get the values in different ways, e.g. accessing the chip > >directly, smbus or isa. It is easily scriptable. I use it in combination > >with gnuplot in a shell-script to make a graph of the CPU and > >motherboard temperatures; > >http://www.xs4all.nl/~rsmith/freebsd/index.html#monitor=20 > > > >Roland >=20 > I did and it only worked for my on an ASUS A8N-SLI Deluxe. ASUS=20 > A8N32-SLI Deluxe evidently uses another IO chip (or e newer revision)=20 > and on my lab's i386 ASUS P800 system I have the same problem, neither=20 > ACPI, smbus nor anything else seems to work or obtain temperature/fan spe= ed. >=20 > It's funny, on those boxes xmbmon/mbmon worked fine I also saw ACPI=20 > thermal zones and fan speed (expecially my older ASUS A8N-SLI Deluxe). My ASUS K8V DeLuxe doesn't work with ACPI; there is no hw.acpi.thermal sysctl.=20 The only thing that seems to work is mbmon via the ISA interface. Trying SMBus gives nonsense values. Roland --=20 R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) --/9DWx/yDrRhgMJTb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEyMg8EnfvsMMhpyURAtyRAJ4jBwxxgRj3u3m3PGeKJfDBny8LjQCgjFOE BLpkJIaBf0/JvocHr7RnO7s= =EQ8N -----END PGP SIGNATURE----- --/9DWx/yDrRhgMJTb-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 27 14:51:56 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1D4716A4DA for ; Thu, 27 Jul 2006 14:51:56 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1011B43D49 for ; Thu, 27 Jul 2006 14:51:55 +0000 (GMT) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0J32002G3HAIK150@osl1smout1.broadpark.no> for freebsd-stable@freebsd.org; Thu, 27 Jul 2006 16:51:54 +0200 (CEST) Received: from kg-work.kg4.no ([80.203.92.117]) by osl1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with SMTP id <0J3200MY7HAIDLF0@osl1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Thu, 27 Jul 2006 16:51:54 +0200 (CEST) Date: Thu, 27 Jul 2006 16:51:54 +0200 From: Torfinn Ingolfsen X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH To: freebsd-stable@freebsd.org Message-id: <20060727165154.a303509b.torfinn.ingolfsen@broadpark.no> MIME-version: 1.0 X-Mailer: Sylpheed version 2.2.6 (GTK+ 2.8.20; i386-portbld-freebsd5.5) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Gigabyte K8-NF-9 and SMBus X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 14:51:56 -0000 Hello, Following an interesting discussion about temperature monitoring on this mailing list, I decided to try this on a machine with the Gigabyte K8-NF-9 motherboard (the only machine which I can get a /dev/smb0 device on). It runs 6.1-stable: root@kg-fil# uname -a FreeBSD kg-fil.kg4.no 6.1-STABLE FreeBSD 6.1-STABLE #8: Sun May 7 22:51:56 CEST 2006 root@kg-fil.kg4.no:/usr/obj/usr/src/sys/FIL60 amd64 I load the following modules: root@kg-fil# kldload ichsmb root@kg-fil# kldload smb which gives this output in /var/log/messages: Jul 27 16:31:58 kg-fil kernel: ichsmb0: port 0xe800-0xe81f,0x 1c00-0x1c3f,0x1c40-0x1c7f irq 20 at device 1.1 on pci0 Jul 27 16:31:58 kg-fil kernel: ichsmb0: [GIANT-LOCKED] Jul 27 16:31:58 kg-fil kernel: smbus0: on ichsmb0 Jul 27 16:32:16 kg-fil kernel: smb0: on smbus0 But when I try 'smbmsg -p' I get this in /var/log/messages: Jul 27 16:32:31 kg-fil kernel: ichsmb0: device timeout, status=0x00 Jul 27 16:33:02 kg-fil last message repeated 123 times Jul 27 16:33:27 kg-fil last message repeated 100 times Hmm, it doesn't look like it is working properly. I also tried loading smb first and ichsmb last, but nothing changes. -- Regards, Torfinn Ingolfsen, Norway From owner-freebsd-stable@FreeBSD.ORG Thu Jul 27 15:09:10 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E25E516A4E1 for ; Thu, 27 Jul 2006 15:09:10 +0000 (UTC) (envelope-from mikej@rogers.com) Received: from H43.C18.B96.tor.eicat.ca (H43.C18.B96.tor.eicat.ca [66.96.18.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3304E43D78 for ; Thu, 27 Jul 2006 15:09:05 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from [127.0.0.1] (desktop.home.local [172.16.0.200]) by H43.C18.B96.tor.eicat.ca (Postfix) with ESMTP id E3A561148E; Thu, 27 Jul 2006 11:08:56 -0400 (EDT) Message-ID: <44C8D73F.7010908@rogers.com> Date: Thu, 27 Jul 2006 11:09:51 -0400 From: Mike Jakubik User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Bruno Ducrot References: <44C63DFD.5040401@rogers.com> <20060726160952.GW17014@poupinou.org> <016E6A0B-E3E4-4444-BD27-24E75C784788@tamu.edu> <44C7BA05.7020508@rogers.com> <44C85C4F.7030902@rogers.com> <20060727074831.GX17014@poupinou.org> In-Reply-To: <20060727074831.GX17014@poupinou.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SpamToaster-Information: This messages has been scanned by SpamToaster http://www.digitalprogression.ca X-SpamToaster: Found to be clean X-SpamToaster-SpamCheck: not spam, SpamAssassin (not cached, score=-2.49, required 3.5, ALL_TRUSTED -1.80, AWL 0.00, BAYES_00 -2.60, DK_POLICY_SIGNSOME 0.00, DNS_FROM_RFC_ABUSE 0.20, DNS_FROM_RFC_POST 1.71) X-SpamToaster-From: mikej@rogers.com X-Spam-Status: No Cc: David Duchscher , stable@freebsd.org, Jiawei Ye Subject: Re: Monitoring temperature with acpi (sysctls) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 15:09:11 -0000 Bruno Ducrot wrote: > Could you please try (if you have a working smb device) > > # smbmsg -p > Well, i don't think its being detected/supported. I tried loading all the smbus related kernel modules, but no device. Id Refs Address Size Name 1 9 0xc0400000 2d1624 kernel 2 1 0xc06d2000 606ac acpi.ko 3 3 0xc4dca000 2000 smbus.ko 4 1 0xc4dcc000 3000 iicsmb.ko 5 3 0xc4dcf000 3000 iicbus.ko 6 1 0xc4de4000 3000 smb.ko 7 1 0xc4df3000 3000 iic.ko 8 1 0xc4df6000 3000 if_ic.ko However, dmesg seems to show that there is a SMBus device on the MB. pci0: at device 31.3 (no driver attached) From owner-freebsd-stable@FreeBSD.ORG Thu Jul 27 15:14:41 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A80616A4DD for ; Thu, 27 Jul 2006 15:14:41 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 401F243D5D for ; Thu, 27 Jul 2006 15:14:39 +0000 (GMT) (envelope-from freebsd-listen@fabiankeil.de) Received: (qmail 16998 invoked from network); 27 Jul 2006 15:14:36 -0000 Received: from unknown (HELO localhost) (775067@[217.50.146.49]) (envelope-sender ) by smtprelay01.ispgateway.de (qmail-ldap-1.03) with SMTP for ; 27 Jul 2006 15:14:36 -0000 Date: Thu, 27 Jul 2006 17:14:16 +0200 From: Fabian Keil To: freebsd-stable@freebsd.org Message-ID: <20060727171416.6a8a104f@localhost> In-Reply-To: <20060726152440.647fca4e@localhost> References: <20060715132007.61a5dbf5@localhost> <20060715160110.45064.qmail@web51902.mail.yahoo.com> <20060715185948.117e9024@localhost> <20060726152440.647fca4e@localhost> X-Mailer: Sylpheed-Claws 2.3.1 (GTK+ 2.8.19; i386-portbld-freebsd6.1) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2006-08-19.asc Mime-Version: 1.0 Content-Type: multipart/signed; boundary=Sig_9yaej8a_xyuUB6CKexw4OkZ; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: peter.thoenen@yahoo.com, Robert Watson Subject: Re: FreeBSD 6.1 Tor issues (Once More, with Feeling) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 15:14:41 -0000 --Sig_9yaej8a_xyuUB6CKexw4OkZ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Fabian Keil wrote: > Fabian Keil wrote: >=20 > > Peter Thoenen wrote: > >=20 > > > To you have pf running? If so can you turn it off for a bit a see > > > if you still crash. On my box I was getting all sorts of witness > > > kbd backtraces on pf and since turning pf off (maybe a week ago), > > > haven't crashed yet. Going to let it keep running unmetered for > > > another 2 weeks and see if I crash or not. > > So far I didn't see a single PF related complaint from witness, > > but I'll try disabling PF in a few days anyway. >=20 > It took a little longer than I thought, but I finally > disabled PF today and switched to natd. Uptime was slightly above 25 hours. Compiling HEAD right now.=20 Fabian --=20 http://www.fabiankeil.de/ --Sig_9yaej8a_xyuUB6CKexw4OkZ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEyNhSjV8GA4rMKUQRAtkBAKCNIsIRqkEnwWcB2WH3yWnKlJi3YwCeJfXG nxl4uD3kUzxa7tsV2+M2T/A= =BACX -----END PGP SIGNATURE----- --Sig_9yaej8a_xyuUB6CKexw4OkZ-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 27 15:37:59 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D9BEB16A4DD for ; Thu, 27 Jul 2006 15:37:59 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 291CF43D6B for ; Thu, 27 Jul 2006 15:37:56 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (qdovsj@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id k6RFboCu039943 for ; Thu, 27 Jul 2006 17:37:56 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id k6RFbok9039942; Thu, 27 Jul 2006 17:37:50 +0200 (CEST) (envelope-from olli) Date: Thu, 27 Jul 2006 17:37:50 +0200 (CEST) Message-Id: <200607271537.k6RFbok9039942@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG In-Reply-To: <44C7C185.2050601@dmv.com> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.0-20051224 ("Ronay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Thu, 27 Jul 2006 17:37:56 +0200 (CEST) Cc: Subject: Re: filesystem full error with inumber X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 15:37:59 -0000 Sven Willenberger wrote: > This was an upgrade from a 5.x system (UFS2); a full fsck did in fact fix the > problem (for now). Because of past experience I recommend that you disable background fsck (it has a switch in /etc/rc.conf). There are failure scenarios with background fsck that can lead to symptoms similar to what you have experienced. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "C++ is the only current language making COBOL look good." -- Bertrand Meyer From owner-freebsd-stable@FreeBSD.ORG Thu Jul 27 15:45:54 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55E7516A4E0 for ; Thu, 27 Jul 2006 15:45:54 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 96C1543D6B for ; Thu, 27 Jul 2006 15:45:53 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (klyvwf@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id k6RFjkLW040733 for ; Thu, 27 Jul 2006 17:45:52 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id k6RFjkJD040732; Thu, 27 Jul 2006 17:45:46 +0200 (CEST) (envelope-from olli) Date: Thu, 27 Jul 2006 17:45:46 +0200 (CEST) Message-Id: <200607271545.k6RFjkJD040732@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG In-Reply-To: <20060727083620.75d10af2@mablung.edhellond.fbi.ie> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.0-20051224 ("Ronay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Thu, 27 Jul 2006 17:45:52 +0200 (CEST) Cc: Subject: Re: filesystem full error with inumber X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 15:45:54 -0000 Feargal Reilly wrote: > BTW, anybody know what the best method be for double-checking > df's figures would be? du? No, du(1) only sees files that have links (i.e. directory entries). It doesn't see deleted files that occupy space as long as processes still have them open, which can make quite a difference. You can use the command "lsof +L1" to check for such files. If there aren't any on the file system in question, then the number from du(1) should be pretty close to the number from df(1). The df(1) tool just displays the summary records from the file system. The only safe way to verify those numbers is to run fsck(8) manually on the file system (possibly twice). It will fix the summary records if necessary. Then run df(1) again. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "To this day, many C programmers believe that 'strong typing' just means pounding extra hard on the keyboard." -- Peter van der Linden From owner-freebsd-stable@FreeBSD.ORG Thu Jul 27 15:53:32 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 17D6416A4E0 for ; Thu, 27 Jul 2006 15:53:32 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FCEF43D7C for ; Thu, 27 Jul 2006 15:53:30 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (mzebix@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id k6RFrOsR041208 for ; Thu, 27 Jul 2006 17:53:30 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id k6RFrOle041207; Thu, 27 Jul 2006 17:53:24 +0200 (CEST) (envelope-from olli) Date: Thu, 27 Jul 2006 17:53:24 +0200 (CEST) Message-Id: <200607271553.k6RFrOle041207@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG In-Reply-To: <44C8D73F.7010908@rogers.com> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.0-20051224 ("Ronay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Thu, 27 Jul 2006 17:53:30 +0200 (CEST) Cc: Subject: Re: Monitoring temperature with acpi (sysctls) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 15:53:32 -0000 Mike Jakubik wrote: > Bruno Ducrot wrote: > > Could you please try (if you have a working smb device) > > # smbmsg -p > > Well, i don't think its being detected/supported. I tried loading all > the smbus related kernel modules, but no device. > > Id Refs Address Size Name > 1 9 0xc0400000 2d1624 kernel > 2 1 0xc06d2000 606ac acpi.ko > 3 3 0xc4dca000 2000 smbus.ko > 4 1 0xc4dcc000 3000 iicsmb.ko > 5 3 0xc4dcf000 3000 iicbus.ko > 6 1 0xc4de4000 3000 smb.ko > 7 1 0xc4df3000 3000 iic.ko > 8 1 0xc4df6000 3000 if_ic.ko You should also try to load these kernel modules: alpm.ko, amdpm.ko, intpm.ko, viapm.ko > However, dmesg seems to show that there is a SMBus device on the MB. > pci0: at device 31.3 (no driver attached) If none of the mentioned modules attach, please look at the output from "pciconf -lv". What's the entry for your SMBus device (pci0:31:3)? Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. (On the statement print "42 monkeys" + "1 snake":) By the way, both perl and Python get this wrong. Perl gives 43 and Python gives "42 monkeys1 snake", when the answer is clearly "41 monkeys and 1 fat snake". -- Jim Fulton From owner-freebsd-stable@FreeBSD.ORG Thu Jul 27 16:13:43 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 53AD316A4E7 for ; Thu, 27 Jul 2006 16:13:43 +0000 (UTC) (envelope-from ducrot@poupinou.org) Received: from poup.poupinou.org (poup.poupinou.org [195.101.94.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D25E43D49 for ; Thu, 27 Jul 2006 16:13:41 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from ducrot by poup.poupinou.org with local (Exim) id 1G68US-0007kk-00; Thu, 27 Jul 2006 18:13:36 +0200 Date: Thu, 27 Jul 2006 18:13:35 +0200 To: Mike Jakubik Message-ID: <20060727161335.GB17014@poupinou.org> References: <44C63DFD.5040401@rogers.com> <20060726160952.GW17014@poupinou.org> <016E6A0B-E3E4-4444-BD27-24E75C784788@tamu.edu> <44C7BA05.7020508@rogers.com> <44C85C4F.7030902@rogers.com> <20060727074831.GX17014@poupinou.org> <44C8D73F.7010908@rogers.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44C8D73F.7010908@rogers.com> User-Agent: Mutt/1.5.9i From: Bruno Ducrot Cc: David Duchscher , stable@freebsd.org, Jiawei Ye Subject: Re: Monitoring temperature with acpi (sysctls) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 16:13:43 -0000 On Thu, Jul 27, 2006 at 11:09:51AM -0400, Mike Jakubik wrote: > Bruno Ducrot wrote: > >Could you please try (if you have a working smb device) > > > ># smbmsg -p > > > > Well, i don't think its being detected/supported. I tried loading all > the smbus related kernel modules, but no device. > > Id Refs Address Size Name > 1 9 0xc0400000 2d1624 kernel > 2 1 0xc06d2000 606ac acpi.ko > 3 3 0xc4dca000 2000 smbus.ko > 4 1 0xc4dcc000 3000 iicsmb.ko > 5 3 0xc4dcf000 3000 iicbus.ko > 6 1 0xc4de4000 3000 smb.ko > 7 1 0xc4df3000 3000 iic.ko > 8 1 0xc4df6000 3000 if_ic.ko > > However, dmesg seems to show that there is a SMBus device on the MB. > > pci0: at device 31.3 (no driver attached) > It should be ichsmb with a ich7 southbridge IIRC, but there is a missing pci id onto sys/ichsmb/ichsmb_pci.c, (it should be 0x27da8086). Maybe the ich7 isn't supported yet. I don't have time to check more ATM. I'll look intel specs tomorrow. -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. From owner-freebsd-stable@FreeBSD.ORG Thu Jul 27 16:35:00 2006 Return-Path: X-Original-To: stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DEBA16A4E0; Thu, 27 Jul 2006 16:35:00 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9024643D53; Thu, 27 Jul 2006 16:34:59 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id k6RGYDw5079674; Thu, 27 Jul 2006 12:34:31 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-stable@FreeBSD.org Date: Thu, 27 Jul 2006 12:33:51 -0400 User-Agent: KMail/1.6.2 References: <44C63DFD.5040401@rogers.com> <44C8D73F.7010908@rogers.com> <20060727161335.GB17014@poupinou.org> In-Reply-To: <20060727161335.GB17014@poupinou.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200607271233.53741.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.88/1623/Wed Jul 26 18:35:11 2006 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: Mike Jakubik , stable@FreeBSD.org, Bruno Ducrot , Jiawei Ye , David Duchscher Subject: Re: Monitoring temperature with acpi (sysctls) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 16:35:00 -0000 On Thursday 27 July 2006 12:13 pm, Bruno Ducrot wrote: > It should be ichsmb with a ich7 southbridge IIRC, but there is a > missing pci id onto sys/ichsmb/ichsmb_pci.c, (it should be > 0x27da8086). > > Maybe the ich7 isn't supported yet. I don't have time to check > more ATM. I'll look intel specs tomorrow. FYI, see kern/85106: http://www.freebsd.org/cgi/query-pr.cgi?pr=85106 Jung-uk Kim From owner-freebsd-stable@FreeBSD.ORG Thu Jul 27 16:35:00 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DEBA16A4E0; Thu, 27 Jul 2006 16:35:00 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9024643D53; Thu, 27 Jul 2006 16:34:59 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id k6RGYDw5079674; Thu, 27 Jul 2006 12:34:31 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-stable@FreeBSD.org Date: Thu, 27 Jul 2006 12:33:51 -0400 User-Agent: KMail/1.6.2 References: <44C63DFD.5040401@rogers.com> <44C8D73F.7010908@rogers.com> <20060727161335.GB17014@poupinou.org> In-Reply-To: <20060727161335.GB17014@poupinou.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200607271233.53741.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.88/1623/Wed Jul 26 18:35:11 2006 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: Mike Jakubik , stable@FreeBSD.org, Bruno Ducrot , Jiawei Ye , David Duchscher Subject: Re: Monitoring temperature with acpi (sysctls) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 16:35:00 -0000 On Thursday 27 July 2006 12:13 pm, Bruno Ducrot wrote: > It should be ichsmb with a ich7 southbridge IIRC, but there is a > missing pci id onto sys/ichsmb/ichsmb_pci.c, (it should be > 0x27da8086). > > Maybe the ich7 isn't supported yet. I don't have time to check > more ATM. I'll look intel specs tomorrow. FYI, see kern/85106: http://www.freebsd.org/cgi/query-pr.cgi?pr=85106 Jung-uk Kim From owner-freebsd-stable@FreeBSD.ORG Thu Jul 27 16:46:19 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 224D716A4DA for ; Thu, 27 Jul 2006 16:46:19 +0000 (UTC) (envelope-from mikej@rogers.com) Received: from H43.C18.B96.tor.eicat.ca (H43.C18.B96.tor.eicat.ca [66.96.18.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8167543D49 for ; Thu, 27 Jul 2006 16:46:18 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from [127.0.0.1] (desktop.home.local [172.16.0.200]) by H43.C18.B96.tor.eicat.ca (Postfix) with ESMTP id CB7DA11481; Thu, 27 Jul 2006 12:46:07 -0400 (EDT) Message-ID: <44C8EE06.3060701@rogers.com> Date: Thu, 27 Jul 2006 12:47:02 -0400 From: Mike Jakubik User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Bruno Ducrot References: <44C63DFD.5040401@rogers.com> <20060726160952.GW17014@poupinou.org> <016E6A0B-E3E4-4444-BD27-24E75C784788@tamu.edu> <44C7BA05.7020508@rogers.com> <44C85C4F.7030902@rogers.com> <20060727074831.GX17014@poupinou.org> <44C8D73F.7010908@rogers.com> <20060727161335.GB17014@poupinou.org> In-Reply-To: <20060727161335.GB17014@poupinou.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SpamToaster-Information: This messages has been scanned by SpamToaster http://www.digitalprogression.ca X-SpamToaster: Found to be clean X-SpamToaster-SpamCheck: not spam, SpamAssassin (not cached, score=-2.49, required 3.5, ALL_TRUSTED -1.80, AWL 0.00, BAYES_00 -2.60, DK_POLICY_SIGNSOME 0.00, DNS_FROM_RFC_ABUSE 0.20, DNS_FROM_RFC_POST 1.71) X-SpamToaster-From: mikej@rogers.com X-Spam-Status: No Cc: David Duchscher , stable@freebsd.org, Jiawei Ye Subject: Re: Monitoring temperature with acpi (sysctls) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 16:46:19 -0000 Bruno Ducrot wrote: > It should be ichsmb with a ich7 southbridge IIRC, but there is a > missing pci id onto sys/ichsmb/ichsmb_pci.c, (it should be > 0x27da8086). > > Maybe the ich7 isn't supported yet. I don't have time to check > more ATM. I'll look intel specs tomorrow. > It indeed is a ich7. none0@pci0:31:3: class=0x0c0500 card=0x798015d9 chip=0x27da8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) SMBus Controller' class = serial bus subclass = SMBus Thanks for taking an interest guys, let me know how i can help. From owner-freebsd-stable@FreeBSD.ORG Thu Jul 27 16:47:42 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2187A16A4FC; Thu, 27 Jul 2006 16:47:42 +0000 (UTC) (envelope-from mikej@rogers.com) Received: from H43.C18.B96.tor.eicat.ca (H43.C18.B96.tor.eicat.ca [66.96.18.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id B152C43D53; Thu, 27 Jul 2006 16:47:41 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from [127.0.0.1] (desktop.home.local [172.16.0.200]) by H43.C18.B96.tor.eicat.ca (Postfix) with ESMTP id 3636311481; Thu, 27 Jul 2006 12:47:31 -0400 (EDT) Message-ID: <44C8EE5A.4070205@rogers.com> Date: Thu, 27 Jul 2006 12:48:26 -0400 From: Mike Jakubik User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Jung-uk Kim References: <44C63DFD.5040401@rogers.com> <44C8D73F.7010908@rogers.com> <20060727161335.GB17014@poupinou.org> <200607271233.53741.jkim@FreeBSD.org> In-Reply-To: <200607271233.53741.jkim@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SpamToaster-Information: This messages has been scanned by SpamToaster http://www.digitalprogression.ca X-SpamToaster: Found to be clean X-SpamToaster-SpamCheck: not spam, SpamAssassin (not cached, score=-2.49, required 3.5, ALL_TRUSTED -1.80, AWL 0.00, BAYES_00 -2.60, DK_POLICY_SIGNSOME 0.00, DNS_FROM_RFC_ABUSE 0.20, DNS_FROM_RFC_POST 1.71) X-SpamToaster-From: mikej@rogers.com X-Spam-Status: No Cc: Bruno Ducrot , freebsd-stable@FreeBSD.org Subject: Re: Monitoring temperature with acpi (sysctls) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 16:47:42 -0000 Jung-uk Kim wrote: > FYI, see kern/85106: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=85106 > Great, i will try the patch shortly. From owner-freebsd-stable@FreeBSD.ORG Thu Jul 27 17:02:00 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9BF1B16A4E0 for ; Thu, 27 Jul 2006 17:02:00 +0000 (UTC) (envelope-from dwilde1@gmail.com) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id C336B43D4C for ; Thu, 27 Jul 2006 17:01:59 +0000 (GMT) (envelope-from dwilde1@gmail.com) Received: by wx-out-0102.google.com with SMTP id t13so1273081wxc for ; Thu, 27 Jul 2006 10:01:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=ZxOR8ZcPhFPkw0ftAWV1W+vaXVv7MQMwBYZg+Pqya4muRZYMu7FD8hxi31NSdewO3rwDjHhm427ktyOWZ4Zv22t4frKXvLsJ98NZLFxXZpfCwOA3KWg98/zIdG7UlB6CFWZA9z/Nhk0uCX8Qy5WbTv6CzWn0bekNzfMkby9OsyU= Received: by 10.70.50.18 with SMTP id x18mr1043922wxx; Thu, 27 Jul 2006 10:01:59 -0700 (PDT) Received: by 10.70.16.9 with HTTP; Thu, 27 Jul 2006 10:01:59 -0700 (PDT) Message-ID: Date: Thu, 27 Jul 2006 12:01:59 -0500 From: "Don Wilde" Sender: dwilde1@gmail.com To: freebsd-stable@freebsd.org MIME-Version: 1.0 X-Google-Sender-Auth: 6d130d82436b5560 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: iwi(4) in RELENG_6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 17:02:00 -0000 * *> >* I have "device iwi" in my kernel configuration. Should I remove it and *> >* use a module instead? Or is this supposed to work? * > This is from the firmware(9) support code. Add "options firmware" and you > should be fine. You will still need to load the firmware blobs as modules, > but that's another story. I have looked at man 9 firmware and man 9 module, and the /usr/share/examples/kld. My STABLE is as of July 20. firmware_get: failed to load firmware image iwi_bss iwi0: could not load firmware I started by posting this a week ago to -mobile, but, beyond the 'options firmware' suggestion, nobody there had any suggestions. From owner-freebsd-stable@FreeBSD.ORG Thu Jul 27 17:39:17 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 544A816A4DE; Thu, 27 Jul 2006 17:39:17 +0000 (UTC) (envelope-from mikej@rogers.com) Received: from H43.C18.B96.tor.eicat.ca (H43.C18.B96.tor.eicat.ca [66.96.18.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE99B43D53; Thu, 27 Jul 2006 17:39:16 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from [127.0.0.1] (desktop.home.local [172.16.0.200]) by H43.C18.B96.tor.eicat.ca (Postfix) with ESMTP id 2B3671141A; Thu, 27 Jul 2006 13:39:08 -0400 (EDT) Message-ID: <44C8FA73.9060503@rogers.com> Date: Thu, 27 Jul 2006 13:40:03 -0400 From: Mike Jakubik User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Mike Jakubik References: <44C63DFD.5040401@rogers.com> <44C8D73F.7010908@rogers.com> <20060727161335.GB17014@poupinou.org> <200607271233.53741.jkim@FreeBSD.org> <44C8EE5A.4070205@rogers.com> In-Reply-To: <44C8EE5A.4070205@rogers.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SpamToaster-Information: This messages has been scanned by SpamToaster http://www.digitalprogression.ca X-SpamToaster: Found to be clean X-SpamToaster-SpamCheck: not spam, SpamAssassin (not cached, score=-2.49, required 3.5, ALL_TRUSTED -1.80, BAYES_00 -2.60, DK_POLICY_SIGNSOME 0.00, DNS_FROM_RFC_ABUSE 0.20, DNS_FROM_RFC_POST 1.71) X-SpamToaster-From: mikej@rogers.com X-Spam-Status: No Cc: Bruno Ducrot , freebsd-stable@FreeBSD.org, Jung-uk Kim Subject: Re: Monitoring temperature with acpi (sysctls) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 17:39:17 -0000 Well, here are the patch results. The controller is detected: ichsmb0: port 0x1100-0x111f irq 19 at device 31.3 on pci0 ichsmb0: [GIANT-LOCKED] smbus0: on ichsmb0 smb0: on smbus0 However communication does not seem to work: # smbmsg -p Probing for devices on /dev/smb0: Device @0x30: rw Device @0x32: rw ^C ichsmb0: device timeout, status=0x41 ichsmb0: device timeout, status=0x41 ichsmb0: device timeout, status=0x41 I also tried running mbmon using SMB, however this is the result: # mbmon -S No SMBus HWM available!! InitMBInfo: Unknown error: 0 Without any options, i get bogus temp values: # mbmon Temp.= 208.0, 0.0, 0.0; Rot.= 0, 0, 0 Vcore = 3.62, 3.62; Volt. = 3.62, 5.21, 11.80, 1.13, 2.09 From owner-freebsd-stable@FreeBSD.ORG Thu Jul 27 18:01:28 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9647116A4DA for ; Thu, 27 Jul 2006 18:01:28 +0000 (UTC) (envelope-from karagodov@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C3F143D53 for ; Thu, 27 Jul 2006 18:01:27 +0000 (GMT) (envelope-from karagodov@gmail.com) Received: by py-out-1112.google.com with SMTP id b36so316191pyb for ; Thu, 27 Jul 2006 11:01:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=sjdJel7yKXlokdYt8bU1WAT0lbjhLwXKfkRAS4RQR9UxD7qtzVn8mg7o/fpLdGKDQBZT0jTV72XMFRVWFKno3PmVqE6MancUt392cv4qae3MSotG3gaOKwaI3L1oIHrPipBsS0gjy2IHfJHSUUYU92AQlyqsW7nLtVuvMIu2BwE= Received: by 10.35.62.19 with SMTP id p19mr13516215pyk; Thu, 27 Jul 2006 11:01:25 -0700 (PDT) Received: by 10.35.66.6 with HTTP; Thu, 27 Jul 2006 11:01:24 -0700 (PDT) Message-ID: Date: Thu, 27 Jul 2006 22:01:24 +0400 From: "Alexey Karagodov" To: freebsd-stable@freebsd.org In-Reply-To: <200607271553.k6RFrOle041207@lurza.secnetix.de> MIME-Version: 1.0 References: <44C8D73F.7010908@rogers.com> <200607271553.k6RFrOle041207@lurza.secnetix.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Monitoring temperature with acpi (sysctls) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 18:01:28 -0000 ichsmb0@pci0:31:3: class=0x0c0500 card=0x618015d9 chip=0x24d38086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801EB/ER (ICH5/ICH5R) SMBus Controller' class = serial bus subclass = SMBus 2006/7/27, Oliver Fromme : > > Mike Jakubik wrote: > > Bruno Ducrot wrote: > > > Could you please try (if you have a working smb device) > > > # smbmsg -p > > > > Well, i don't think its being detected/supported. I tried loading all > > the smbus related kernel modules, but no device. > > > > Id Refs Address Size Name > > 1 9 0xc0400000 2d1624 kernel > > 2 1 0xc06d2000 606ac acpi.ko > > 3 3 0xc4dca000 2000 smbus.ko > > 4 1 0xc4dcc000 3000 iicsmb.ko > > 5 3 0xc4dcf000 3000 iicbus.ko > > 6 1 0xc4de4000 3000 smb.ko > > 7 1 0xc4df3000 3000 iic.ko > > 8 1 0xc4df6000 3000 if_ic.ko > > You should also try to load these kernel modules: > alpm.ko, amdpm.ko, intpm.ko, viapm.ko > > > However, dmesg seems to show that there is a SMBus device on the MB. > > pci0: at device 31.3 (no driver attached) > > If none of the mentioned modules attach, please look > at the output from "pciconf -lv". What's the entry > for your SMBus device (pci0:31:3)? > > Best regards > Oliver > > -- > Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing > Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd > Any opinions expressed in this message may be personal to the author > and may not necessarily reflect the opinions of secnetix in any way. > > (On the statement print "42 monkeys" + "1 snake":) By the way, > both perl and Python get this wrong. Perl gives 43 and Python > gives "42 monkeys1 snake", when the answer is clearly "41 monkeys > and 1 fat snake". -- Jim Fulton > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Thu Jul 27 18:15:42 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5540116A4E2; Thu, 27 Jul 2006 18:15:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0121F43D78; Thu, 27 Jul 2006 18:15:29 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k6RIFP32078798; Thu, 27 Jul 2006 14:15:28 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Mike Jakubik Date: Thu, 27 Jul 2006 13:58:16 -0400 User-Agent: KMail/1.9.1 References: <44C7ED5F.6060902@rogers.com> In-Reply-To: <44C7ED5F.6060902@rogers.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607271358.17333.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 27 Jul 2006 14:15:29 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1623/Wed Jul 26 18:35:11 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: stable@freebsd.org, phk@freebsd.org Subject: Re: MFC of kern_resource.c (calru changes) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 18:15:42 -0000 On Wednesday 26 July 2006 18:31, Mike Jakubik wrote: > Are there any plans to MFC the last few commits to kern_resource.c to > -STABLE? I have a number of machines which flood the logs with "calcru: > negative runtime" messages every time w, ps or top is used, so im hoping > these may fix the issue. I think it involves an ABI breakage, so I doubt it. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Thu Jul 27 18:20:32 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 81B2716A4DD for ; Thu, 27 Jul 2006 18:20:32 +0000 (UTC) (envelope-from mark@hydrus.org.uk) Received: from blaster.systems.pipex.net (blaster.systems.pipex.net [62.241.163.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C13843D8F for ; Thu, 27 Jul 2006 18:20:16 +0000 (GMT) (envelope-from mark@hydrus.org.uk) Received: from crimson.hydrus.org.uk (81-86-154-21.dsl.pipex.com [81.86.154.21]) by blaster.systems.pipex.net (Postfix) with ESMTP id 25CD2E00027D; Thu, 27 Jul 2006 19:20:13 +0100 (BST) Received: from crimson.hydrus.org.uk (localhost [127.0.0.1]) by crimson.hydrus.org.uk (8.13.6/8.13.1) with ESMTP id k6RIMIuU097315; Thu, 27 Jul 2006 19:22:18 +0100 (BST) (envelope-from mark@crimson.hydrus.org.uk) Received: (from mark@localhost) by crimson.hydrus.org.uk (8.13.6/8.13.1/Submit) id k6RIMHp2097311; Thu, 27 Jul 2006 19:22:17 +0100 (BST) (envelope-from mark) Date: Thu, 27 Jul 2006 19:22:17 +0100 (BST) From: Mark Willson Message-Id: <200607271822.k6RIMHp2097311@crimson.hydrus.org.uk> To: Don@Silver-Lynx.com, freebsd-stable@freebsd.org In-Reply-To: Cc: Subject: Re: iwi(4) in RELENG_6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 18:20:32 -0000 Have you tried using the firmware from iwi-firmware-kmod, rather than iwi-firmware. I am using the former on a Thinkpad T42 and it is working ok. -mark From owner-freebsd-stable@FreeBSD.ORG Thu Jul 27 18:46:09 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7BE1216A4E2; Thu, 27 Jul 2006 18:46:09 +0000 (UTC) (envelope-from mikej@rogers.com) Received: from H43.C18.B96.tor.eicat.ca (H43.C18.B96.tor.eicat.ca [66.96.18.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C79843D6D; Thu, 27 Jul 2006 18:46:08 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from [127.0.0.1] (desktop.home.local [172.16.0.200]) by H43.C18.B96.tor.eicat.ca (Postfix) with ESMTP id C3A411147D; Thu, 27 Jul 2006 14:45:55 -0400 (EDT) Message-ID: <44C90A1B.2050200@rogers.com> Date: Thu, 27 Jul 2006 14:46:51 -0400 From: Mike Jakubik User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: John Baldwin References: <44C7ED5F.6060902@rogers.com> <200607271358.17333.jhb@freebsd.org> In-Reply-To: <200607271358.17333.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SpamToaster-Information: This messages has been scanned by SpamToaster http://www.digitalprogression.ca X-SpamToaster: Found to be clean X-SpamToaster-SpamCheck: not spam, SpamAssassin (not cached, score=-2.49, required 3.5, ALL_TRUSTED -1.80, AWL 0.00, BAYES_00 -2.60, DK_POLICY_SIGNSOME 0.00, DNS_FROM_RFC_ABUSE 0.20, DNS_FROM_RFC_POST 1.71) X-SpamToaster-From: mikej@rogers.com X-Spam-Status: No Cc: stable@freebsd.org, phk@freebsd.org Subject: Re: MFC of kern_resource.c (calru changes) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 18:46:09 -0000 John Baldwin wrote: > On Wednesday 26 July 2006 18:31, Mike Jakubik wrote: > >> Are there any plans to MFC the last few commits to kern_resource.c to >> -STABLE? I have a number of machines which flood the logs with "calcru: >> negative runtime" messages every time w, ps or top is used, so im hoping >> these may fix the issue. >> > > I think it involves an ABI breakage, so I doubt it. > > Thats unfortunate, as i just finished extensively testing the system with -CURRENT. There are no calcru messages, and no negative timestamps on processes occurring. In fact, everything is working perfectly. Is there anything that can be done to address this problem on -STABLE? From owner-freebsd-stable@FreeBSD.ORG Thu Jul 27 19:01:09 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 023F516A4DF for ; Thu, 27 Jul 2006 19:01:09 +0000 (UTC) (envelope-from dwilde1@gmail.com) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 678DC43D5C for ; Thu, 27 Jul 2006 19:01:04 +0000 (GMT) (envelope-from dwilde1@gmail.com) Received: by wx-out-0102.google.com with SMTP id h30so1346203wxd for ; Thu, 27 Jul 2006 12:01:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=D4/XnBynRNvqEurojWeNwVVYq/sk3m7yGYF104Gm3nMV8Uc+GTwdRLV60N1RC3q/mO4hfSY1/2zzY6UzTUXB86zFfnSKTEIYzwuYFFmICno45WZwVieVaDzNWk4ALeVWzGkk47ildSQUc9ffOGw8Gr2Ro7ACXULAp6ekeWu0jZs= Received: by 10.70.131.19 with SMTP id e19mr973277wxd; Thu, 27 Jul 2006 12:01:03 -0700 (PDT) Received: by 10.70.16.9 with HTTP; Thu, 27 Jul 2006 12:01:03 -0700 (PDT) Message-ID: Date: Thu, 27 Jul 2006 14:01:03 -0500 From: "Don Wilde" Sender: dwilde1@gmail.com To: "Mark Willson" In-Reply-To: <200607271822.k6RIMHp2097311@crimson.hydrus.org.uk> MIME-Version: 1.0 References: <200607271822.k6RIMHp2097311@crimson.hydrus.org.uk> X-Google-Sender-Auth: 65fc2b31234b3507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: iwi(4) in RELENG_6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 19:01:09 -0000 Yes, I have. I just did another CVSup, and when I recompiled -kmod it did indeed put a bunch of .ko files in /build/modules, but a) I still get a whole bunch of Can't load firmware complaints, and b) it doesn't work. It goes through the DISCOVER process, but doesn't get any offers it recognizes. I've tried this both with an open DHCP and also with my parameters wired in. Hardware notes: Dell 6100 Inspiron with 2200G iwi. I have heard from another gent who has a 2200G pci card and is having the same problem with STABLE. This all was working two weeks ago. On 7/27/06, Mark Willson wrote: > > Have you tried using the firmware from iwi-firmware-kmod, rather than > iwi-firmware. I am using the former on a Thinkpad T42 and it is working > ok. > > -mark > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Thu Jul 27 19:17:51 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 570A816A4E1 for ; Thu, 27 Jul 2006 19:17:51 +0000 (UTC) (envelope-from mark@hydrus.org.uk) Received: from ranger.systems.pipex.net (ranger.systems.pipex.net [62.241.162.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id DDA2243D4C for ; Thu, 27 Jul 2006 19:17:50 +0000 (GMT) (envelope-from mark@hydrus.org.uk) Received: from crimson.hydrus.org.uk (81-86-154-21.dsl.pipex.com [81.86.154.21]) by ranger.systems.pipex.net (Postfix) with ESMTP id 11943E0000AC; Thu, 27 Jul 2006 20:17:48 +0100 (BST) Received: from crimson.hydrus.org.uk (localhost [127.0.0.1]) by crimson.hydrus.org.uk (8.13.6/8.13.1) with ESMTP id k6RJJqq2097511; Thu, 27 Jul 2006 20:19:52 +0100 (BST) (envelope-from mark@crimson.hydrus.org.uk) Received: (from mark@localhost) by crimson.hydrus.org.uk (8.13.6/8.13.1/Submit) id k6RJJqOr097510; Thu, 27 Jul 2006 20:19:52 +0100 (BST) (envelope-from mark) Date: Thu, 27 Jul 2006 20:19:52 +0100 (BST) From: Mark Willson Message-Id: <200607271919.k6RJJqOr097510@crimson.hydrus.org.uk> To: Don@Silver-Lynx.com, mark@hydrus.org.uk In-Reply-To: Cc: freebsd-stable@freebsd.org Subject: Re: iwi(4) in RELENG_6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 19:17:51 -0000 > From: "Don Wilde" > Yes, I have. I just did another CVSup, and when I recompiled -kmod it did > indeed put a bunch of .ko files in /build/modules, but a) I still get a > whole bunch of Can't load firmware complaints, and b) it doesn't work. It > goes through the DISCOVER process, but doesn't get any offers it recognizes. > I've tried this both with an open DHCP and also with my parameters wired in. > > Hardware notes: Dell 6100 Inspiron with 2200G iwi. I have heard from another > gent who has a 2200G pci card and is having the same problem with STABLE. > > This all was working two weeks ago. That is, indeed, a drag. b) is bad. We are using different hardware, which I guess could be a factor. When I can boot this thing under FreeBSD (work intervenes at present) I'll post what iwi-firmware-kmod put where. -mark From owner-freebsd-stable@FreeBSD.ORG Thu Jul 27 19:47:48 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 961B916A4DF for ; Thu, 27 Jul 2006 19:47:48 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6CD6943D55 for ; Thu, 27 Jul 2006 19:47:45 +0000 (GMT) (envelope-from arno@heho.snv.jussieu.fr) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.13.7/jtpda-5.4) with ESMTP id k6RJlitB058557 ; Thu, 27 Jul 2006 21:47:44 +0200 (CEST) X-Ids: 168 Received: from heho.labo (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.13.3/jtpda-5.2) with ESMTP id k6RJlh1I030701 ; Thu, 27 Jul 2006 21:47:43 +0200 (MEST) Received: (from arno@localhost) by heho.labo (8.13.3/8.13.1/Submit) id k6RJlgrB030698; Thu, 27 Jul 2006 21:47:42 +0200 (MEST) (envelope-from arno) Sender: arno@heho.snv.jussieu.fr To: freebsd-stable@freebsd.org From: "Arno J. Klaassen" Date: 27 Jul 2006 21:47:42 +0200 Message-ID: Lines: 66 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (shiva.jussieu.fr [134.157.0.168]); Thu, 27 Jul 2006 21:47:44 +0200 (CEST) X-Virus-Scanned: ClamAV 0.88.2/1624/Thu Jul 27 19:11:25 2006 on shiva.jussieu.fr X-Virus-Status: Clean Cc: wpaul@windriver.com Subject: nfs-client reveals MFC-if_re-probs (or vice-versa) ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 19:47:48 -0000 Hello, I have a curious problem which at first sight seems related to the end-June MFC of if_re : - I 'mount -o nfsv3,intr,noconn,-r=32768,-w=32768 <-stable-server>:/files/bsd /files/bsd ' - (/usr/ports and /usr/src are symlinks to /files/bsd/*) quickly after a portinstall/portversion etc. I get : nfs server <-stable-server>: not responding (and the corresponding process stuck in 'bo_wwa' according to top(1) ) - though I still can 'ping <-stable-server>' and even 'ssh me@<-stable-server-IP>' - <-stable-server> works ok with two other -stable clients (using if_bge) and all are compiled from the very same source-base (and <-stable-server> works fine as well with a linux-client) which seems to exclude nfsd-probs - a kernel from June the 11th works ok - downgrading if_re.c to revision 1.46.2.14 and if_rlreg.h to revision 1.51.2.3 makes the problem disappear - this is on my demo-notebook, I can test network stuff without much limitations; I just use nfs on it for upgrading world and ports. NB, same behaviour on amd64-stable and i386-stable (multi-boot same hardware) I can fill a PR if requested or feel free to contact me for further testing. Best regards, Arno PS: relevant pciconf info : re0@pci0:8:0: class=0x020000 card=0x47011558 chip=0x816910ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8169 Gigabit Ethernet Adapter' class = network subclass = ethernet otherwise standard kernel conf with stripped unneeded drivers and extra : device cpufreq device atapicam device sound options TCP_DROP_SYNFIN (hint??) -- Arno J. Klaassen SCITO S.A. 8 rue des Haies F-75020 Paris, France http://scito.com From owner-freebsd-stable@FreeBSD.ORG Thu Jul 27 20:45:08 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8908716A4DA for ; Thu, 27 Jul 2006 20:45:08 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FF8843D60 for ; Thu, 27 Jul 2006 20:45:02 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.188.213] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis), id 0MKwh2-1G6CiO3mgk-0001ve; Thu, 27 Jul 2006 22:44:19 +0200 From: Max Laier Organization: FreeBSD To: freebsd-stable@freebsd.org Date: Thu, 27 Jul 2006 22:44:06 +0200 User-Agent: KMail/1.9.3 References: <200607271822.k6RIMHp2097311@crimson.hydrus.org.uk> In-Reply-To: X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1314111.pj4uJRd5Jv"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200607272244.13115.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: Mark Willson , Don Wilde Subject: Re: iwi(4) in RELENG_6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 20:45:08 -0000 --nextPart1314111.pj4uJRd5Jv Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline [Please don't top-post] On Thursday 27 July 2006 21:01, Don Wilde wrote: > Yes, I have. I just did another CVSup, and when I recompiled -kmod it did > indeed put a bunch of .ko files in /build/modules, but a) I still get a > whole bunch of Can't load firmware complaints, and b) it doesn't work. It > goes through the DISCOVER process, but doesn't get any offers it > recognizes. I've tried this both with an open DHCP and also with my > parameters wired in. > > Hardware notes: Dell 6100 Inspiron with 2200G iwi. I have heard from > another gent who has a 2200G pci card and is having the same problem with > STABLE. > > This all was working two weeks ago. Just to get the facts straight and assembled in one place: You are running a somewhat recent RELENG_6, have net/iwi-firmware-kmod=20 installed and "device iwi" and "options firmware" built into your kernel? When do you get the "Can't load firmware" messages? What does kldstat [-v]= =20 say before and after that point? Can you try "kldload iwi_bss" before and= =20 see if that gets you up and running? > On 7/27/06, Mark Willson wrote: > > Have you tried using the firmware from iwi-firmware-kmod, rather than > > iwi-firmware. I am using the former on a Thinkpad T42 and it is working > > ok. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1314111.pj4uJRd5Jv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQBEySWdXyyEoT62BG0RAk4tAJsFc2X6oXVpc/5i0ssaQSUOTfXTCwCeKjyO 74z9bsdlYmj3nAyLXlrL3CY= =miiV -----END PGP SIGNATURE----- --nextPart1314111.pj4uJRd5Jv-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 27 23:47:18 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E37B216A4DE; Thu, 27 Jul 2006 23:47:18 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E5B143D46; Thu, 27 Jul 2006 23:47:18 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id k6RNlGln095574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Jul 2006 16:47:18 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <44C95084.6020209@errno.com> Date: Thu, 27 Jul 2006 16:47:16 -0700 From: Sam Leffler User-Agent: Thunderbird 1.5.0.4 (X11/20060724) MIME-Version: 1.0 To: Andrew Thompson References: <20060720224632.GB31459@osgiliath.brixandersen.dk> <44C00B40.2010901@errno.com> <20060726144058.GD3077@osgiliath.opasia.dk> <44C793DB.5090900@errno.com> <20060726163017.GB5856@osgiliath.opasia.dk> <44C7AF68.3090109@errno.com> <20060726181534.GD5856@osgiliath.opasia.dk> <44C7D05C.8000408@errno.com> <20060726215341.GA7763@heff.fud.org.nz> In-Reply-To: <20060726215341.GA7763@heff.fud.org.nz> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: "scan stuck" with if_iwi(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 23:47:19 -0000 Andrew Thompson wrote: > On Wed, Jul 26, 2006 at 01:28:12PM -0700, Sam Leffler wrote: >> Henrik Brix Andersen wrote: >>> Oh? Sounds interesting, where can I find these patches? >> The work has always been in perforce.freebsd.org; look in the sam_wifi >> branch. The code will not hit head until folks show up to fix legacy >> drivers that use net80211. I got stuck holding the bag when I committed >> the wpa support and it ain't going to happen again. >> > > Do you have a list of drivers that are stalling this? The changes decouple scanning from the net80211 state machine so any driver that uses ieee80211_new_state is affected: tubby% grep -l ieee80211_new_state */*.c ath/if_ath.c awi/awi.c ipw/if_ipw.c iwi/if_iwi.c ral/rt2560.c ral/rt2661.c usb/if_ural.c wi/if_wi.c I know how to convert ath and ral. iwi and ipw might not be too bad now that they've been changed to not abuse the state machine so much. awi, ural, and wi will break. ural might be ok after the new usb stack comes in but that's not clear. So I guess I'd take responsibility for ath and ral and want help with all other drivers. Sam From owner-freebsd-stable@FreeBSD.ORG Fri Jul 28 00:00:05 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E1B5D16A4DD for ; Fri, 28 Jul 2006 00:00:05 +0000 (UTC) (envelope-from dwilde1@gmail.com) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C67043D49 for ; Fri, 28 Jul 2006 00:00:04 +0000 (GMT) (envelope-from dwilde1@gmail.com) Received: by wx-out-0102.google.com with SMTP id s16so181259wxc for ; Thu, 27 Jul 2006 17:00:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=MRLEqNashJNVpCQRgZ4cAduQvieq+KwTP8TL5NcAOSyD162WVXpuyPePfwzTssa7rdjUjRm1VTX73kRZ4aZp+FwZ42jWzj8lXhjMGMetrtoqjFQP3pYMcdQIba8hV/t7Zn+3mGCUQP10xpmNy3x0o5/eSV8aqFiycYFzdgEl/qk= Received: by 10.70.34.17 with SMTP id h17mr1457103wxh; Thu, 27 Jul 2006 17:00:04 -0700 (PDT) Received: by 10.70.16.9 with HTTP; Thu, 27 Jul 2006 17:00:04 -0700 (PDT) Message-ID: Date: Thu, 27 Jul 2006 19:00:04 -0500 From: "Don Wilde" Sender: dwilde1@gmail.com To: "Max Laier" In-Reply-To: <200607272244.13115.max@love2party.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_87347_31280105.1154044804161" References: <200607271822.k6RIMHp2097311@crimson.hydrus.org.uk> <200607272244.13115.max@love2party.net> X-Google-Sender-Auth: dbb75ed926072e54 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: iwi(4) in RELENG_6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 00:00:06 -0000 ------=_Part_87347_31280105.1154044804161 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 7/27/06, Max Laier wrote: > > [Please don't top-post] > > On Thursday 27 July 2006 21:01, Don Wilde wrote: > > Yes, I have. I just did another CVSup, and when I recompiled -kmod it > did > > indeed put a bunch of .ko files in /build/modules, but a) I still get a > > whole bunch of Can't load firmware complaints, and b) it doesn't work. > It > > goes through the DISCOVER process, but doesn't get any offers it > > recognizes. I've tried this both with an open DHCP and also with my > > parameters wired in. > > > > Hardware notes: Dell 6100 Inspiron with 2200G iwi. I have heard from > > another gent who has a 2200G pci card and is having the same problem > with > > STABLE. > > > > This all was working two weeks ago. > > Just to get the facts straight and assembled in one place: > > You are running a somewhat recent RELENG_6, have net/iwi-firmware-kmod > installed and "device iwi" and "options firmware" built into your kernel? > > When do you get the "Can't load firmware" messages? What does kldstat > [-v] > say before and after that point? Can you try "kldload iwi_bss" before and > see if that gets you up and running? > > > On 7/27/06, Mark Willson wrote: > > > Have you tried using the firmware from iwi-firmware-kmod, rather than > > > iwi-firmware. I am using the former on a Thinkpad T42 and it is > working > > > ok. Hi, Max - I did so, and it appears that the module is already loaded. It seems that the problems occur because my system is also trying to load the old firmware somehow. A more disturbing issue is that my rc.conf seems to be being read twice. I see the kldstat reports (with my echo commands) being printed four times instead of the two I'm requesting. Attached are my rc.conf and dmesg. ------=_Part_87347_31280105.1154044804161 Content-Type: application/octet-stream; name=rc.cnf Content-Transfer-Encoding: base64 X-Attachment-Id: f_eq5sfhaa Content-Disposition: attachment; filename="rc.cnf" CiMgLS0gc3lzaW5zdGFsbCBnZW5lcmF0ZWQgZGVsdGFzIC0tICMgU3VuIEphbiAgMSAwOToyNTox MSAyMDA2CiMgQ3JlYXRlZDogU3VuIEphbiAgMSAwOToyNToxMSAyMDA2CiMgRW5hYmxlIG5ldHdv cmsgZGFlbW9ucyBmb3IgdXNlciBjb252ZW5pZW5jZS4KIyBQbGVhc2UgbWFrZSBhbGwgY2hhbmdl cyB0byB0aGlzIGZpbGUsIG5vdCB0byAvZXRjL2RlZmF1bHRzL3JjLmNvbmYuCiMgVGhpcyBmaWxl IG5vdyBjb250YWlucyBqdXN0IHRoZSBvdmVycmlkZXMgZnJvbSAvZXRjL2RlZmF1bHRzL3JjLmNv bmYuCmJsYW5rdGltZT0iMzAwIgpsaW51eF9lbmFibGU9IllFUyIKbW91c2VkX2VuYWJsZT0iWUVT Igptb3VzZWRfcG9ydD0iL2Rldi9wc20wIgptb3VzZWRfdHlwZT0iYXV0byIKbW91c2VkX2ZsYWdz PSItMyIKc2F2ZXI9InNuYWtlIgpzc2hkX2VuYWJsZT0iWUVTIgp1c2JkX2VuYWJsZT0iWUVTIgpo b3N0bmFtZT0ibHlueC5uZXR3b3JrLWx5bngubmV0IgpkZWZhdWx0X3JvdXRlcj0iMTkyLjE2OC4x MC4xIgppZmNvbmZpZ19iZmUwPSJESENQIgphcG1fZW5hYmxlPSJOTyIKZWNobyAnaXdpIGZpcm13 YXJlIGxvYWQnCmtsZHN0YXQgLXYKa2xkbG9hZCBpd2lfYnNzCmVjaG8gJ2FmdGVyIGl3aSBsb2Fk JwprbGRzdGF0IC12CmlmY29uZmlnX2l3aTA9IkRIQ1Agc3NpZCByZXdpcmVkIGNoYW5uZWwgMTEg YXV0aG1vZGUgc2hhcmVkIHdlcHR4a2V5IDEgd2VwbW9kZSBvbiB3ZXBrZXkgMHgxMjM0NTY3ODkw IgojaWZjb25maWdfaXdpMD0iREhDUCIKaXdpX2VuYWJsZT0iWUVTIgojaXdpX2VuYWJsZT0iTk8i Cml3aV9pbnRlcmZhY2VzPSJpd2kwIgpwb3dlcmRfZW5hYmxlPSJZRVMiCnBvd2VyZF9mbGFncz0i LWEgbWF4aW11bSAtYiBhZGFwdGl2ZSAtaSA5NSAtciA2MCAtcCAyMDAwIgojcG93ZXJkX2ZsYWdz PSItYSBtYXhpbXVtIC1iIG1heGltdW0gLXAgMjAwMCIKZWNvbm9teV9jeF9sb3dlc3Q9IkxPVyIK ------=_Part_87347_31280105.1154044804161 Content-Type: application/octet-stream; name=dmesg.iwi Content-Transfer-Encoding: base64 X-Attachment-Id: f_eq5sg82z Content-Disposition: attachment; filename="dmesg.iwi" MTE4PgkJNTUgY3B1L2FjcGlfcGVyZgoJCTU2IGFjcGkvYWNwaV9zbWJhdAoJCTU3IGNwdS9hY3Bp X3Rocm90dGxlCjI5ICAgIDEgMHhjNGVkNjAwMCAzMDAwMCAgICBpd2lfYnNzLmtvCglDb250YWlu cyBtb2R1bGVzOgoJCUlkIE5hbWUKCQkyMzkgaXdpX2Jzc19mdwpBZGRpdGlvbmFsIHJvdXRpbmcg b3B0aW9uczoKLgpNb3VudGluZyBORlMgZmlsZSBzeXN0ZW1zOgouCml3aSBmaXJtd2FyZSBsb2Fk CklkIFJlZnMgQWRkcmVzcyAgICBTaXplICAgICBOYW1lCiAxICAgMzEgMHhjMDQwMDAwMCAzNTc2 ZjAgICBrZXJuZWwKCUNvbnRhaW5zIG1vZHVsZXM6CgkJSWQgTmFtZQoJCTU4IGNhbQoJCTU5IHBy b2JlCgkJNjAgeHB0CgkJNjEgY2QKCQk2MiBwYXNzCgkJNjMgYXRhCgkJNjQgcGNjYXJkL2F0YQoJ CTY1IGF0YS9hZAoJCTY2IGlzYS9hdGEKCQk2NyBhdGFwY2kvYXRhCgkJNjggcGNpL2F0YXBjaQoJ CTY5IGF0YS9hdGFwaWNhbQoJCTcwIGF0YS9hY2QKCQk3MSBiZmUvbWlpYnVzCgkJNzIgcGNpL2Jm ZQoJCTczIGNiYi9jYXJkYnVzCgkJNzQgZXhjYQoJCTc1IGZ3b2hjaS9maXJld2lyZQoJCTc2IGNh cmRidXMvZndvaGNpCgkJNzcgcGNpL2Z3b2hjaQoJCTc4IGZpcmV3aXJlL2Z3ZQoJCTc5IGZpcmV3 aXJlL3NicAoJCTgwIHBjaS9pd2kKCQk4MSBnX21kCgkJODIgbWVtCgkJODMgbWlpYnVzL2FjcGh5 CgkJODQgbWlpYnVzL2FtcGh5CgkJODUgbWlpYnVzL2JtdHBoeQoJCTg2IG1paWJ1cy9icmdwaHkK CQk4NyBtaWlidXMvY2lwaHkKCQk4OCBtaWlidXMvZTEwMDBwaHkKCQk4OSBtaWlidXMveGxwaHkK CQk5MCBtaWlidXMvaW5waHkKCQk5MSBtaWlidXMvbHh0cGh5CgkJOTIgbWlpYnVzL21scGh5CgkJ OTMgbWlpYnVzL25zZ3BoeQoJCTk0IG1paWJ1cy9uc3BoeQoJCTk1IG1paWJ1cy9wbmFwaHkKCQk5 NiBtaWlidXMvcG5waHkKCQk5NyBtaWlidXMvcXNwaHkKCQk5OCBtaWlidXMvcmdlcGh5CgkJOTkg bWlpYnVzL3JscGh5CgkJMTAwIG1paWJ1cy9ydWVwaHkKCQkxMDEgbWlpYnVzL3Rka3BoeQoJCTEw MiBtaWlidXMvdGxwaHkKCQkxMDMgbWlpYnVzL3VrcGh5CgkJMTA0IG1paWJ1cy94bXBoeQoJCTEw NSBudWxsCgkJMTA2IGNiYi9wY2NhcmQKCQkxMDcgcGNpYy9wY2NhcmQKCQkxMDggaXNhL2NiYgoJ CTEwOSBwY2kvY2JiCgkJMTEwIHBjaS9maXh1cF9wY2kKCQkxMTEgcGNpL2lnbm9yZV9wY2kKCQkx MTIgcGNpL2lzYWIKCQkxMTMgcGNpYi9wY2kKCQkxMTQgcGNpL3BjaWIKCQkxMTUgcHBidXMvbHB0 CgkJMTE2IHBwYy9wcGJ1cwoJCTExNyBwcGJ1cy9wcGkKCQkxMTggcmFuZG9tCgkJMTE5IGF1ZS9t aWlidXMKCQkxMjAgdWh1Yi9hdWUKCQkxMjEgYXhlL21paWJ1cwoJCTEyMiB1aHViL2F4ZQoJCTEy MyB1aHViL2NkY2UKCQkxMjQgdWh1Yi9jdWUKCQkxMjUgdWh1Yi9rdWUKCQkxMjYgcnVlL21paWJ1 cwoJCTEyNyB1aHViL3J1ZQoJCTEyOCBjYXJkYnVzL29oY2kKCQkxMjkgcGNpL29oY2kKCQkxMzAg dWh1Yi91Z2VuCgkJMTMxIGNhcmRidXMvdWhjaQoJCTEzMiBwY2kvdWhjaQoJCTEzMyB1aHViL3Vo aWQKCQkxMzQgdWh1Yi91aHViCgkJMTM1IHVzYi91aHViCgkJMTM2IHVodWIvdWtiZAoJCTEzNyB1 aHViL3VscHQKCQkxMzggdWh1Yi91bWFzcwoJCTEzOSB1aHViL3VtcwoJCTE0MCB1aHViL3VyaW8K CQkxNDEgZWhjaS91c2IKCQkxNDIgdWhjaS91c2IKCQkxNDMgb2hjaS91c2IKCQkxNDQgdWh1Yi91 c2Nhbm5lcgoJCTE0NSB3YXRjaGRvZwoJCTE0NiBkZXZmcwoJCTE0NyBwcm9jZnMKCQkxNDggcHNl dWRvZnMKCQkxNDkgZ19kZXYKCQkxNTAgZ19kaXNrCgkJMTUxIGdfZ3B0CgkJMTUyIGdfdmZzCgkJ MTUzIGVpc2FiL2lzYQoJCTE1NCBpc2FiL2lzYQoJCTE1NSBpc2EvaXNhaGludAoJCTE1NiBpc2Ev b3JtCgkJMTU3IGlzYS9wbnAKCQkxNTggY2Q5NjYwCgkJMTU5IGVsZjMyCgkJMTYwIHNoZWxsCgkJ MTYxIGNwdS9jcHVmcmVxCgkJMTYyIHJvb3RidXMKCQkxNjMgZmlybXdhcmUKCQkxNjQgc3lzdm1z ZwoJCTE2NSBtc2dyY3YKCQkxNjYgbXNnc25kCgkJMTY3IG1zZ2dldAoJCTE2OCBtc2djdGwKCQkx NjkgbXNnc3lzCgkJMTcwIHN5c3ZzZW0KCQkxNzEgc2Vtb3AKCQkxNzIgc2VtZ2V0CgkJMTczIF9f c2VtY3RsCgkJMTc0IHNlbXN5cwoJCTE3NSBzeXN2c2htCgkJMTc2IHNobWdldAoJCTE3NyBzaG1k dAoJCTE3OCBzaG1jdGwKCQkxNzkgc2htYXQKCQkxODAgc2htc3lzCgkJMTgxIGV0aGVyCgkJMTgy IGxvb3AKCQkxODMgaWZfcHBwCgkJMTg0IGlmX3NsCgkJMTg1IGlmX3R1bgoJCTE4NiB3bGFuX3dl cAoJCTE4NyB3bGFuCgkJMTg4IHBjaS9kZQoJCTE4OSB1ZnMKCQkxOTAgZ19jbGFzcwoJCTE5MSBh dGtiZGMvYXRrYmQKCQkxOTIgYWNwaS9hdGtiZGMKCQkxOTMgaXNhL2F0a2JkYwoJCTE5NCBhY3Bp L3BzbWNwbnAKCQkxOTUgaXNhL3BzbWNwbnAKCQkxOTYgYXRrYmRjL3BzbQoJCTE5NyBpbwoJCTE5 OCBhY3BpL3BwYwoJCTE5OSBpc2EvcHBjCgkJMjAwIHNjdGVybS1zYwoJCTIwMSBzY3JuZHItdmdh CgkJMjAyIGdfYnNkCgkJMjAzIGdfbWJyZXh0CgkJMjA0IGdfbWJyCgkJMjA1IGlzYS9wbnBiaW9z CgkJMjA2IGxlZ2FjeS9jcHUKCQkyMDcgbmV4dXMvbGVnYWN5CgkJMjA4IHBjaS9tcHRhYmxlX3Bj aWIKCQkyMDkgbGVnYWN5L21wdGFibGVfcGNpYgoJCTIxMCBpc2Evc3lzcmVzb3VyY2UKCQkyMTEg cm9vdC9uZXh1cwoJCTIxMiBhY3BpL2F0cGljCgkJMjEzIGlzYS9hdHBpYwoJCTIxNCBhY3BpL2F0 dGltZXIKCQkyMTUgaXNhL2F0dGltZXIKCQkyMTYgbGVnYWN5L2lzYQoJCTIxNyBhY3BpL2F0ZG1h CgkJMjE4IGlzYS9hdGRtYQoJCTIxOSBhY3BpL25weGlzYQoJCTIyMCBpc2EvbnB4aXNhCgkJMjIx IG5leHVzL25weAoJCTIyMiBpc2EvcG10aW1lcgoJCTIyMyBwY2kvcGNpYmlvc19wY2liCgkJMjI0 IGlzYS9wY2lidXNfcG5wCgkJMjI1IHBjaS9ob3N0YgoJCTIyNiBsZWdhY3kvcGNpYgoJCTIyNyBs ZWdhY3kvcGlyCgkJMjI4IGlzYS9zYwoJCTIyOSBpc2EvdmdhCgkJMjMwIHBjaS9hZ3BfYWxpCgkJ MjMxIHBjaS9hZ3BfYW1kCgkJMjMyIHBjaS9hZ3BfYW1kNjQKCQkyMzMgcGNpL2FncF9hdGkKCQky MzQgcGNpL2FncF9pODEwCgkJMjM1IHBjaS9hZ3BfaW50ZWwKCQkyMzYgcGNpL2FncF9udmlkaWEK CQkyMzcgcGNpL2FncF9zaXMKCQkyMzggcGNpL2FncF92aWEKIDIgICAgMSAweGMwNzU4MDAwIDMz OGMgICAgIHNuZF9kcml2ZXIua28KCUNvbnRhaW5zIG1vZHVsZXM6CgkJSWQgTmFtZQoJCTM5IHNu ZF9kcml2ZXIKIDMgICAgMiAweGMwNzVjMDAwIDRkNDggICAgIHNuZF9hZDE4MTYua28KCUNvbnRh aW5zIG1vZHVsZXM6CgkJSWQgTmFtZQoJCSAyIGFjcGkvc25kX2FkMTgxNgoJCSAzIGlzYS9zbmRf YWQxODE2CiA0ICAgMzAgMHhjMDc2MTAwMCAyMmFlOCAgICBzb3VuZC5rbwoJQ29udGFpbnMgbW9k dWxlczoKCQlJZCBOYW1lCgkJIDEgc291bmQKIDUgICAgMiAweGMwNzg0MDAwIDUxYjQgICAgIHNu ZF9hbHM0MDAwLmtvCglDb250YWlucyBtb2R1bGVzOgoJCUlkIE5hbWUKCQkgNCBwY2kvc25kX2Fs czQwMDAKIDYgICAgMiAweGMwNzhhMDAwIDU5NTQgICAgIHNuZF9hdGlpeHAua28KCUNvbnRhaW5z IG1vZHVsZXM6CgkJSWQgTmFtZQoJCSA1IHBjaS9zbmRfYXRpaXhwCiA3ICAgIDIgMHhjMDc5MDAw MCA0ZWYwICAgICBzbmRfY21pLmtvCglDb250YWlucyBtb2R1bGVzOgoJCUlkIE5hbWUKCQkgNiBw Y2kvc25kX2NtaQogOCAgICAyIDB4YzA3OTUwMDAgNTUxNCAgICAgc25kX2NzNDI4MS5rbwoJQ29u dGFpbnMgbW9kdWxlczoKCQlJZCBOYW1lCgkJIDcgcGNpL3NuZF9jczQyODEKIDkgICAgMyAweGMw NzliMDAwIDc0ZDAgICAgIHNuZF9jc2Eua28KCUNvbnRhaW5zIG1vZHVsZXM6CgkJSWQgTmFtZQoJ CSA4IHBjaS9zbmRfY3NhCgkJIDkgY3NhL3NuZF9jc2FwY20KMTAgICAgMiAweGMwN2EzMDAwIGJm YTAgICAgIHNuZF9kczEua28KCUNvbnRhaW5zIG1vZHVsZXM6CgkJSWQgTmFtZQoJCTEwIHBjaS9z bmRfZHMxCjExICAgIDIgMHhjMDdhZjAwMCA3Njc0ICAgICBzbmRfZW11MTBrMS5rbwoJQ29udGFp bnMgbW9kdWxlczoKCQlJZCBOYW1lCgkJMTEgcGNpL2VtdWpveQoJCTEyIGNhcmRidXMvc25kX2Vt dTEwazEKCQkxMyBwY2kvc25kX2VtdTEwazEKMTIgICAgMiAweGMwN2I3MDAwIDcxOWMgICAgIHNu ZF9lczEzN3gua28KCUNvbnRhaW5zIG1vZHVsZXM6CgkJSWQgTmFtZQoJCTE0IHBjaS9zbmRfZXMx Mzd4CjEzICAgIDMgMHhjMDdiZjAwMCA0ZmQ4ICAgICBzbmRfZXNzLmtvCglDb250YWlucyBtb2R1 bGVzOgoJCUlkIE5hbWUKCQkxNyBhY3BpL2Vzc2NvbnRyb2wKCQkxOCBpc2EvZXNzY29udHJvbAoJ CTE5IHNiYy9zbmRfZXNzCgkJMjAgaXNhL3NuZF9lczE4ODgKMTQgICAgNSAweGMwN2M0MDAwIDQ4 OWMgICAgIHNuZF9zYmMua28KCUNvbnRhaW5zIG1vZHVsZXM6CgkJSWQgTmFtZQoJCTE1IGFjcGkv c25kX3NiYwoJCTE2IGlzYS9zbmRfc2JjCjE1ICAgIDIgMHhjMDdjOTAwMCA0OTg0ICAgICBzbmRf Zm04MDEua28KCUNvbnRhaW5zIG1vZHVsZXM6CgkJSWQgTmFtZQoJCTIxIHBjaS9zbmRfZm04MDEK MTYgICAgMyAweGMwN2NlMDAwIGIzZDAgICAgIHNuZF9tc3Mua28KCUNvbnRhaW5zIG1vZHVsZXM6 CgkJSWQgTmFtZQoJCTIyIGd1c2Mvc25kX2d1c3BjbQoJCTIzIGFjcGkvc25kX3BucG1zcwoJCTI0 IGlzYS9zbmRfcG5wbXNzCgkJMjUgaXNhL3NuZF9tc3MKCQkyNiBhY3BpL3NuZF9ndXNjCgkJMjcg aXNhL3NuZF9ndXNjCjE3ICAgIDIgMHhjMDdkYTAwMCA1ZWMwICAgICBzbmRfaWNoLmtvCglDb250 YWlucyBtb2R1bGVzOgoJCUlkIE5hbWUKCQkyOCBwY2kvc25kX2ljaAoxOCAgICAyIDB4YzA3ZTAw MDAgYjQ2OCAgICAgc25kX21hZXN0cm8ua28KCUNvbnRhaW5zIG1vZHVsZXM6CgkJSWQgTmFtZQoJ CTI5IHBjaS9zbmRfbWFlc3RybwoxOSAgICAyIDB4YzA3ZWMwMDAgOTNmNCAgICAgc25kX21hZXN0 cm8zLmtvCglDb250YWlucyBtb2R1bGVzOgoJCUlkIE5hbWUKCQkzMCBwY2kvc25kX21hZXN0cm8z CjIwICAgIDIgMHhjMDdmNjAwMCAxMDk0OCAgICBzbmRfbmVvbWFnaWMua28KCUNvbnRhaW5zIG1v ZHVsZXM6CgkJSWQgTmFtZQoJCTMxIHBjaS9zbmRfbmVvbWFnaWMKMjEgICAgMiAweGMwODA3MDAw IDRlYzAgICAgIHNuZF9zYjE2LmtvCglDb250YWlucyBtb2R1bGVzOgoJCUlkIE5hbWUKCQkzMiBz YmMvc25kX3NiMTYKMjIgICAgMiAweGMwODBjMDAwIDQ4Y2MgICAgIHNuZF9zYjgua28KCUNvbnRh aW5zIG1vZHVsZXM6CgkJSWQgTmFtZQoJCTMzIHNiYy9zbmRfc2I4CjIzICAgIDIgMHhjMDgxMTAw MCA1ODM4ICAgICBzbmRfc29sby5rbwoJQ29udGFpbnMgbW9kdWxlczoKCQlJZCBOYW1lCgkJMzQg cGNpL3NuZF9zb2xvCjI0ICAgIDIgMHhjMDgxNzAwMCA1MWY4ICAgICBzbmRfdDRkd2F2ZS5rbwoJ Q29udGFpbnMgbW9kdWxlczoKCQlJZCBOYW1lCgkJMzUgcGNpL3NuZF90NGR3YXZlCjI1ICAgIDIg MHhjMDgxZDAwMCA2MGYwICAgICBzbmRfdmlhODIzMy5rbwoJQ29udGFpbnMgbW9kdWxlczoKCQlJ ZCBOYW1lCgkJMzYgcGNpL3NuZF92aWE4MjMzCjI2ICAgIDIgMHhjMDgyNDAwMCA0OWJjICAgICBz bmRfdmlhODJjNjg2LmtvCglDb250YWlucyBtb2R1bGVzOgoJCUlkIE5hbWUKCQkzNyBwY2kvc25k X3ZpYTgyYzY4NgoyNyAgICAyIDB4YzA4MjkwMDAgNDU4NCAgICAgc25kX3ZpYmVzLmtvCglDb250 YWlucyBtb2R1bGVzOgoJCUlkIE5hbWUKCQkzOCBwY2kvc25kX3ZpYmVzCjI4ICAgIDEgMHhjMDgy ZTAwMCA1OTdhYyAgICBhY3BpLmtvCglDb250YWlucyBtb2R1bGVzOgoJCUlkIE5hbWUKCQk0MCBu ZXh1cy9hY3BpCgkJNDEgYWNwaS9hY3BpX2J1dHRvbgoJCTQyIGFjcGkvYWNwaV9pc2FiCgkJNDMg cGNpYi9hY3BpX3BjaQoJCTQ0IGFjcGkvYWNwaV9wY2liCgkJNDUgcGNpL2FjcGlfcGNpYgoJCTQ2 IGFjcGkvYWNwaV9zeXNyZXNvdXJjZQoJCTQ3IGFjcGkvYWNwaV90aW1lcgoJCTQ4IGFjcGkvYWNw aV9wY2lfbGluawoJCTQ5IGFjcGkvYWNwaV90egoJCTUwIGFjcGkvYWNwaV9hY2FkCgkJNTEgYWNw aS9hY3BpX2NtYmF0CgkJNTIgYWNwaS9jcHUKCQk1MyBhY3BpL2FjcGlfZWMKCQk1NCBhY3BpL2Fj cGlfbGlkCgkJNTUgY3B1L2FjcGlfcGVyZgoJCTU2IGFjcGkvYWNwaV9zbWJhdAoJCTU3IGNwdS9h Y3BpX3Rocm90dGxlCjI5ICAgIDEgMHhjNGVkNjAwMCAzMDAwMCAgICBpd2lfYnNzLmtvCglDb250 YWlucyBtb2R1bGVzOgoJCUlkIE5hbWUKCQkyMzkgaXdpX2Jzc19mdwprbGRsb2FkOiAKY2FuJ3Qg bG9hZCBpd2lfYnNzCjogCkZpbGUgZXhpc3RzCmFmdGVyIGl3aSBsb2FkCklkIFJlZnMgQWRkcmVz cyAgICBTaXplICAgICBOYW1lCiAxICAgMzEgMHhjMDQwMDAwMCAzNTc2ZjAgICBrZXJuZWwKCUNv bnRhaW5zIG1vZHVsZXM6CgkJSWQgTmFtZQoJCTU4IGNhbQoJCTU5IHByb2JlCgkJNjAgeHB0CgkJ NjEgY2QKCQk2MiBwYXNzCgkJNjMgYXRhCgkJNjQgcGNjYXJkL2F0YQoJCTY1IGF0YS9hZAoJCTY2 IGlzYS9hdGEKCQk2NyBhdGFwY2kvYXRhCgkJNjggcGNpL2F0YXBjaQoJCTY5IGF0YS9hdGFwaWNh bQoJCTcwIGF0YS9hY2QKCQk3MSBiZmUvbWlpYnVzCgkJNzIgcGNpL2JmZQoJCTczIGNiYi9jYXJk YnVzCgkJNzQgZXhjYQoJCTc1IGZ3b2hjaS9maXJld2lyZQoJCTc2IGNhcmRidXMvZndvaGNpCgkJ NzcgcGNpL2Z3b2hjaQoJCTc4IGZpcmV3aXJlL2Z3ZQoJCTc5IGZpcmV3aXJlL3NicAoJCTgwIHBj aS9pd2kKCQk4MSBnX21kCgkJODIgbWVtCgkJODMgbWlpYnVzL2FjcGh5CgkJODQgbWlpYnVzL2Ft cGh5CgkJODUgbWlpYnVzL2JtdHBoeQoJCTg2IG1paWJ1cy9icmdwaHkKCQk4NyBtaWlidXMvY2lw aHkKCQk4OCBtaWlidXMvZTEwMDBwaHkKCQk4OSBtaWlidXMveGxwaHkKCQk5MCBtaWlidXMvaW5w aHkKCQk5MSBtaWlidXMvbHh0cGh5CgkJOTIgbWlpYnVzL21scGh5CgkJOTMgbWlpYnVzL25zZ3Bo eQoJCTk0IG1paWJ1cy9uc3BoeQoJCTk1IG1paWJ1cy9wbmFwaHkKCQk5NiBtaWlidXMvcG5waHkK CQk5NyBtaWlidXMvcXNwaHkKCQk5OCBtaWlidXMvcmdlcGh5CgkJOTkgbWlpYnVzL3JscGh5CgkJ MTAwIG1paWJ1cy9ydWVwaHkKCQkxMDEgbWlpYnVzL3Rka3BoeQoJCTEwMiBtaWlidXMvdGxwaHkK CQkxMDMgbWlpYnVzL3VrcGh5CgkJMTA0IG1paWJ1cy94bXBoeQoJCTEwNSBudWxsCgkJMTA2IGNi Yi9wY2NhcmQKCQkxMDcgcGNpYy9wY2NhcmQKCQkxMDggaXNhL2NiYgoJCTEwOSBwY2kvY2JiCgkJ MTEwIHBjaS9maXh1cF9wY2kKCQkxMTEgcGNpL2lnbm9yZV9wY2kKCQkxMTIgcGNpL2lzYWIKCQkx MTMgcGNpYi9wY2kKCQkxMTQgcGNpL3BjaWIKCQkxMTUgcHBidXMvbHB0CgkJMTE2IHBwYy9wcGJ1 cwoJCTExNyBwcGJ1cy9wcGkKCQkxMTggcmFuZG9tCgkJMTE5IGF1ZS9taWlidXMKCQkxMjAgdWh1 Yi9hdWUKCQkxMjEgYXhlL21paWJ1cwoJCTEyMiB1aHViL2F4ZQoJCTEyMyB1aHViL2NkY2UKCQkx MjQgdWh1Yi9jdWUKCQkxMjUgdWh1Yi9rdWUKCQkxMjYgcnVlL21paWJ1cwoJCTEyNyB1aHViL3J1 ZQoJCTEyOCBjYXJkYnVzL29oY2kKCQkxMjkgcGNpL29oY2kKCQkxMzAgdWh1Yi91Z2VuCgkJMTMx IGNhcmRidXMvdWhjaQoJCTEzMiBwY2kvdWhjaQoJCTEzMyB1aHViL3VoaWQKCQkxMzQgdWh1Yi91 aHViCgkJMTM1IHVzYi91aHViCgkJMTM2IHVodWIvdWtiZAoJCTEzNyB1aHViL3VscHQKCQkxMzgg dWh1Yi91bWFzcwoJCTEzOSB1aHViL3VtcwoJCTE0MCB1aHViL3VyaW8KCQkxNDEgZWhjaS91c2IK CQkxNDIgdWhjaS91c2IKCQkxNDMgb2hjaS91c2IKCQkxNDQgdWh1Yi91c2Nhbm5lcgoJCTE0NSB3 YXRjaGRvZwoJCTE0NiBkZXZmcwoJCTE0NyBwcm9jZnMKCQkxNDggcHNldWRvZnMKCQkxNDkgZ19k ZXYKCQkxNTAgZ19kaXNrCgkJMTUxIGdfZ3B0CgkJMTUyIGdfdmZzCgkJMTUzIGVpc2FiL2lzYQoJ CTE1NCBpc2FiL2lzYQoJCTE1NSBpc2EvaXNhaGludAoJCTE1NiBpc2Evb3JtCgkJMTU3IGlzYS9w bnAKCQkxNTggY2Q5NjYwCgkJMTU5IGVsZjMyCgkJMTYwIHNoZWxsCgkJMTYxIGNwdS9jcHVmcmVx CgkJMTYyIHJvb3RidXMKCQkxNjMgZmlybXdhcmUKCQkxNjQgc3lzdm1zZwoJCTE2NSBtc2dyY3YK CQkxNjYgbXNnc25kCgkJMTY3IG1zZ2dldAoJCTE2OCBtc2djdGwKCQkxNjkgbXNnc3lzCgkJMTcw IHN5c3ZzZW0KCQkxNzEgc2Vtb3AKCQkxNzIgc2VtZ2V0CgkJMTczIF9fc2VtY3RsCgkJMTc0IHNl bXN5cwoJCTE3NSBzeXN2c2htCgkJMTc2IHNobWdldAoJCTE3NyBzaG1kdAoJCTE3OCBzaG1jdGwK CQkxNzkgc2htYXQKCQkxODAgc2htc3lzCgkJMTgxIGV0aGVyCgkJMTgyIGxvb3AKCQkxODMgaWZf cHBwCgkJMTg0IGlmX3NsCgkJMTg1IGlmX3R1bgoJCTE4NiB3bGFuX3dlcAoJCTE4NyB3bGFuCgkJ MTg4IHBjaS9kZQoJCTE4OSB1ZnMKCQkxOTAgZ19jbGFzcwoJCTE5MSBhdGtiZGMvYXRrYmQKCQkx OTIgYWNwaS9hdGtiZGMKCQkxOTMgaXNhL2F0a2JkYwoJCTE5NCBhY3BpL3BzbWNwbnAKCQkxOTUg aXNhL3BzbWNwbnAKCQkxOTYgYXRrYmRjL3BzbQoJCTE5NyBpbwoJCTE5OCBhY3BpL3BwYwoJCTE5 OSBpc2EvcHBjCgkJMjAwIHNjdGVybS1zYwoJCTIwMSBzY3JuZHItdmdhCgkJMjAyIGdfYnNkCgkJ MjAzIGdfbWJyZXh0CgkJMjA0IGdfbWJyCgkJMjA1IGlzYS9wbnBiaW9zCgkJMjA2IGxlZ2FjeS9j cHUKCQkyMDcgbmV4dXMvbGVnYWN5CgkJMjA4IHBjaS9tcHRhYmxlX3BjaWIKCQkyMDkgbGVnYWN5 L21wdGFibGVfcGNpYgoJCTIxMCBpc2Evc3lzcmVzb3VyY2UKCQkyMTEgcm9vdC9uZXh1cwoJCTIx MiBhY3BpL2F0cGljCgkJMjEzIGlzYS9hdHBpYwoJCTIxNCBhY3BpL2F0dGltZXIKCQkyMTUgaXNh L2F0dGltZXIKCQkyMTYgbGVnYWN5L2lzYQoJCTIxNyBhY3BpL2F0ZG1hCgkJMjE4IGlzYS9hdGRt YQoJCTIxOSBhY3BpL25weGlzYQoJCTIyMCBpc2EvbnB4aXNhCgkJMjIxIG5leHVzL25weAoJCTIy MiBpc2EvcG10aW1lcgoJCTIyMyBwY2kvcGNpYmlvc19wY2liCgkJMjI0IGlzYS9wY2lidXNfcG5w CgkJMjI1IHBjaS9ob3N0YgoJCTIyNiBsZWdhY3kvcGNpYgoJCTIyNyBsZWdhY3kvcGlyCgkJMjI4 IGlzYS9zYwoJCTIyOSBpc2EvdmdhCgkJMjMwIHBjaS9hZ3BfYWxpCgkJMjMxIHBjaS9hZ3BfYW1k CgkJMjMyIHBjaS9hZ3BfYW1kNjQKCQkyMzMgcGNpL2FncF9hdGkKCQkyMzQgcGNpL2FncF9pODEw CgkJMjM1IHBjaS9hZ3BfaW50ZWwKCQkyMzYgcGNpL2FncF9udmlkaWEKCQkyMzcgcGNpL2FncF9z aXMKCQkyMzggcGNpL2FncF92aWEKIDIgICAgMSAweGMwNzU4MDAwIDMzOGMgICAgIHNuZF9kcml2 ZXIua28KCUNvbnRhaW5zIG1vZHVsZXM6CgkJSWQgTmFtZQoJCTM5IHNuZF9kcml2ZXIKIDMgICAg MiAweGMwNzVjMDAwIDRkNDggICAgIHNuZF9hZDE4MTYua28KCUNvbnRhaW5zIG1vZHVsZXM6CgkJ SWQgTmFtZQoJCSAyIGFjcGkvc25kX2FkMTgxNgoJCSAzIGlzYS9zbmRfYWQxODE2CiA0ICAgMzAg MHhjMDc2MTAwMCAyMmFlOCAgICBzb3VuZC5rbwoJQ29udGFpbnMgbW9kdWxlczoKCQlJZCBOYW1l CgkJIDEgc291bmQKIDUgICAgMiAweGMwNzg0MDAwIDUxYjQgICAgIHNuZF9hbHM0MDAwLmtvCglD b250YWlucyBtb2R1bGVzOgoJCUlkIE5hbWUKCQkgNCBwY2kvc25kX2FsczQwMDAKIDYgICAgMiAw eGMwNzhhMDAwIDU5NTQgICAgIHNuZF9hdGlpeHAua28KCUNvbnRhaW5zIG1vZHVsZXM6CgkJSWQg TmFtZQoJCSA1IHBjaS9zbmRfYXRpaXhwCiA3ICAgIDIgMHhjMDc5MDAwMCA0ZWYwICAgICBzbmRf Y21pLmtvCglDb250YWlucyBtb2R1bGVzOgoJCUlkIE5hbWUKCQkgNiBwY2kvc25kX2NtaQogOCAg ICAyIDB4YzA3OTUwMDAgNTUxNCAgICAgc25kX2NzNDI4MS5rbwoJQ29udGFpbnMgbW9kdWxlczoK CQlJZCBOYW1lCgkJIDcgcGNpL3NuZF9jczQyODEKIDkgICAgMyAweGMwNzliMDAwIDc0ZDAgICAg IHNuZF9jc2Eua28KCUNvbnRhaW5zIG1vZHVsZXM6CgkJSWQgTmFtZQoJCSA4IHBjaS9zbmRfY3Nh CgkJIDkgY3NhL3NuZF9jc2FwY20KMTAgICAgMiAweGMwN2EzMDAwIGJmYTAgICAgIHNuZF9kczEu a28KCUNvbnRhaW5zIG1vZHVsZXM6CgkJSWQgTmFtZQoJCTEwIHBjaS9zbmRfZHMxCjExICAgIDIg MHhjMDdhZjAwMCA3Njc0ICAgICBzbmRfZW11MTBrMS5rbwoJQ29udGFpbnMgbW9kdWxlczoKCQlJ ZCBOYW1lCgkJMTEgcGNpL2VtdWpveQoJCTEyIGNhcmRidXMvc25kX2VtdTEwazEKCQkxMyBwY2kv c25kX2VtdTEwazEKMTIgICAgMiAweGMwN2I3MDAwIDcxOWMgICAgIHNuZF9lczEzN3gua28KCUNv bnRhaW5zIG1vZHVsZXM6CgkJSWQgTmFtZQoJCTE0IHBjaS9zbmRfZXMxMzd4CjEzICAgIDMgMHhj MDdiZjAwMCA0ZmQ4ICAgICBzbmRfZXNzLmtvCglDb250YWlucyBtb2R1bGVzOgoJCUlkIE5hbWUK CQkxNyBhY3BpL2Vzc2NvbnRyb2wKCQkxOCBpc2EvZXNzY29udHJvbAoJCTE5IHNiYy9zbmRfZXNz CgkJMjAgaXNhL3NuZF9lczE4ODgKMTQgICAgNSAweGMwN2M0MDAwIDQ4OWMgICAgIHNuZF9zYmMu a28KCUNvbnRhaW5zIG1vZHVsZXM6CgkJSWQgTmFtZQoJCTE1IGFjcGkvc25kX3NiYwoJCTE2IGlz YS9zbmRfc2JjCjE1ICAgIDIgMHhjMDdjOTAwMCA0OTg0ICAgICBzbmRfZm04MDEua28KCUNvbnRh aW5zIG1vZHVsZXM6CgkJSWQgTmFtZQoJCTIxIHBjaS9zbmRfZm04MDEKMTYgICAgMyAweGMwN2Nl MDAwIGIzZDAgICAgIHNuZF9tc3Mua28KCUNvbnRhaW5zIG1vZHVsZXM6CgkJSWQgTmFtZQoJCTIy IGd1c2Mvc25kX2d1c3BjbQoJCTIzIGFjcGkvc25kX3BucG1zcwoJCTI0IGlzYS9zbmRfcG5wbXNz CgkJMjUgaXNhL3NuZF9tc3MKCQkyNiBhY3BpL3NuZF9ndXNjCgkJMjcgaXNhL3NuZF9ndXNjCjE3 ICAgIDIgMHhjMDdkYTAwMCA1ZWMwICAgICBzbmRfaWNoLmtvCglDb250YWlucyBtb2R1bGVzOgoJ CUlkIE5hbWUKCQkyOCBwY2kvc25kX2ljaAoxOCAgICAyIDB4YzA3ZTAwMDAgYjQ2OCAgICAgc25k X21hZXN0cm8ua28KCUNvbnRhaW5zIG1vZHVsZXM6CgkJSWQgTmFtZQoJCTI5IHBjaS9zbmRfbWFl c3RybwoxOSAgICAyIDB4YzA3ZWMwMDAgOTNmNCAgICAgc25kX21hZXN0cm8zLmtvCglDb250YWlu cyBtb2R1bGVzOgoJCUlkIE5hbWUKCQkzMCBwY2kvc25kX21hZXN0cm8zCjIwICAgIDIgMHhjMDdm NjAwMCAxMDk0OCAgICBzbmRfbmVvbWFnaWMua28KCUNvbnRhaW5zIG1vZHVsZXM6CgkJSWQgTmFt ZQoJCTMxIHBjaS9zbmRfbmVvbWFnaWMKMjEgICAgMiAweGMwODA3MDAwIDRlYzAgICAgIHNuZF9z YjE2LmtvCglDb250YWlucyBtb2R1bGVzOgoJCUlkIE5hbWUKCQkzMiBzYmMvc25kX3NiMTYKMjIg ICAgMiAweGMwODBjMDAwIDQ4Y2MgICAgIHNuZF9zYjgua28KCUNvbnRhaW5zIG1vZHVsZXM6CgkJ SWQgTmFtZQoJCTMzIHNiYy9zbmRfc2I4CjIzICAgIDIgMHhjMDgxMTAwMCA1ODM4ICAgICBzbmRf c29sby5rbwoJQ29udGFpbnMgbW9kdWxlczoKCQlJZCBOYW1lCgkJMzQgcGNpL3NuZF9zb2xvCjI0 ICAgIDIgMHhjMDgxNzAwMCA1MWY4ICAgICBzbmRfdDRkd2F2ZS5rbwoJQ29udGFpbnMgbW9kdWxl czoKCQlJZCBOYW1lCgkJMzUgcGNpL3NuZF90NGR3YXZlCjI1ICAgIDIgMHhjMDgxZDAwMCA2MGYw ICAgICBzbmRfdmlhODIzMy5rbwoJQ29udGFpbnMgbW9kdWxlczoKCQlJZCBOYW1lCgkJMzYgcGNp L3NuZF92aWE4MjMzCjI2ICAgIDIgMHhjMDgyNDAwMCA0OWJjICAgICBzbmRfdmlhODJjNjg2Lmtv CglDb250YWlucyBtb2R1bGVzOgoJCUlkIE5hbWUKCQkzNyBwY2kvc25kX3ZpYTgyYzY4NgoyNyAg ICAyIDB4YzA4MjkwMDAgNDU4NCAgICAgc25kX3ZpYmVzLmtvCglDb250YWlucyBtb2R1bGVzOgoJ CUlkIE5hbWUKCQkzOCBwY2kvc25kX3ZpYmVzCjI4ICAgIDEgMHhjMDgyZTAwMCA1OTdhYyAgICBh Y3BpLmtvCglDb250YWlucyBtb2R1bGVzOgoJCUlkIE5hbWUKCQk0MCBuZXh1cy9hY3BpCgkJNDEg YWNwaS9hY3BpX2J1dHRvbgoJCTQyIGFjcGkvYWNwaV9pc2FiCgkJNDMgcGNpYi9hY3BpX3BjaQoJ CTQ0IGFjcGkvYWNwaV9wY2liCgkJNDUgcGNpL2FjcGlfcGNpYgoJCTQ2IGFjcGkvYWNwaV9zeXNy ZXNvdXJjZQoJCTQ3IGFjcGkvYWNwaV90aW1lcgoJCTQ4IGFjcGkvYWNwaV9wY2lfbGluawoJCTQ5 IGFjcGkvYWNwaV90egoJCTUwIGFjcGkvYWNwaV9hY2FkCgkJNTEgYWNwaS9hY3BpX2NtYmF0CgkJ NTIgYWNwaS9jcHUKCQk1MyBhY3BpL2FjcGlfZWMKCQk1NCBhY3BpL2FjcGlfbGlkCgkJNTUgY3B1 L2FjcGlfcGVyZgoJCTU2IGFjcGkvYWNwaV9zbWJhdAoJCTU3IGNwdS9hY3BpX3Rocm90dGxlCjI5 ICAgIDEgMHhjNGVkNjAwMCAzMDAwMCAgICBpd2lfYnNzLmtvCglDb250YWlucyBtb2R1bGVzOgoJ CUlkIE5hbWUKCQkyMzkgaXdpX2Jzc19mdwpFTEYgbGRjb25maWcgcGF0aDogL2xpYiAvdXNyL2xp YiAvdXNyL2xpYi9jb21wYXQgL3Vzci9YMTFSNi9saWIgL3Vzci9sb2NhbC9saWIgL3Vzci9sb2Nh bC9saWIvY29tcGF0L3BrZyAvdXNyL2xvY2FsL2xpYi9jb21wYXQgL3Vzci9sb2NhbC9saWIvY29t cGF0L3BrZyAvdXNyL2xvY2FsL2xpYi9ncmFwaHZpeiAvdXNyL2xvY2FsL2xpYi9teXNxbCAvdXNy L2xvY2FsL2xpYi9wdGgKYS5vdXQgbGRjb25maWcgcGF0aDogL3Vzci9saWIvYW91dCAvdXNyL2xp Yi9jb21wYXQvYW91dCAvdXNyL1gxMVI2L2xpYi9hb3V0CkNyZWF0aW5nIGFuZC9vciB0cmltbWlu ZyBsb2cgZmlsZXM6Ci4KU3RhcnRpbmcgc3lzbG9nZC4KSW5pdGlhbCBpMzg2IGluaXRpYWxpemF0 aW9uOgouCkFkZGl0aW9uYWwgQUJJIHN1cHBvcnQ6CiBsaW51eAouClN0YXJ0aW5nIHVzYmQuClN0 YXJ0aW5nIGxvY2FsIGRhZW1vbnM6Ci4KVXBkYXRpbmcgbW90ZAouClN0YXJ0aW5nIHBvd2VyZC4K Q29uZmlndXJpbmcgc3lzY29uczoKIGJsYW5rdGltZQogc2NyZWVuc2F2ZXIKLgpTdGFydGluZyBz c2hkLgpTdGFydGluZyBjcm9uLgpMb2NhbCBwYWNrYWdlIGluaXRpYWxpemF0aW9uOgpVcGRhdGlu ZyBLRE0gY29uZmlndXJhdGlvbgpJbmZvcm1hdGlvbjogcmVhZGluZyBvbGQga2RtcmMgL3Vzci9s b2NhbC9zaGFyZS9jb25maWcva2RtL2tkbXJjIChmcm9tIGtkZSA+PSAyLjIueCkKSW5mb3JtYXRp b246IG9sZCBrZG1yYyBpcyBmcm9tIGtkZSA+PSAzLjEgKGNvbmZpZyB2ZXJzaW9uIDIuMykKaXdp Y29udHJvbDogCkNhbid0IGxvYWQgZmlybXdhcmUgdG8gZHJpdmVyCjogCkludmFsaWQgYXJndW1l bnQKLgpBZGRpdGlvbmFsIFRDUCBvcHRpb25zOgouCml3aSBmaXJtd2FyZSBsb2FkCklkIFJlZnMg QWRkcmVzcyAgICBTaXplICAgICBOYW1lCiAxICAgMzcgMHhjMDQwMDAwMCAzNTc2ZjAgICBrZXJu ZWwKCUNvbnRhaW5zIG1vZHVsZXM6CgkJSWQgTmFtZQoJCTU4IGNhbQoJCTU5IHByb2JlCgkJNjAg eHB0CgkJNjEgY2QKCQk2MiBwYXNzCgkJNjMgYXRhCgkJNjQgcGNjYXJkL2F0YQoJCTY1IGF0YS9h ZAoJCTY2IGlzYS9hdGEKCQk2NyBhdGFwY2kvYXRhCgkJNjggcGNpL2F0YXBjaQoJCTY5IGF0YS9h dGFwaWNhbQoJCTcwIGF0YS9hY2QKCQk3MSBiZmUvbWlpYnVzCgkJNzIgcGNpL2JmZQoJCTczIGNi Yi9jYXJkYnVzCgkJNzQgZXhjYQoJCTc1IGZ3b2hjaS9maXJld2lyZQoJCTc2IGNhcmRidXMvZndv aGNpCgkJNzcgcGNpL2Z3b2hjaQoJCTc4IGZpcmV3aXJlL2Z3ZQoJCTc5IGZpcmV3aXJlL3NicAoJ CTgwIHBjaS9pd2kKCQk4MSBnX21kCgkJODIgbWVtCgkJODMgbWlpYnVzL2FjcGh5CgkJODQgbWlp YnVzL2FtcGh5CgkJODUgbWlpYnVzL2JtdHBoeQoJCTg2IG1paWJ1cy9icmdwaHkKCQk4NyBtaWli dXMvY2lwaHkKCQk4OCBtaWlidXMvZTEwMDBwaHkKCQk4OSBtaWlidXMveGxwaHkKCQk5MCBtaWli dXMvaW5waHkKCQk5MSBtaWlidXMvbHh0cGh5CgkJOTIgbWlpYnVzL21scGh5CgkJOTMgbWlpYnVz L25zZ3BoeQoJCTk0IG1paWJ1cy9uc3BoeQoJCTk1IG1paWJ1cy9wbmFwaHkKCQk5NiBtaWlidXMv cG5waHkKCQk5NyBtaWlidXMvcXNwaHkKCQk5OCBtaWlidXMvcmdlcGh5CgkJOTkgbWlpYnVzL3Js cGh5CgkJMTAwIG1paWJ1cy9ydWVwaHkKCQkxMDEgbWlpYnVzL3Rka3BoeQoJCTEwMiBtaWlidXMv dGxwaHkKCQkxMDMgbWlpYnVzL3VrcGh5CgkJMTA0IG1paWJ1cy94bXBoeQoJCTEwNSBudWxsCgkJ MTA2IGNiYi9wY2NhcmQKCQkxMDcgcGNpYy9wY2NhcmQKCQkxMDggaXNhL2NiYgoJCTEwOSBwY2kv Y2JiCgkJMTEwIHBjaS9maXh1cF9wY2kKCQkxMTEgcGNpL2lnbm9yZV9wY2kKCQkxMTIgcGNpL2lz YWIKCQkxMTMgcGNpYi9wY2kKCQkxMTQgcGNpL3BjaWIKCQkxMTUgcHBidXMvbHB0CgkJMTE2IHBw Yy9wcGJ1cwoJCTExNyBwcGJ1cy9wcGkKCQkxMTggcmFuZG9tCgkJMTE5IGF1ZS9taWlidXMKCQkx MjAgdWh1Yi9hdWUKCQkxMjEgYXhlL21paWJ1cwoJCTEyMiB1aHViL2F4ZQoJCTEyMyB1aHViL2Nk Y2UKCQkxMjQgdWh1Yi9jdWUKCQkxMjUgdWh1Yi9rdWUKCQkxMjYgcnVlL21paWJ1cwoJCTEyNyB1 aHViL3J1ZQoJCTEyOCBjYXJkYnVzL29oY2kKCQkxMjkgcGNpL29oY2kKCQkxMzAgdWh1Yi91Z2Vu CgkJMTMxIGNhcmRidXMvdWhjaQoJCTEzMiBwY2kvdWhjaQoJCTEzMyB1aHViL3VoaWQKCQkxMzQg dWh1Yi91aHViCgkJMTM1IHVzYi91aHViCgkJMTM2IHVodWIvdWtiZAoJCTEzNyB1aHViL3VscHQK CQkxMzggdWh1Yi91bWFzcwoJCTEzOSB1aHViL3VtcwoJCTE0MCB1aHViL3VyaW8KCQkxNDEgZWhj aS91c2IKCQkxNDIgdWhjaS91c2IKCQkxNDMgb2hjaS91c2IKCQkxNDQgdWh1Yi91c2Nhbm5lcgoJ CTE0NSB3YXRjaGRvZwoJCTE0NiBkZXZmcwoJCTE0NyBwcm9jZnMKCQkxNDggcHNldWRvZnMKCQkx NDkgZ19kZXYKCQkxNTAgZ19kaXNrCgkJMTUxIGdfZ3B0CgkJMTUyIGdfdmZzCgkJMTUzIGVpc2Fi L2lzYQoJCTE1NCBpc2FiL2lzYQoJCTE1NSBpc2EvaXNhaGludAoJCTE1NiBpc2Evb3JtCgkJMTU3 IGlzYS9wbnAKCQkxNTggY2Q5NjYwCgkJMTU5IGVsZjMyCgkJMTYwIHNoZWxsCgkJMTYxIGNwdS9j cHVmcmVxCgkJMTYyIHJvb3RidXMKCQkxNjMgZmlybXdhcmUKCQkxNjQgc3lzdm1zZwoJCTE2NSBt c2dyY3YKCQkxNjYgbXNnc25kCgkJMTY3IG1zZ2dldAoJCTE2OCBtc2djdGwKCQkxNjkgbXNnc3lz CgkJMTcwIHN5c3ZzZW0KCQkxNzEgc2Vtb3AKCQkxNzIgc2VtZ2V0CgkJMTczIF9fc2VtY3RsCgkJ MTc0IHNlbXN5cwoJCTE3NSBzeXN2c2htCgkJMTc2IHNobWdldAoJCTE3NyBzaG1kdAoJCTE3OCBz aG1jdGwKCQkxNzkgc2htYXQKCQkxODAgc2htc3lzCgkJMTgxIGV0aGVyCgkJMTgyIGxvb3AKCQkx ODMgaWZfcHBwCgkJMTg0IGlmX3NsCgkJMTg1IGlmX3R1bgoJCTE4NiB3bGFuX3dlcAoJCTE4NyB3 bGFuCgkJMTg4IHBjaS9kZQoJCTE4OSB1ZnMKCQkxOTAgZ19jbGFzcwoJCTE5MSBhdGtiZGMvYXRr YmQKCQkxOTIgYWNwaS9hdGtiZGMKCQkxOTMgaXNhL2F0a2JkYwoJCTE5NCBhY3BpL3BzbWNwbnAK CQkxOTUgaXNhL3BzbWNwbnAKCQkxOTYgYXRrYmRjL3BzbQoJCTE5NyBpbwoJCTE5OCBhY3BpL3Bw YwoJCTE5OSBpc2EvcHBjCgkJMjAwIHNjdGVybS1zYwoJCTIwMSBzY3JuZHItdmdhCgkJMjAyIGdf YnNkCgkJMjAzIGdfbWJyZXh0CgkJMjA0IGdfbWJyCgkJMjA1IGlzYS9wbnBiaW9zCgkJMjA2IGxl Z2FjeS9jcHUKCQkyMDcgbmV4dXMvbGVnYWN5CgkJMjA4IHBjaS9tcHRhYmxlX3BjaWIKCQkyMDkg bGVnYWN5L21wdGFibGVfcGNpYgoJCTIxMCBpc2Evc3lzcmVzb3VyY2UKCQkyMTEgcm9vdC9uZXh1 cwoJCTIxMiBhY3BpL2F0cGljCgkJMjEzIGlzYS9hdHBpYwoJCTIxNCBhY3BpL2F0dGltZXIKCQky MTUgaXNhL2F0dGltZXIKCQkyMTYgbGVnYWN5L2lzYQoJCTIxNyBhY3BpL2F0ZG1hCgkJMjE4IGlz YS9hdGRtYQoJCTIxOSBhY3BpL25weGlzYQoJCTIyMCBpc2EvbnB4aXNhCgkJMjIxIG5leHVzL25w eAoJCTIyMiBpc2EvcG10aW1lcgoJCTIyMyBwY2kvcGNpYmlvc19wY2liCgkJMjI0IGlzYS9wY2li dXNfcG5wCgkJMjI1IHBjaS9ob3N0YgoJCTIyNiBsZWdhY3kvcGNpYgoJCTIyNyBsZWdhY3kvcGly CgkJMjI4IGlzYS9zYwoJCTIyOSBpc2EvdmdhCgkJMjMwIHBjaS9hZ3BfYWxpCgkJMjMxIHBjaS9h Z3BfYW1kCgkJMjMyIHBjaS9hZ3BfYW1kNjQKCQkyMzMgcGNpL2FncF9hdGkKCQkyMzQgcGNpL2Fn cF9pODEwCgkJMjM1IHBjaS9hZ3BfaW50ZWwKCQkyMzYgcGNpL2FncF9udmlkaWEKCQkyMzcgcGNp L2FncF9zaXMKCQkyMzggcGNpL2FncF92aWEKIDIgICAgMSAweGMwNzU4MDAwIDMzOGMgICAgIHNu ZF9kcml2ZXIua28KCUNvbnRhaW5zIG1vZHVsZXM6CgkJSWQgTmFtZQoJCTM5IHNuZF9kcml2ZXIK IDMgICAgMiAweGMwNzVjMDAwIDRkNDggICAgIHNuZF9hZDE4MTYua28KCUNvbnRhaW5zIG1vZHVs ZXM6CgkJSWQgTmFtZQoJCSAyIGFjcGkvc25kX2FkMTgxNgoJCSAzIGlzYS9zbmRfYWQxODE2CiA0 ICAgMzAgMHhjMDc2MTAwMCAyMmFlOCAgICBzb3VuZC5rbwoJQ29udGFpbnMgbW9kdWxlczoKCQlJ ZCBOYW1lCgkJIDEgc291bmQKIDUgICAgMiAweGMwNzg0MDAwIDUxYjQgICAgIHNuZF9hbHM0MDAw LmtvCglDb250YWlucyBtb2R1bGVzOgoJCUlkIE5hbWUKCQkgNCBwY2kvc25kX2FsczQwMDAKIDYg ICAgMiAweGMwNzhhMDAwIDU5NTQgICAgIHNuZF9hdGlpeHAua28KCUNvbnRhaW5zIG1vZHVsZXM6 CgkJSWQgTmFtZQoJCSA1IHBjaS9zbmRfYXRpaXhwCiA3ICAgIDIgMHhjMDc5MDAwMCA0ZWYwICAg ICBzbmRfY21pLmtvCglDb250YWlucyBtb2R1bGVzOgoJCUlkIE5hbWUKCQkgNiBwY2kvc25kX2Nt aQogOCAgICAyIDB4YzA3OTUwMDAgNTUxNCAgICAgc25kX2NzNDI4MS5rbwoJQ29udGFpbnMgbW9k dWxlczoKCQlJZCBOYW1lCgkJIDcgcGNpL3NuZF9jczQyODEKIDkgICAgMyAweGMwNzliMDAwIDc0 ZDAgICAgIHNuZF9jc2Eua28KCUNvbnRhaW5zIG1vZHVsZXM6CgkJSWQgTmFtZQoJCSA4IHBjaS9z bmRfY3NhCgkJIDkgY3NhL3NuZF9jc2FwY20KMTAgICAgMiAweGMwN2EzMDAwIGJmYTAgICAgIHNu ZF9kczEua28KCUNvbnRhaW5zIG1vZHVsZXM6CgkJSWQgTmFtZQoJCTEwIHBjaS9zbmRfZHMxCjEx ICAgIDIgMHhjMDdhZjAwMCA3Njc0ICAgICBzbmRfZW11MTBrMS5rbwoJQ29udGFpbnMgbW9kdWxl czoKCQlJZCBOYW1lCgkJMTEgcGNpL2VtdWpveQoJCTEyIGNhcmRidXMvc25kX2VtdTEwazEKCQkx MyBwY2kvc25kX2VtdTEwazEKMTIgICAgMiAweGMwN2I3MDAwIDcxOWMgICAgIHNuZF9lczEzN3gu a28KCUNvbnRhaW5zIG1vZHVsZXM6CgkJSWQgTmFtZQoJCTE0IHBjaS9zbmRfZXMxMzd4CjEzICAg IDMgMHhjMDdiZjAwMCA0ZmQ4ICAgICBzbmRfZXNzLmtvCglDb250YWlucyBtb2R1bGVzOgoJCUlk IE5hbWUKCQkxNyBhY3BpL2Vzc2NvbnRyb2wKCQkxOCBpc2EvZXNzY29udHJvbAoJCTE5IHNiYy9z bmRfZXNzCgkJMjAgaXNhL3NuZF9lczE4ODgKMTQgICAgNSAweGMwN2M0MDAwIDQ4OWMgICAgIHNu ZF9zYmMua28KCUNvbnRhaW5zIG1vZHVsZXM6CgkJSWQgTmFtZQoJCTE1IGFjcGkvc25kX3NiYwoJ CTE2IGlzYS9zbmRfc2JjCjE1ICAgIDIgMHhjMDdjOTAwMCA0OTg0ICAgICBzbmRfZm04MDEua28K CUNvbnRhaW5zIG1vZHVsZXM6CgkJSWQgTmFtZQoJCTIxIHBjaS9zbmRfZm04MDEKMTYgICAgMyAw eGMwN2NlMDAwIGIzZDAgICAgIHNuZF9tc3Mua28KCUNvbnRhaW5zIG1vZHVsZXM6CgkJSWQgTmFt ZQoJCTIyIGd1c2Mvc25kX2d1c3BjbQoJCTIzIGFjcGkvc25kX3BucG1zcwoJCTI0IGlzYS9zbmRf cG5wbXNzCgkJMjUgaXNhL3NuZF9tc3MKCQkyNiBhY3BpL3NuZF9ndXNjCgkJMjcgaXNhL3NuZF9n dXNjCjE3ICAgIDIgMHhjMDdkYTAwMCA1ZWMwICAgICBzbmRfaWNoLmtvCglDb250YWlucyBtb2R1 bGVzOgoJCUlkIE5hbWUKCQkyOCBwY2kvc25kX2ljaAoxOCAgICAyIDB4YzA3ZTAwMDAgYjQ2OCAg ICAgc25kX21hZXN0cm8ua28KCUNvbnRhaW5zIG1vZHVsZXM6CgkJSWQgTmFtZQoJCTI5IHBjaS9z bmRfbWFlc3RybwoxOSAgICAyIDB4YzA3ZWMwMDAgOTNmNCAgICAgc25kX21hZXN0cm8zLmtvCglD b250YWlucyBtb2R1bGVzOgoJCUlkIE5hbWUKCQkzMCBwY2kvc25kX21hZXN0cm8zCjIwICAgIDIg MHhjMDdmNjAwMCAxMDk0OCAgICBzbmRfbmVvbWFnaWMua28KCUNvbnRhaW5zIG1vZHVsZXM6CgkJ SWQgTmFtZQoJCTMxIHBjaS9zbmRfbmVvbWFnaWMKMjEgICAgMiAweGMwODA3MDAwIDRlYzAgICAg IHNuZF9zYjE2LmtvCglDb250YWlucyBtb2R1bGVzOgoJCUlkIE5hbWUKCQkzMiBzYmMvc25kX3Ni MTYKMjIgICAgMiAweGMwODBjMDAwIDQ4Y2MgICAgIHNuZF9zYjgua28KCUNvbnRhaW5zIG1vZHVs ZXM6CgkJSWQgTmFtZQoJCTMzIHNiYy9zbmRfc2I4CjIzICAgIDIgMHhjMDgxMTAwMCA1ODM4ICAg ICBzbmRfc29sby5rbwoJQ29udGFpbnMgbW9kdWxlczoKCQlJZCBOYW1lCgkJMzQgcGNpL3NuZF9z b2xvCjI0ICAgIDIgMHhjMDgxNzAwMCA1MWY4ICAgICBzbmRfdDRkd2F2ZS5rbwoJQ29udGFpbnMg bW9kdWxlczoKCQlJZCBOYW1lCgkJMzUgcGNpL3NuZF90NGR3YXZlCjI1ICAgIDIgMHhjMDgxZDAw MCA2MGYwICAgICBzbmRfdmlhODIzMy5rbwoJQ29udGFpbnMgbW9kdWxlczoKCQlJZCBOYW1lCgkJ MzYgcGNpL3NuZF92aWE4MjMzCjI2ICAgIDIgMHhjMDgyNDAwMCA0OWJjICAgICBzbmRfdmlhODJj Njg2LmtvCglDb250YWlucyBtb2R1bGVzOgoJCUlkIE5hbWUKCQkzNyBwY2kvc25kX3ZpYTgyYzY4 NgoyNyAgICAyIDB4YzA4MjkwMDAgNDU4NCAgICAgc25kX3ZpYmVzLmtvCglDb250YWlucyBtb2R1 bGVzOgoJCUlkIE5hbWUKCQkzOCBwY2kvc25kX3ZpYmVzCjI4ICAgIDEgMHhjMDgyZTAwMCA1OTdh YyAgICBhY3BpLmtvCglDb250YWlucyBtb2R1bGVzOgoJCUlkIE5hbWUKCQk0MCBuZXh1cy9hY3Bp CgkJNDEgYWNwaS9hY3BpX2J1dHRvbgoJCTQyIGFjcGkvYWNwaV9pc2FiCgkJNDMgcGNpYi9hY3Bp X3BjaQoJCTQ0IGFjcGkvYWNwaV9wY2liCgkJNDUgcGNpL2FjcGlfcGNpYgoJCTQ2IGFjcGkvYWNw aV9zeXNyZXNvdXJjZQoJCTQ3IGFjcGkvYWNwaV90aW1lcgoJCTQ4IGFjcGkvYWNwaV9wY2lfbGlu awoJCTQ5IGFjcGkvYWNwaV90egoJCTUwIGFjcGkvYWNwaV9hY2FkCgkJNTEgYWNwaS9hY3BpX2Nt YmF0CgkJNTIgYWNwaS9jcHUKCQk1MyBhY3BpL2FjcGlfZWMKCQk1NCBhY3BpL2FjcGlfbGlkCgkJ NTUgY3B1L2FjcGlfcGVyZgoJCTU2IGFjcGkvYWNwaV9zbWJhdAoJCTU3IGNwdS9hY3BpX3Rocm90 dGxlCjI5ICAgIDEgMHhjNGVkNjAwMCAzMDAwMCAgICBpd2lfYnNzLmtvCglDb250YWlucyBtb2R1 bGVzOgoJCUlkIE5hbWUKCQkyMzkgaXdpX2Jzc19mdwozMCAgICAxIDB4YzRmZmEwMDAgMTYwMDAg ICAgbGludXgua28KCUNvbnRhaW5zIG1vZHVsZXM6CgkJSWQgTmFtZQoJCTI0MCBsaW51eGVsZgoJ CTI0MSBsaW51eGFvdXQKMzEgICAgMSAweGM1MDUxMDAwIDIwMDAgICAgIHNuYWtlX3NhdmVyLmtv CglDb250YWlucyBtb2R1bGVzOgoJCUlkIE5hbWUKCQkyNDIgc25ha2Vfc2F2ZXIKa2xkbG9hZDog CmNhbid0IGxvYWQgaXdpX2Jzcwo6IApGaWxlIGV4aXN0cwphZnRlciBpd2kgbG9hZApJZCBSZWZz IEFkZHJlc3MgICAgU2l6ZSAgICAgTmFtZQogMSAgIDM3IDB4YzA0MDAwMDAgMzU3NmYwICAga2Vy bmVsCglDb250YWlucyBtb2R1bGVzOgoJCUlkIE5hbWUKCQk1OCBjYW0KCQk1OSBwcm9iZQoJCTYw IHhwdAoJCTYxIGNkCgkJNjIgcGFzcwoJCTYzIGF0YQoJCTY0IHBjY2FyZC9hdGEKCQk2NSBhdGEv YWQKCQk2NiBpc2EvYXRhCgkJNjcgYXRhcGNpL2F0YQoJCTY4IHBjaS9hdGFwY2kKCQk2OSBhdGEv YXRhcGljYW0KCQk3MCBhdGEvYWNkCgkJNzEgYmZlL21paWJ1cwoJCTcyIHBjaS9iZmUKCQk3MyBj YmIvY2FyZGJ1cwoJCTc0IGV4Y2EKCQk3NSBmd29oY2kvZmlyZXdpcmUKCQk3NiBjYXJkYnVzL2Z3 b2hjaQoJCTc3IHBjaS9md29oY2kKCQk3OCBmaXJld2lyZS9md2UKCQk3OSBmaXJld2lyZS9zYnAK CQk4MCBwY2kvaXdpCgkJODEgZ19tZAoJCTgyIG1lbQoJCTgzIG1paWJ1cy9hY3BoeQoJCTg0IG1p aWJ1cy9hbXBoeQoJCTg1IG1paWJ1cy9ibXRwaHkKCQk4NiBtaWlidXMvYnJncGh5CgkJODcgbWlp YnVzL2NpcGh5CgkJODggbWlpYnVzL2UxMDAwcGh5CgkJODkgbWlpYnVzL3hscGh5CgkJOTAgbWlp YnVzL2lucGh5CgkJOTEgbWlpYnVzL2x4dHBoeQoJCTkyIG1paWJ1cy9tbHBoeQoJCTkzIG1paWJ1 cy9uc2dwaHkKCQk5NCBtaWlidXMvbnNwaHkKCQk5NSBtaWlidXMvcG5hcGh5CgkJOTYgbWlpYnVz L3BucGh5CgkJOTcgbWlpYnVzL3FzcGh5CgkJOTggbWlpYnVzL3JnZXBoeQoJCTk5IG1paWJ1cy9y bHBoeQoJCTEwMCBtaWlidXMvcnVlcGh5CgkJMTAxIG1paWJ1cy90ZGtwaHkKCQkxMDIgbWlpYnVz L3RscGh5CgkJMTAzIG1paWJ1cy91a3BoeQoJCTEwNCBtaWlidXMveG1waHkKCQkxMDUgbnVsbAoJ CTEwNiBjYmIvcGNjYXJkCgkJMTA3IHBjaWMvcGNjYXJkCgkJMTA4IGlzYS9jYmIKCQkxMDkgcGNp L2NiYgoJCTExMCBwY2kvZml4dXBfcGNpCgkJMTExIHBjaS9pZ25vcmVfcGNpCgkJMTEyIHBjaS9p c2FiCgkJMTEzIHBjaWIvcGNpCgkJMTE0IHBjaS9wY2liCgkJMTE1IHBwYnVzL2xwdAoJCTExNiBw cGMvcHBidXMKCQkxMTcgcHBidXMvcHBpCgkJMTE4IHJhbmRvbQoJCTExOSBhdWUvbWlpYnVzCgkJ MTIwIHVodWIvYXVlCgkJMTIxIGF4ZS9taWlidXMKCQkxMjIgdWh1Yi9heGUKCQkxMjMgdWh1Yi9j ZGNlCgkJMTI0IHVodWIvY3VlCgkJMTI1IHVodWIva3VlCgkJMTI2IHJ1ZS9taWlidXMKCQkxMjcg dWh1Yi9ydWUKCQkxMjggY2FyZGJ1cy9vaGNpCgkJMTI5IHBjaS9vaGNpCgkJMTMwIHVodWIvdWdl bgoJCTEzMSBjYXJkYnVzL3VoY2kKCQkxMzIgcGNpL3VoY2kKCQkxMzMgdWh1Yi91aGlkCgkJMTM0 IHVodWIvdWh1YgoJCTEzNSB1c2IvdWh1YgoJCTEzNiB1aHViL3VrYmQKCQkxMzcgdWh1Yi91bHB0 CgkJMTM4IHVodWIvdW1hc3MKCQkxMzkgdWh1Yi91bXMKCQkxNDAgdWh1Yi91cmlvCgkJMTQxIGVo Y2kvdXNiCgkJMTQyIHVoY2kvdXNiCgkJMTQzIG9oY2kvdXNiCgkJMTQ0IHVodWIvdXNjYW5uZXIK CQkxNDUgd2F0Y2hkb2cKCQkxNDYgZGV2ZnMKCQkxNDcgcHJvY2ZzCgkJMTQ4IHBzZXVkb2ZzCgkJ MTQ5IGdfZGV2CgkJMTUwIGdfZGlzawoJCTE1MSBnX2dwdAoJCTE1MiBnX3ZmcwoJCTE1MyBlaXNh Yi9pc2EKCQkxNTQgaXNhYi9pc2EKCQkxNTUgaXNhL2lzYWhpbnQKCQkxNTYgaXNhL29ybQoJCTE1 NyBpc2EvcG5wCgkJMTU4IGNkOTY2MAoJCTE1OSBlbGYzMgoJCTE2MCBzaGVsbAoJCTE2MSBjcHUv Y3B1ZnJlcQoJCTE2MiByb290YnVzCgkJMTYzIGZpcm13YXJlCgkJMTY0IHN5c3Ztc2cKCQkxNjUg bXNncmN2CgkJMTY2IG1zZ3NuZAoJCTE2NyBtc2dnZXQKCQkxNjggbXNnY3RsCgkJMTY5IG1zZ3N5 cwoJCTE3MCBzeXN2c2VtCgkJMTcxIHNlbW9wCgkJMTcyIHNlbWdldAoJCTE3MyBfX3NlbWN0bAoJ CTE3NCBzZW1zeXMKCQkxNzUgc3lzdnNobQoJCTE3NiBzaG1nZXQKCQkxNzcgc2htZHQKCQkxNzgg c2htY3RsCgkJMTc5IHNobWF0CgkJMTgwIHNobXN5cwoJCTE4MSBldGhlcgoJCTE4MiBsb29wCgkJ MTgzIGlmX3BwcAoJCTE4NCBpZl9zbAoJCTE4NSBpZl90dW4KCQkxODYgd2xhbl93ZXAKCQkxODcg d2xhbgoJCTE4OCBwY2kvZGUKCQkxODkgdWZzCgkJMTkwIGdfY2xhc3MKCQkxOTEgYXRrYmRjL2F0 a2JkCgkJMTkyIGFjcGkvYXRrYmRjCgkJMTkzIGlzYS9hdGtiZGMKCQkxOTQgYWNwaS9wc21jcG5w CgkJMTk1IGlzYS9wc21jcG5wCgkJMTk2IGF0a2JkYy9wc20KCQkxOTcgaW8KCQkxOTggYWNwaS9w cGMKCQkxOTkgaXNhL3BwYwoJCTIwMCBzY3Rlcm0tc2MKCQkyMDEgc2NybmRyLXZnYQoJCTIwMiBn X2JzZAoJCTIwMyBnX21icmV4dAoJCTIwNCBnX21icgoJCTIwNSBpc2EvcG5wYmlvcwoJCTIwNiBs ZWdhY3kvY3B1CgkJMjA3IG5leHVzL2xlZ2FjeQoJCTIwOCBwY2kvbXB0YWJsZV9wY2liCgkJMjA5 IGxlZ2FjeS9tcHRhYmxlX3BjaWIKCQkyMTAgaXNhL3N5c3Jlc291cmNlCgkJMjExIHJvb3QvbmV4 dXMKCQkyMTIgYWNwaS9hdHBpYwoJCTIxMyBpc2EvYXRwaWMKCQkyMTQgYWNwaS9hdHRpbWVyCgkJ MjE1IGlzYS9hdHRpbWVyCgkJMjE2IGxlZ2FjeS9pc2EKCQkyMTcgYWNwaS9hdGRtYQoJCTIxOCBp c2EvYXRkbWEKCQkyMTkgYWNwaS9ucHhpc2EKCQkyMjAgaXNhL25weGlzYQoJCTIyMSBuZXh1cy9u cHgKCQkyMjIgaXNhL3BtdGltZXIKCQkyMjMgcGNpL3BjaWJpb3NfcGNpYgoJCTIyNCBpc2EvcGNp YnVzX3BucAoJCTIyNSBwY2kvaG9zdGIKCQkyMjYgbGVnYWN5L3BjaWIKCQkyMjcgbGVnYWN5L3Bp cgoJCTIyOCBpc2Evc2MKCQkyMjkgaXNhL3ZnYQoJCTIzMCBwY2kvYWdwX2FsaQoJCTIzMSBwY2kv YWdwX2FtZAoJCTIzMiBwY2kvYWdwX2FtZDY0CgkJMjMzIHBjaS9hZ3BfYXRpCgkJMjM0IHBjaS9h Z3BfaTgxMAoJCTIzNSBwY2kvYWdwX2ludGVsCgkJMjM2IHBjaS9hZ3BfbnZpZGlhCgkJMjM3IHBj aS9hZ3Bfc2lzCgkJMjM4IHBjaS9hZ3BfdmlhCiAyICAgIDEgMHhjMDc1ODAwMCAzMzhjICAgICBz bmRfZHJpdmVyLmtvCglDb250YWlucyBtb2R1bGVzOgoJCUlkIE5hbWUKCQkzOSBzbmRfZHJpdmVy CiAzICAgIDIgMHhjMDc1YzAwMCA0ZDQ4ICAgICBzbmRfYWQxODE2LmtvCglDb250YWlucyBtb2R1 bGVzOgoJCUlkIE5hbWUKCQkgMiBhY3BpL3NuZF9hZDE4MTYKCQkgMyBpc2Evc25kX2FkMTgxNgog NCAgIDMwIDB4YzA3NjEwMDAgMjJhZTggICAgc291bmQua28KCUNvbnRhaW5zIG1vZHVsZXM6CgkJ SWQgTmFtZQoJCSAxIHNvdW5kCiA1ICAgIDIgMHhjMDc4NDAwMCA1MWI0ICAgICBzbmRfYWxzNDAw MC5rbwoJQ29udGFpbnMgbW9kdWxlczoKCQlJZCBOYW1lCgkJIDQgcGNpL3NuZF9hbHM0MDAwCiA2 ICAgIDIgMHhjMDc4YTAwMCA1OTU0ICAgICBzbmRfYXRpaXhwLmtvCglDb250YWlucyBtb2R1bGVz OgoJCUlkIE5hbWUKCQkgNSBwY2kvc25kX2F0aWl4cAogNyAgICAyIDB4YzA3OTAwMDAgNGVmMCAg ICAgc25kX2NtaS5rbwoJQ29udGFpbnMgbW9kdWxlczoKCQlJZCBOYW1lCgkJIDYgcGNpL3NuZF9j bWkKIDggICAgMiAweGMwNzk1MDAwIDU1MTQgICAgIHNuZF9jczQyODEua28KCUNvbnRhaW5zIG1v ZHVsZXM6CgkJSWQgTmFtZQoJCSA3IHBjaS9zbmRfY3M0MjgxCiA5ICAgIDMgMHhjMDc5YjAwMCA3 NGQwICAgICBzbmRfY3NhLmtvCglDb250YWlucyBtb2R1bGVzOgoJCUlkIE5hbWUKCQkgOCBwY2kv c25kX2NzYQoJCSA5IGNzYS9zbmRfY3NhcGNtCjEwICAgIDIgMHhjMDdhMzAwMCBiZmEwICAgICBz bmRfZHMxLmtvCglDb250YWlucyBtb2R1bGVzOgoJCUlkIE5hbWUKCQkxMCBwY2kvc25kX2RzMQox MSAgICAyIDB4YzA3YWYwMDAgNzY3NCAgICAgc25kX2VtdTEwazEua28KCUNvbnRhaW5zIG1vZHVs ZXM6CgkJSWQgTmFtZQoJCTExIHBjaS9lbXVqb3kKCQkxMiBjYXJkYnVzL3NuZF9lbXUxMGsxCgkJ MTMgcGNpL3NuZF9lbXUxMGsxCjEyICAgIDIgMHhjMDdiNzAwMCA3MTljICAgICBzbmRfZXMxMzd4 LmtvCglDb250YWlucyBtb2R1bGVzOgoJCUlkIE5hbWUKCQkxNCBwY2kvc25kX2VzMTM3eAoxMyAg ICAzIDB4YzA3YmYwMDAgNGZkOCAgICAgc25kX2Vzcy5rbwoJQ29udGFpbnMgbW9kdWxlczoKCQlJ ZCBOYW1lCgkJMTcgYWNwaS9lc3Njb250cm9sCgkJMTggaXNhL2Vzc2NvbnRyb2wKCQkxOSBzYmMv c25kX2VzcwoJCTIwIGlzYS9zbmRfZXMxODg4CjE0ICAgIDUgMHhjMDdjNDAwMCA0ODljICAgICBz bmRfc2JjLmtvCglDb250YWlucyBtb2R1bGVzOgoJCUlkIE5hbWUKCQkxNSBhY3BpL3NuZF9zYmMK CQkxNiBpc2Evc25kX3NiYwoxNSAgICAyIDB4YzA3YzkwMDAgNDk4NCAgICAgc25kX2ZtODAxLmtv CglDb250YWlucyBtb2R1bGVzOgoJCUlkIE5hbWUKCQkyMSBwY2kvc25kX2ZtODAxCjE2ICAgIDMg MHhjMDdjZTAwMCBiM2QwICAgICBzbmRfbXNzLmtvCglDb250YWlucyBtb2R1bGVzOgoJCUlkIE5h bWUKCQkyMiBndXNjL3NuZF9ndXNwY20KCQkyMyBhY3BpL3NuZF9wbnBtc3MKCQkyNCBpc2Evc25k X3BucG1zcwoJCTI1IGlzYS9zbmRfbXNzCgkJMjYgYWNwaS9zbmRfZ3VzYwoJCTI3IGlzYS9zbmRf Z3VzYwoxNyAgICAyIDB4YzA3ZGEwMDAgNWVjMCAgICAgc25kX2ljaC5rbwoJQ29udGFpbnMgbW9k dWxlczoKCQlJZCBOYW1lCgkJMjggcGNpL3NuZF9pY2gKMTggICAgMiAweGMwN2UwMDAwIGI0Njgg ICAgIHNuZF9tYWVzdHJvLmtvCglDb250YWlucyBtb2R1bGVzOgoJCUlkIE5hbWUKCQkyOSBwY2kv c25kX21hZXN0cm8KMTkgICAgMiAweGMwN2VjMDAwIDkzZjQgICAgIHNuZF9tYWVzdHJvMy5rbwoJ Q29udGFpbnMgbW9kdWxlczoKCQlJZCBOYW1lCgkJMzAgcGNpL3NuZF9tYWVzdHJvMwoyMCAgICAy IDB4YzA3ZjYwMDAgMTA5NDggICAgc25kX25lb21hZ2ljLmtvCglDb250YWlucyBtb2R1bGVzOgoJ CUlkIE5hbWUKCQkzMSBwY2kvc25kX25lb21hZ2ljCjIxICAgIDIgMHhjMDgwNzAwMCA0ZWMwICAg ICBzbmRfc2IxNi5rbwoJQ29udGFpbnMgbW9kdWxlczoKCQlJZCBOYW1lCgkJMzIgc2JjL3NuZF9z YjE2CjIyICAgIDIgMHhjMDgwYzAwMCA0OGNjICAgICBzbmRfc2I4LmtvCglDb250YWlucyBtb2R1 bGVzOgoJCUlkIE5hbWUKCQkzMyBzYmMvc25kX3NiOAoyMyAgICAyIDB4YzA4MTEwMDAgNTgzOCAg ICAgc25kX3NvbG8ua28KCUNvbnRhaW5zIG1vZHVsZXM6CgkJSWQgTmFtZQoJCTM0IHBjaS9zbmRf c29sbwoyNCAgICAyIDB4YzA4MTcwMDAgNTFmOCAgICAgc25kX3Q0ZHdhdmUua28KCUNvbnRhaW5z IG1vZHVsZXM6CgkJSWQgTmFtZQoJCTM1IHBjaS9zbmRfdDRkd2F2ZQoyNSAgICAyIDB4YzA4MWQw MDAgNjBmMCAgICAgc25kX3ZpYTgyMzMua28KCUNvbnRhaW5zIG1vZHVsZXM6CgkJSWQgTmFtZQoJ CTM2IHBjaS9zbmRfdmlhODIzMwoyNiAgICAyIDB4YzA4MjQwMDAgNDliYyAgICAgc25kX3ZpYTgy YzY4Ni5rbwoJQ29udGFpbnMgbW9kdWxlczoKCQlJZCBOYW1lCgkJMzcgcGNpL3NuZF92aWE4MmM2 ODYKMjcgICAgMiAweGMwODI5MDAwIDQ1ODQgICAgIHNuZF92aWJlcy5rbwoJQ29udGFpbnMgbW9k dWxlczoKCQlJZCBOYW1lCgkJMzggcGNpL3NuZF92aWJlcwoyOCAgICAxIDB4YzA4MmUwMDAgNTk3 YWMgICAgYWNwaS5rbwoJQ29udGFpbnMgbW9kdWxlczoKCQlJZCBOYW1lCgkJNDAgbmV4dXMvYWNw aQoJCTQxIGFjcGkvYWNwaV9idXR0b24KCQk0MiBhY3BpL2FjcGlfaXNhYgoJCTQzIHBjaWIvYWNw aV9wY2kKCQk0NCBhY3BpL2FjcGlfcGNpYgoJCTQ1IHBjaS9hY3BpX3BjaWIKCQk0NiBhY3BpL2Fj cGlfc3lzcmVzb3VyY2UKCQk0NyBhY3BpL2FjcGlfdGltZXIKCQk0OCBhY3BpL2FjcGlfcGNpX2xp bmsKCQk0OSBhY3BpL2FjcGlfdHoKCQk1MCBhY3BpL2FjcGlfYWNhZAoJCTUxIGFjcGkvYWNwaV9j bWJhdAoJCTUyIGFjcGkvY3B1CgkJNTMgYWNwaS9hY3BpX2VjCgkJNTQgYWNwaS9hY3BpX2xpZAoJ CTU1IGNwdS9hY3BpX3BlcmYKCQk1NiBhY3BpL2FjcGlfc21iYXQKCQk1NyBjcHUvYWNwaV90aHJv dHRsZQoyOSAgICAxIDB4YzRlZDYwMDAgMzAwMDAgICAgaXdpX2Jzcy5rbwoJQ29udGFpbnMgbW9k dWxlczoKCQlJZCBOYW1lCgkJMjM5IGl3aV9ic3NfZncKMzAgICAgMSAweGM0ZmZhMDAwIDE2MDAw ICAgIGxpbnV4LmtvCglDb250YWlucyBtb2R1bGVzOgoJCUlkIE5hbWUKCQkyNDAgbGludXhlbGYK CQkyNDEgbGludXhhb3V0CjMxICAgIDEgMHhjNTA1MTAwMCAyMDAwICAgICBzbmFrZV9zYXZlci5r bwoJQ29udGFpbnMgbW9kdWxlczoKCQlJZCBOYW1lCgkJMjQyIHNuYWtlX3NhdmVyClN0YXJ0aW5n IGRlZmF1bHQgbW91c2VkOgouClN0YXJ0aW5nIGJhY2tncm91bmQgZmlsZSBzeXN0ZW0gY2hlY2tz IGluIDYwIHNlY29uZHMuCgpUaHUgSnVsIDI3IDE3OjUxOjI0IENEVCAyMDA2Cg== ------=_Part_87347_31280105.1154044804161-- From owner-freebsd-stable@FreeBSD.ORG Fri Jul 28 00:12:41 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5DF7E16A4DD for ; Fri, 28 Jul 2006 00:12:41 +0000 (UTC) (envelope-from prvs=julian=357b23966@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 009AC43D4C for ; Fri, 28 Jul 2006 00:12:40 +0000 (GMT) (envelope-from prvs=julian=357b23966@elischer.org) Received: from unknown (HELO [192.168.2.4]) ([10.251.60.57]) by a50.ironport.com with ESMTP; 27 Jul 2006 17:12:40 -0700 Message-ID: <44C95678.1070306@elischer.org> Date: Thu, 27 Jul 2006 17:12:40 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: stable@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Monitoring temperature with acpi (sysctls) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 00:12:41 -0000 Someone mentionned that you can't reach the smbus on ASUS boards. That's because they turn it off in the BIOS. They turn it on and off as they need to read stuff for their SMI (well on some of their boards at least). you can turn it on again using pciconf. but I forget the exact incantation. (I've asked someone to send me the script so I'll have it later if anyone wants it) From owner-freebsd-stable@FreeBSD.ORG Fri Jul 28 00:22:03 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 969A416A4DE for ; Fri, 28 Jul 2006 00:22:03 +0000 (UTC) (envelope-from dwilde1@gmail.com) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id F339143D46 for ; Fri, 28 Jul 2006 00:22:02 +0000 (GMT) (envelope-from dwilde1@gmail.com) Received: by wx-out-0102.google.com with SMTP id s16so183802wxc for ; Thu, 27 Jul 2006 17:22:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=SOj/9or+Xu1Pp47RWGaUdj5/rtoDKG9MRzZxeI+5dE5ujZR51ZQQO2tMg++t5LD06q+E66tP5NCba6lK+O6Gc1DZ2Mit1kE4ImSCXYURdwZksrH2y/gyU9uxprsc3dvWHccob/cgLRCdd9xgMUADS1XFetvAxo+1RUziMc0ycII= Received: by 10.70.132.16 with SMTP id f16mr1471120wxd; Thu, 27 Jul 2006 17:22:02 -0700 (PDT) Received: by 10.70.16.9 with HTTP; Thu, 27 Jul 2006 17:22:02 -0700 (PDT) Message-ID: Date: Thu, 27 Jul 2006 19:22:02 -0500 From: "Don Wilde" Sender: dwilde1@gmail.com To: "Max Laier" In-Reply-To: MIME-Version: 1.0 References: <200607271822.k6RIMHp2097311@crimson.hydrus.org.uk> <200607272244.13115.max@love2party.net> X-Google-Sender-Auth: 0e5938fa3d1b0d00 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: iwi(4) in RELENG_6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 00:22:03 -0000 On 7/27/06, Don Wilde wrote: > > > > On 7/27/06, Max Laier wrote: > > > > [Please don't top-post] > > > > On Thursday 27 July 2006 21:01, Don Wilde wrote: > > > Yes, I have. I just did another CVSup, and when I recompiled -kmod it > > did > > > indeed put a bunch of .ko files in /build/modules, but a) I still get > > a > > > whole bunch of Can't load firmware complaints, and b) it doesn't work. > > It > > > goes through the DISCOVER process, but doesn't get any offers it > > > recognizes. I've tried this both with an open DHCP and also with my > > > parameters wired in. > > > > > > Hardware notes: Dell 6100 Inspiron with 2200G iwi. I have heard from > > > another gent who has a 2200G pci card and is having the same problem > > with > > > STABLE. > > > > > > This all was working two weeks ago. > > > > Just to get the facts straight and assembled in one place: > > > > You are running a somewhat recent RELENG_6, have net/iwi-firmware-kmod > > installed and "device iwi" and "options firmware" built into your > > kernel? > > > > When do you get the "Can't load firmware" messages? What does kldstat > > [-v] > > say before and after that point? Can you try "kldload iwi_bss" before > > and > > see if that gets you up and running? > > > > > On 7/27/06, Mark Willson wrote: > > > > Have you tried using the firmware from iwi-firmware-kmod, rather > > than > > > > iwi-firmware. I am using the former on a Thinkpad T42 and it is > > working > > > > ok. > > > > Hi, Max - > > I did so, and it appears that the module is already loaded. It seems that > the problems occur because my system is also trying to load the old firmware > somehow. > > A more disturbing issue is that my rc.conf seems to be being read twice. I > see the kldstat reports (with my echo commands) being printed four times > instead of the two I'm requesting. Attached are my rc.conf and dmesg. > Okay, I've gotten it working with all encryption off (raw DHCP). All the nasty messages went away, so I'll see what's changed in the ifconfig options. ifconfig_iwi0="DHCP ssid rewired channel 11 authmode shared weptxkey 1 wepmode on wepkey 0x1234567890" Can anybody spot it off the top? From owner-freebsd-stable@FreeBSD.ORG Fri Jul 28 00:32:32 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D52716A4DD; Fri, 28 Jul 2006 00:32:32 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3CEC43D73; Fri, 28 Jul 2006 00:32:31 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id k6S0WSEH095764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Jul 2006 17:32:30 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <44C95B1C.1080305@errno.com> Date: Thu, 27 Jul 2006 17:32:28 -0700 From: Sam Leffler User-Agent: Thunderbird 1.5.0.4 (X11/20060724) MIME-Version: 1.0 To: Andrew Thompson References: <20060720224632.GB31459@osgiliath.brixandersen.dk> <44C00B40.2010901@errno.com> <20060726144058.GD3077@osgiliath.opasia.dk> <44C793DB.5090900@errno.com> <20060726163017.GB5856@osgiliath.opasia.dk> <44C7AF68.3090109@errno.com> <20060726181534.GD5856@osgiliath.opasia.dk> <44C7D05C.8000408@errno.com> <20060726215341.GA7763@heff.fud.org.nz> <44C95084.6020209@errno.com> In-Reply-To: <44C95084.6020209@errno.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: "scan stuck" with if_iwi(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 00:32:32 -0000 Sam Leffler wrote: > Andrew Thompson wrote: >> On Wed, Jul 26, 2006 at 01:28:12PM -0700, Sam Leffler wrote: >>> Henrik Brix Andersen wrote: >>>> Oh? Sounds interesting, where can I find these patches? >>> The work has always been in perforce.freebsd.org; look in the sam_wifi >>> branch. The code will not hit head until folks show up to fix legacy >>> drivers that use net80211. I got stuck holding the bag when I committed >>> the wpa support and it ain't going to happen again. >>> >> Do you have a list of drivers that are stalling this? > > The changes decouple scanning from the net80211 state machine so any > driver that uses ieee80211_new_state is affected: > > tubby% grep -l ieee80211_new_state */*.c > ath/if_ath.c > awi/awi.c > ipw/if_ipw.c > iwi/if_iwi.c > ral/rt2560.c > ral/rt2661.c > usb/if_ural.c > wi/if_wi.c > > I know how to convert ath and ral. iwi and ipw might not be too bad now > that they've been changed to not abuse the state machine so much. awi, > ural, and wi will break. ural might be ok after the new usb stack comes > in but that's not clear. > > So I guess I'd take responsibility for ath and ral and want help with > all other drivers. I forgot the other key item missing from the above list: ndis. It bypasses the net80211 api's lots of places and frobs things directly so converting may be a big job--hard to say until someone tries it. Sam From owner-freebsd-stable@FreeBSD.ORG Fri Jul 28 00:32:32 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C09E16A4DF for ; Fri, 28 Jul 2006 00:32:32 +0000 (UTC) (envelope-from dwilde1@gmail.com) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8BF4F43D6B for ; Fri, 28 Jul 2006 00:32:26 +0000 (GMT) (envelope-from dwilde1@gmail.com) Received: by wx-out-0102.google.com with SMTP id s16so185030wxc for ; Thu, 27 Jul 2006 17:32:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=JQC1CU5Ki+2sxWbkSdGVrIoV9TGflqBdxRb+bZIiWYefKqoRN9tF77jlcP16+YOELNEYIaRj3D6GCWYdVlQnu7cER7M3AJWnSW3An3qO43pU9sCSKDs9rGVyqD9ZZkairvWTP4YXJblhBjwBWyjqVUbjBQy9xfj6wZTU0iVlPwQ= Received: by 10.70.7.7 with SMTP id 7mr1488146wxg; Thu, 27 Jul 2006 17:32:25 -0700 (PDT) Received: by 10.70.16.9 with HTTP; Thu, 27 Jul 2006 17:32:23 -0700 (PDT) Message-ID: Date: Thu, 27 Jul 2006 19:32:23 -0500 From: "Don Wilde" Sender: dwilde1@gmail.com To: "Max Laier" In-Reply-To: MIME-Version: 1.0 References: <200607271822.k6RIMHp2097311@crimson.hydrus.org.uk> <200607272244.13115.max@love2party.net> X-Google-Sender-Auth: ac2b50c35990bae6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: iwi(4) in RELENG_6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 00:32:32 -0000 On 7/27/06, Don Wilde wrote: > > On 7/27/06, Don Wilde wrote: > > > > > > > On 7/27/06, Max Laier < max@love2party.net> wrote: > > > > > > [Please don't top-post] > > > > > > On Thursday 27 July 2006 21:01, Don Wilde wrote: > > > > Yes, I have. I just did another CVSup, and when I recompiled -kmod > > > it did > > > > indeed put a bunch of .ko files in /build/modules, but a) I still > > > get a > > > > whole bunch of Can't load firmware complaints, and b) it doesn't > > > work. It > > > > goes through the DISCOVER process, but doesn't get any offers it > > > > recognizes. I've tried this both with an open DHCP and also with my > > > > parameters wired in. > > > > > > > > Hardware notes: Dell 6100 Inspiron with 2200G iwi. I have heard from > > > > another gent who has a 2200G pci card and is having the same problem > > > with > > > > STABLE. > > > > > > > > This all was working two weeks ago. > > > > > > Just to get the facts straight and assembled in one place: > > > > > > You are running a somewhat recent RELENG_6, have net/iwi-firmware-kmod > > > installed and "device iwi" and "options firmware" built into your > > > kernel? > > > > > > When do you get the "Can't load firmware" messages? What does kldstat > > > [-v] > > > say before and after that point? Can you try "kldload iwi_bss" before > > > and > > > see if that gets you up and running? > > > > > > > On 7/27/06, Mark Willson wrote: > > > > > Have you tried using the firmware from iwi-firmware-kmod, rather > > > than > > > > > iwi-firmware. I am using the former on a Thinkpad T42 and it is > > > working > > > > > ok. > > > > > > > > Hi, Max - > > > > I did so, and it appears that the module is already loaded. It seems > > that the problems occur because my system is also trying to load the old > > firmware somehow. > > > > A more disturbing issue is that my rc.conf seems to be being read twice. > > I see the kldstat reports (with my echo commands) being printed four times > > instead of the two I'm requesting. Attached are my rc.conf and dmesg. > > > > Okay, I've gotten it working with all encryption off (raw DHCP). All the > nasty messages went away, so I'll see what's changed in the ifconfig > options. > > ifconfig_iwi0="DHCP ssid rewired channel 11 authmode shared weptxkey 1 > wepmode on wepkey 0x1234567890" > > Can anybody spot it off the top? > By removing the hardwired 'channel 11 authmode shared' from both sides, I have been able to connect successfully with WEP authentication. Thanks for all your suggestions, guys! :D From owner-freebsd-stable@FreeBSD.ORG Fri Jul 28 01:07:56 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E49716A4DF for ; Fri, 28 Jul 2006 01:07:56 +0000 (UTC) (envelope-from drosih@rpi.edu) Received: from smtp6.server.rpi.edu (smtp6.server.rpi.edu [128.113.2.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id E181143D7C for ; Fri, 28 Jul 2006 01:07:47 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp6.server.rpi.edu (8.13.1/8.13.1) with ESMTP id k6S17kab005659 for ; Thu, 27 Jul 2006 21:07:46 -0400 Mime-Version: 1.0 Message-Id: Date: Thu, 27 Jul 2006 21:07:45 -0400 To: freebsd-stable@freebsd.org From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) Subject: Weird problems with 'pf' (on both 5.x and 6.x) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 01:07:56 -0000 It happens that I noticed two odd networking problems recently. One of them is easily reproducible, and I have it tracked down to one innocuous-looking line in my /etc/pf.conf. The other is a problem in a chat server that I run, with a few hundred people on it, and is much more of a hassle to reproduce. But turning off 'pf' to solve the first problem seems to have also solved the second problem, so I assume both problems come from the same culprit. Once I figured out how to reproduce the problem, it seems so easy to reproduce that I find it odd that no one else has run into it. But I also do not notice any PR's that seemed to describe the problem. I'd appreciate it if people would try to duplicate the problem on some other machines. This problem has been seen on: 5.x-stable as built on Mon Jul 24 6.x-stable as built on Mon Jul 17 (as well as several earlier snapshots of both 5.x and 6.x). I have a freebsd box which is the server for a print queue named 'bill', and is running pf. I have other machines which reference that queue. It seems that machines on the same subnet as the server-box do not exhibit the problem. But for other machines, if I do 'lpq -Pbill' twice in rapid succession, then the second one will hang. After some futzing around, I determined that if my pf.conf has only the lines: # Filtering: the implicit first two rules are #pass in all #pass out all then I can do many many lpq's in a row, without any trouble. But if I restart pf after adding these lines to pf.conf: # Allow all outgoing tcp and udp connections and keep state pass out quick proto { tcp, udp } all keep state then I have the problem where the second 'lpq' from a remote host will hang, if it is done right after the first one. That's right. I add a rule which just does "quick passing" for *outbound* connections, and somehow that screws up (blocks?) *incoming* connections. I have no rules which should block any packets at all, so my guess is that some packets are getting lost, delayed, or corrupted somewhere. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-stable@FreeBSD.ORG Fri Jul 28 01:18:18 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 20A1E16A4DD for ; Fri, 28 Jul 2006 01:18:18 +0000 (UTC) (envelope-from drosih@rpi.edu) Received: from smtp7.server.rpi.edu (smtp7.server.rpi.edu [128.113.2.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DBB843D46 for ; Fri, 28 Jul 2006 01:18:17 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp7.server.rpi.edu (8.13.1/8.13.1) with ESMTP id k6S1IEN4024853 for ; Thu, 27 Jul 2006 21:18:16 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 27 Jul 2006 21:18:13 -0400 To: freebsd-stable@freebsd.org From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) Subject: Re: Weird problems with 'pf' (on both 5.x and 6.x) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 01:18:18 -0000 At 9:07 PM -0400 7/27/06, Garance A Drosihn wrote: > >But if I restart pf after adding these lines to pf.conf: > > # Allow all outgoing tcp and udp connections and keep state > pass out quick proto { tcp, udp } all keep state > >then I have the problem where the second 'lpq' from a remote >host will hang, if it is done right after the first one. The client-machine which is doing the lpq is a solaris machine, so here is the 'snoop' output from that side of things. Disclaimer: I'm not a networking expert, so I'm hoping someone else will find this a lot more obvious than I do. Here's the packets from the first 'lpq', with various names changed to protect the innocent (and to reduce the wrapping a little bit...): ________________________________ 1 0.00000 lpq-client -> print-serv ETHER Type=0800 (IP), size = 62 bytes 1 0.00000 lpq-client -> print-serv IP D=128.113.000.001 S=128.113.002.002 LEN=48, ID=13267 1 0.00000 lpq-client -> print-serv TCP D=515 S=1023 Syn Seq=1503722122 Len=0 Win=24820 Options= 1 0.00000 lpq-client -> print-serv PRINTER C port=1023 ________________________________ 2 0.00068 print-serv -> lpq-client ETHER Type=0800 (IP), size = 62 bytes 2 0.00068 print-serv -> lpq-client IP D=128.113.002.002 S=128.113.000.001 LEN=48, ID=4007 2 0.00068 print-serv -> lpq-client TCP D=1023 S=515 Syn Ack=1503722123 Seq=1874442309 Len=0 Win=65535 Options= 2 0.00068 print-serv -> lpq-client PRINTER R port=1023 ________________________________ 3 0.00072 lpq-client -> print-serv ETHER Type=0800 (IP), size = 54 bytes 3 0.00072 lpq-client -> print-serv IP D=128.113.000.001 S=128.113.002.002 LEN=40, ID=13268 3 0.00072 lpq-client -> print-serv TCP D=515 S=1023 Ack=1874442310 Seq=1503722123 Len=0 Win=24820 3 0.00072 lpq-client -> print-serv PRINTER C port=1023 ________________________________ 4 0.00088 lpq-client -> print-serv ETHER Type=0800 (IP), size = 63 bytes 4 0.00088 lpq-client -> print-serv IP D=128.113.000.001 S=128.113.002.002 LEN=49, ID=13269 4 0.00088 lpq-client -> print-serv TCP D=515 S=1023 Ack=1874442310 Seq=1503722123 Len=9 Win=24820 4 0.00088 lpq-client -> print-serv PRINTER C port=1023 \3bill\n ________________________________ 5 0.03003 print-serv -> lpq-client ETHER Type=0800 (IP), size = 132 bytes 5 0.03003 print-serv -> lpq-client IP D=128.113.002.002 S=128.113.000.001 LEN=118, ID=4045 5 0.03003 print-serv -> lpq-client TCP D=1023 S=515 Ack=1503722132 Seq=1874442310 Len=78 Win=65535 5 0.03003 print-serv -> lpq-client PRINTER R port=1023 Warning: bill is ________________________________ 6 0.03014 print-serv -> lpq-client ETHER Type=0800 (IP), size = 60 bytes 6 0.03014 print-serv -> lpq-client IP D=128.113.002.002 S=128.113.000.001 LEN=40, ID=4046 6 0.03014 print-serv -> lpq-client TCP D=1023 S=515 Fin Ack=1503722132 Seq=1874442388 Len=0 Win=65535 6 0.03014 print-serv -> lpq-client PRINTER R port=1023 ________________________________ 7 0.03020 lpq-client -> print-serv ETHER Type=0800 (IP), size = 54 bytes 7 0.03020 lpq-client -> print-serv IP D=128.113.000.001 S=128.113.002.002 LEN=40, ID=13270 7 0.03020 lpq-client -> print-serv TCP D=515 S=1023 Ack=1874442388 Seq=1503722132 Len=0 Win=24820 7 0.03020 lpq-client -> print-serv PRINTER C port=1023 ________________________________ 8 0.03022 lpq-client -> print-serv ETHER Type=0800 (IP), size = 54 bytes 8 0.03022 lpq-client -> print-serv IP D=128.113.000.001 S=128.113.002.002 LEN=40, ID=13271 8 0.03022 lpq-client -> print-serv TCP D=515 S=1023 Ack=1874442389 Seq=1503722132 Len=0 Win=24820 8 0.03022 lpq-client -> print-serv PRINTER C port=1023 ________________________________ 9 0.03074 lpq-client -> print-serv ETHER Type=0800 (IP), size = 54 bytes 9 0.03074 lpq-client -> print-serv IP D=128.113.000.001 S=128.113.002.002 LEN=40, ID=13272 9 0.03074 lpq-client -> print-serv TCP D=515 S=1023 Fin Ack=1874442389 Seq=1503722132 Len=0 Win=24820 9 0.03074 lpq-client -> print-serv PRINTER C port=1023 ________________________________ 10 0.03132 print-serv -> lpq-client ETHER Type=0800 (IP), size = 60 bytes 10 0.03132 print-serv -> lpq-client IP D=128.113.002.002 S=128.113.000.001 LEN=40, ID=4047 10 0.03132 print-serv -> lpq-client TCP D=1023 S=515 Ack=1503722133 Seq=1874442389 Len=0 Win=65534 10 0.03132 print-serv -> lpq-client PRINTER R port=1023 ________________________________ and then here is the packets from the second 'lpq', done right after the first one. It looks like the problem is in the initial handshaking to get the connection started: ________________________________ 11 7.19194 lpq-client -> print-serv ETHER Type=0800 (IP), size = 62 bytes 11 7.19194 lpq-client -> print-serv IP D=128.113.000.001 S=128.113.002.002 LEN=48, ID=13273 11 7.19194 lpq-client -> print-serv TCP D=515 S=1023 Syn Seq=1505511645 Len=0 Win=24820 Options= 11 7.19194 lpq-client -> print-serv PRINTER C port=1023 ________________________________ 12 10.55769 lpq-client -> print-serv ETHER Type=0800 (IP), size = 62 bytes 12 10.55769 lpq-client -> print-serv IP D=128.113.000.001 S=128.113.002.002 LEN=48, ID=13274 12 10.55769 lpq-client -> print-serv TCP D=515 S=1023 Syn Seq=1505511645 Len=0 Win=24820 Options= 12 10.55769 lpq-client -> print-serv PRINTER C port=1023 ________________________________ 13 17.30771 lpq-client -> print-serv ETHER Type=0800 (IP), size = 62 bytes 13 17.30771 lpq-client -> print-serv IP D=128.113.000.001 S=128.113.002.002 LEN=48, ID=13275 13 17.30771 lpq-client -> print-serv TCP D=515 S=1023 Syn Seq=1505511645 Len=0 Win=24820 Options= 13 17.30771 lpq-client -> print-serv PRINTER C port=1023 ________________________________ 14 30.80785 lpq-client -> print-serv ETHER Type=0800 (IP), size = 62 bytes 14 30.80785 lpq-client -> print-serv IP D=128.113.000.001 S=128.113.002.002 LEN=48, ID=56013 14 30.80785 lpq-client -> print-serv TCP D=515 S=1023 Syn Seq=1505511645 Len=0 Win=24820 Options= 14 30.80785 lpq-client -> print-serv PRINTER C port=1023 ________________________________ 15 57.80771 lpq-client -> print-serv ETHER Type=0800 (IP), size = 62 bytes 15 57.80771 lpq-client -> print-serv IP D=128.113.000.001 S=128.113.002.002 LEN=48, ID=56014 15 57.80771 lpq-client -> print-serv TCP D=515 S=1023 Syn Seq=1505511645 Len=0 Win=24820 Options= 15 57.80771 lpq-client -> print-serv PRINTER C port=1023 ________________________________ 16 111.80771 lpq-client -> print-serv ETHER Type=0800 (IP), size = 62 bytes 16 111.80771 lpq-client -> print-serv IP D=128.113.000.001 S=128.113.002.002 LEN=48, ID=56015 16 111.80771 lpq-client -> print-serv TCP D=515 S=1023 Syn Seq=1505511645 Len=0 Win=24820 Options= 16 111.80771 lpq-client -> print-serv PRINTER C port=1023 ________________________________ 17 111.80842 print-serv -> lpq-client ETHER Type=0800 (IP), size = 62 bytes 17 111.80842 print-serv -> lpq-client IP D=128.113.002.002 S=128.113.000.001 LEN=48, ID=4050 17 111.80842 print-serv -> lpq-client TCP D=1023 S=515 Syn Ack=1505511646 Seq=3101688498 Len=0 Win=65535 Options= 17 111.80842 print-serv -> lpq-client PRINTER R port=1023 ________________________________ 18 111.80845 lpq-client -> print-serv ETHER Type=0800 (IP), size = 54 bytes 18 111.80845 lpq-client -> print-serv IP D=128.113.000.001 S=128.113.002.002 LEN=40, ID=56016 18 111.80845 lpq-client -> print-serv TCP D=515 S=1023 Ack=3101688499 Seq=1505511646 Len=0 Win=24820 18 111.80845 lpq-client -> print-serv PRINTER C port=1023 ________________________________ 19 111.80868 lpq-client -> print-serv ETHER Type=0800 (IP), size = 63 bytes 19 111.80868 lpq-client -> print-serv IP D=128.113.000.001 S=128.113.002.002 LEN=49, ID=56017 19 111.80868 lpq-client -> print-serv TCP D=515 S=1023 Ack=3101688499 Seq=1505511646 Len=9 Win=24820 19 111.80868 lpq-client -> print-serv PRINTER C port=1023 \3bill\n ________________________________ 20 111.83771 print-serv -> lpq-client ETHER Type=0800 (IP), size = 132 bytes 20 111.83771 print-serv -> lpq-client IP D=128.113.002.002 S=128.113.000.001 LEN=118, ID=4088 20 111.83771 print-serv -> lpq-client TCP D=1023 S=515 Ack=1505511655 Seq=3101688499 Len=78 Win=65535 20 111.83771 print-serv -> lpq-client PRINTER R port=1023 Warning: bill is ________________________________ 21 111.83782 print-serv -> lpq-client ETHER Type=0800 (IP), size = 60 bytes 21 111.83782 print-serv -> lpq-client IP D=128.113.002.002 S=128.113.000.001 LEN=40, ID=4089 21 111.83782 print-serv -> lpq-client TCP D=1023 S=515 Fin Ack=1505511655 Seq=3101688577 Len=0 Win=65535 21 111.83782 print-serv -> lpq-client PRINTER R port=1023 ________________________________ 22 111.83786 lpq-client -> print-serv ETHER Type=0800 (IP), size = 54 bytes 22 111.83786 lpq-client -> print-serv IP D=128.113.000.001 S=128.113.002.002 LEN=40, ID=56018 22 111.83786 lpq-client -> print-serv TCP D=515 S=1023 Ack=3101688577 Seq=1505511655 Len=0 Win=24820 22 111.83786 lpq-client -> print-serv PRINTER C port=1023 ________________________________ 23 111.83787 lpq-client -> print-serv ETHER Type=0800 (IP), size = 54 bytes 23 111.83787 lpq-client -> print-serv IP D=128.113.000.001 S=128.113.002.002 LEN=40, ID=56019 23 111.83787 lpq-client -> print-serv TCP D=515 S=1023 Ack=3101688578 Seq=1505511655 Len=0 Win=24820 23 111.83787 lpq-client -> print-serv PRINTER C port=1023 ________________________________ 24 111.83851 lpq-client -> print-serv ETHER Type=0800 (IP), size = 54 bytes 24 111.83851 lpq-client -> print-serv IP D=128.113.000.001 S=128.113.002.002 LEN=40, ID=56020 24 111.83851 lpq-client -> print-serv TCP D=515 S=1023 Fin Ack=3101688578 Seq=1505511655 Len=0 Win=24820 24 111.83851 lpq-client -> print-serv PRINTER C port=1023 ________________________________ 25 111.83911 print-serv -> lpq-client ETHER Type=0800 (IP), size = 60 bytes 25 111.83911 print-serv -> lpq-client IP D=128.113.002.002 S=128.113.000.001 LEN=40, ID=4090 25 111.83911 print-serv -> lpq-client TCP D=1023 S=515 Ack=1505511656 Seq=3101688578 Len=0 Win=65534 25 111.83911 print-serv -> lpq-client PRINTER R port=1023 ________________________________ All I have to do is '/etc/rc.d/pf stop' on the print-server machine, and immediately these long delays will go away. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-stable@FreeBSD.ORG Fri Jul 28 01:58:03 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 35CAF16A4DD for ; Fri, 28 Jul 2006 01:58:03 +0000 (UTC) (envelope-from drosih@rpi.edu) Received: from smtp7.server.rpi.edu (smtp7.server.rpi.edu [128.113.2.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id A154B43D46 for ; Fri, 28 Jul 2006 01:58:02 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp7.server.rpi.edu (8.13.1/8.13.1) with ESMTP id k6S1vwUj004736 for ; Thu, 27 Jul 2006 21:58:00 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 27 Jul 2006 21:57:58 -0400 To: freebsd-stable@freebsd.org From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) Subject: Re: Weird problems with 'pf' (on both 5.x and 6.x) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 01:58:03 -0000 At 9:18 PM -0400 7/27/06, Garance A Drosihn wrote: >At 9:07 PM -0400 7/27/06, Garance A Drosihn wrote: >> >>But if I restart pf after adding these lines to pf.conf: >> >> # Allow all outgoing tcp and udp connections and keep state >> pass out quick proto { tcp, udp } all keep state >> >>then I have the problem where the second 'lpq' from a remote >>host will hang, if it is done right after the first one. > >The client-machine which is doing the lpq is a solaris >machine, so here is the 'snoop' output from that side >of things. It occurred to me that it might be more informative to see the transaction from the *freebsd* side of things, since that's the machine running pf! So, here is a similar set of two lpq's, as seen from the print-server side of the connection. It seems to be telling the same basic story, as far as I can tell. (316) santropez/root # tcpdump -vvvvX -r /tmp/gadchecks/all-060727.212311 host lpq-client reading from file /tmp/gadchecks/all-060727.212311, link-type EN10MB (Ethernet) 21:23:32.175093 IP (tos 0x0, ttl 63, id 53775, offset 0, flags [DF], proto: TCP (6), length: 48) lpq-client.1023 > print-serv.printer: S, cksum 0x6b2c (correct), 2119630748:2119630748(0) win 24820 0x0000: 4500 0030 d20f 4000 3f06 36af 8071 1985 E..0..@.?.6..q.. 0x0010: 8071 18a2 03ff 0203 7e56 ff9c 0000 0000 .q......~V...... 0x0020: 7002 60f4 6b2c 0000 0101 0402 0204 05b4 p.`.k,.......... 21:23:32.175205 IP (tos 0x0, ttl 64, id 4488, offset 0, flags [DF], proto: TCP (6), length: 48) print-serv.printer > lpq-client.1023: S, cksum 0x0bfa (correct), 2140553600:2140553600(0) ack 2119630749 win 65535 0x0000: 4500 0030 1188 4000 4006 f636 8071 18a2 E..0..@.@..6.q.. 0x0010: 8071 1985 0203 03ff 7f96 4180 7e56 ff9d .q........A.~V.. 0x0020: 7012 ffff 0bfa 0000 0204 05b4 0402 0000 p............... 21:23:32.175787 IP (tos 0x0, ttl 63, id 53776, offset 0, flags [DF], proto: TCP (6), length: 40) lpq-client.1023 > print-serv.printer: ., cksum 0xd6c8 (correct), 1:1(0) ack 1 win 24820 0x0000: 4500 0028 d210 4000 3f06 36b6 8071 1985 E..(..@.?.6..q.. 0x0010: 8071 18a2 03ff 0203 7e56 ff9d 7f96 4181 .q......~V....A. 0x0020: 5010 60f4 d6c8 0000 5555 5555 5555 P.`.....UUUUUU 21:23:32.175935 IP (tos 0x0, ttl 63, id 53777, offset 0, flags [DF], proto: TCP (6), length: 49) lpq-client.1023 > print-serv.printer: P, cksum 0xc80d (correct), 1:10(9) ack 1 win 24820 0x0000: 4500 0031 d211 4000 3f06 36ac 8071 1985 E..1..@.?.6..q.. 0x0010: 8071 18a2 03ff 0203 7e56 ff9d 7f96 4181 .q......~V....A. 0x0020: 5018 60f4 c80d 0000 0370 6269 6c6c 3264 P.`......bill 0x0030: 0a . 21:23:32.204946 IP (tos 0x0, ttl 64, id 4526, offset 0, flags [DF], proto: TCP (6), length: 118) print-serv.printer > lpq-client.1023: P, cksum 0x5bcb (correct), 1:79(78) ack 10 win 65535 0x0000: 4500 0076 11ae 4000 4006 f5ca 8071 18a2 E..v..@.@....q.. 0x0010: 8071 1985 0203 03ff 7f96 4181 7e56 ffa6 .q........A.~V.. 0x0020: 5018 ffff 5bcb 0000 5761 726e 696e 673a P...[...Warning: 0x0030: 2070 6269 6c6c 3264 2069 7320 646f 776e .bill.is.down 0x0040: 3a20 5468 6973 2071 7565 7565 2069 7320 :.This.queue.is. 0x0050: 666f 7220 4761 7261 6e63 6520 7465 7374 for.Garance.test 0x0060: 696e 672e 2073 742f 3678 0a6e 6f20 656e ing..st/6x.no.en 0x0070: 7472 6965 730a tries. 21:23:32.204988 IP (tos 0x0, ttl 64, id 4527, offset 0, flags [DF], proto: TCP (6), length: 40) print-serv.printer > lpq-client.1023: F, cksum 0x3765 (correct), 79:79(0) ack 10 win 65535 0x0000: 4500 0028 11af 4000 4006 f617 8071 18a2 E..(..@.@....q.. 0x0010: 8071 1985 0203 03ff 7f96 41cf 7e56 ffa6 .q........A.~V.. 0x0020: 5011 ffff 3765 0000 P...7e.. 21:23:32.205701 IP (tos 0x0, ttl 63, id 53778, offset 0, flags [DF], proto: TCP (6), length: 40) lpq-client.1023 > print-serv.printer: ., cksum 0xd671 (correct), 10:10(0) ack 79 win 24820 0x0000: 4500 0028 d212 4000 3f06 36b4 8071 1985 E..(..@.?.6..q.. 0x0010: 8071 18a2 03ff 0203 7e56 ffa6 7f96 41cf .q......~V....A. 0x0020: 5010 60f4 d671 0000 5555 5555 5555 P.`..q..UUUUUU 21:23:32.205755 IP (tos 0x0, ttl 63, id 53779, offset 0, flags [DF], proto: TCP (6), length: 40) lpq-client.1023 > print-serv.printer: ., cksum 0xd670 (correct), 10:10(0) ack 80 win 24820 0x0000: 4500 0028 d213 4000 3f06 36b3 8071 1985 E..(..@.?.6..q.. 0x0010: 8071 18a2 03ff 0203 7e56 ffa6 7f96 41d0 .q......~V....A. 0x0020: 5010 60f4 d670 0000 5555 5555 5555 P.`..p..UUUUUU 21:23:32.206880 IP (tos 0x0, ttl 63, id 53780, offset 0, flags [DF], proto: TCP (6), length: 40) lpq-client.1023 > print-serv.printer: F, cksum 0xd66f (correct), 10:10(0) ack 80 win 24820 0x0000: 4500 0028 d214 4000 3f06 36b2 8071 1985 E..(..@.?.6..q.. 0x0010: 8071 18a2 03ff 0203 7e56 ffa6 7f96 41d0 .q......~V....A. 0x0020: 5011 60f4 d66f 0000 5555 5555 5555 P.`..o..UUUUUU 21:23:32.206918 IP (tos 0x0, ttl 64, id 4528, offset 0, flags [DF], proto: TCP (6), length: 40) print-serv.printer > lpq-client.1023: ., cksum 0x3765 (correct), 80:80(0) ack 11 win 65534 0x0000: 4500 0028 11b0 4000 4006 f616 8071 18a2 E..(..@.@....q.. 0x0010: 8071 1985 0203 03ff 7f96 41d0 7e56 ffa7 .q........A.~V.. 0x0020: 5010 fffe 3765 0000 P...7e.. 21:23:34.252791 IP (tos 0x0, ttl 63, id 53781, offset 0, flags [DF], proto: TCP (6), length: 48) lpq-client.1023 > print-serv.printer: S, cksum 0x2329 (correct), 2120304533:2120304533(0) win 24820 0x0000: 4500 0030 d215 4000 3f06 36a9 8071 1985 E..0..@.?.6..q.. 0x0010: 8071 18a2 03ff 0203 7e61 4795 0000 0000 .q......~aG..... 0x0020: 7002 60f4 2329 0000 0101 0402 0204 05b4 p.`.#).......... 21:23:37.617105 IP (tos 0x0, ttl 63, id 53782, offset 0, flags [DF], proto: TCP (6), length: 48) lpq-client.1023 > print-serv.printer: S, cksum 0x2329 (correct), 2120304533:2120304533(0) win 24820 0x0000: 4500 0030 d216 4000 3f06 36a8 8071 1985 E..0..@.?.6..q.. 0x0010: 8071 18a2 03ff 0203 7e61 4795 0000 0000 .q......~aG..... 0x0020: 7002 60f4 2329 0000 0101 0402 0204 05b4 p.`.#).......... 21:23:44.367128 IP (tos 0x0, ttl 63, id 53783, offset 0, flags [DF], proto: TCP (6), length: 48) lpq-client.1023 > print-serv.printer: S, cksum 0x2329 (correct), 2120304533:2120304533(0) win 24820 0x0000: 4500 0030 d217 4000 3f06 36a7 8071 1985 E..0..@.?.6..q.. 0x0010: 8071 18a2 03ff 0203 7e61 4795 0000 0000 .q......~aG..... 0x0020: 7002 60f4 2329 0000 0101 0402 0204 05b4 p.`.#).......... 21:23:57.867184 IP (tos 0x0, ttl 63, id 53784, offset 0, flags [DF], proto: TCP (6), length: 48) lpq-client.1023 > print-serv.printer: S, cksum 0x2329 (correct), 2120304533:2120304533(0) win 24820 0x0000: 4500 0030 d218 4000 3f06 36a6 8071 1985 E..0..@.?.6..q.. 0x0010: 8071 18a2 03ff 0203 7e61 4795 0000 0000 .q......~aG..... 0x0020: 7002 60f4 2329 0000 0101 0402 0204 05b4 p.`.#).......... 21:24:24.867224 IP (tos 0x0, ttl 63, id 53785, offset 0, flags [DF], proto: TCP (6), length: 48) lpq-client.1023 > print-serv.printer: S, cksum 0x2329 (correct), 2120304533:2120304533(0) win 24820 0x0000: 4500 0030 d219 4000 3f06 36a5 8071 1985 E..0..@.?.6..q.. 0x0010: 8071 18a2 03ff 0203 7e61 4795 0000 0000 .q......~aG..... 0x0020: 7002 60f4 2329 0000 0101 0402 0204 05b4 p.`.#).......... 21:25:18.867322 IP (tos 0x0, ttl 63, id 53786, offset 0, flags [DF], proto: TCP (6), length: 48) lpq-client.1023 > print-serv.printer: S, cksum 0x2329 (correct), 2120304533:2120304533(0) win 24820 0x0000: 4500 0030 d21a 4000 3f06 36a4 8071 1985 E..0..@.?.6..q.. 0x0010: 8071 18a2 03ff 0203 7e61 4795 0000 0000 .q......~aG..... 0x0020: 7002 60f4 2329 0000 0101 0402 0204 05b4 p.`.#).......... 21:25:18.867426 IP (tos 0x0, ttl 64, id 4531, offset 0, flags [DF], proto: TCP (6), length: 48) print-serv.printer > lpq-client.1023: S, cksum 0x4f45 (correct), 933494308:933494308(0) ack 2120304534 win 65535 0x0000: 4500 0030 11b3 4000 4006 f60b 8071 18a2 E..0..@.@....q.. 0x0010: 8071 1985 0203 03ff 37a3 fe24 7e61 4796 .q......7..$~aG. 0x0020: 7012 ffff 4f45 0000 0204 05b4 0402 0000 p...OE.......... 21:25:18.868017 IP (tos 0x0, ttl 63, id 53787, offset 0, flags [DF], proto: TCP (6), length: 40) lpq-client.1023 > print-serv.printer: ., cksum 0x1a14 (correct), 1:1(0) ack 1 win 24820 0x0000: 4500 0028 d21b 4000 3f06 36ab 8071 1985 E..(..@.?.6..q.. 0x0010: 8071 18a2 03ff 0203 7e61 4796 37a3 fe25 .q......~aG.7..% 0x0020: 5010 60f4 1a14 0000 5555 5555 5555 P.`.....UUUUUU 21:25:18.868252 IP (tos 0x0, ttl 63, id 53788, offset 0, flags [DF], proto: TCP (6), length: 49) lpq-client.1023 > print-serv.printer: P, cksum 0x0b59 (correct), 1:10(9) ack 1 win 24820 0x0000: 4500 0031 d21c 4000 3f06 36a1 8071 1985 E..1..@.?.6..q.. 0x0010: 8071 18a2 03ff 0203 7e61 4796 37a3 fe25 .q......~aG.7..% 0x0020: 5018 60f4 0b59 0000 0370 6269 6c6c 3264 P.`..Y...bill 0x0030: 0a . 21:25:18.897042 IP (tos 0x0, ttl 64, id 4569, offset 0, flags [DF], proto: TCP (6), length: 118) print-serv.printer > lpq-client.1023: P, cksum 0x9f16 (correct), 1:79(78) ack 10 win 65535 0x0000: 4500 0076 11d9 4000 4006 f59f 8071 18a2 E..v..@.@....q.. 0x0010: 8071 1985 0203 03ff 37a3 fe25 7e61 479f .q......7..%~aG. 0x0020: 5018 ffff 9f16 0000 5761 726e 696e 673a P.......Warning: 0x0030: 2070 6269 6c6c 3264 2069 7320 646f 776e .bill.is.down 0x0040: 3a20 5468 6973 2071 7565 7565 2069 7320 :.This.queue.is. 0x0050: 666f 7220 4761 7261 6e63 6520 7465 7374 for.Garance.test 0x0060: 696e 672e 2073 742f 3678 0a6e 6f20 656e ing..st/6x.no.en 0x0070: 7472 6965 730a tries. 21:25:18.897085 IP (tos 0x0, ttl 64, id 4570, offset 0, flags [DF], proto: TCP (6), length: 40) print-serv.printer > lpq-client.1023: F, cksum 0x7ab0 (correct), 79:79(0) ack 10 win 65535 0x0000: 4500 0028 11da 4000 4006 f5ec 8071 18a2 E..(..@.@....q.. 0x0010: 8071 1985 0203 03ff 37a3 fe73 7e61 479f .q......7..s~aG. 0x0020: 5011 ffff 7ab0 0000 P...z... 21:25:18.897800 IP (tos 0x0, ttl 63, id 53789, offset 0, flags [DF], proto: TCP (6), length: 40) lpq-client.1023 > print-serv.printer: ., cksum 0x19bd (correct), 10:10(0) ack 79 win 24820 0x0000: 4500 0028 d21d 4000 3f06 36a9 8071 1985 E..(..@.?.6..q.. 0x0010: 8071 18a2 03ff 0203 7e61 479f 37a3 fe73 .q......~aG.7..s 0x0020: 5010 60f4 19bd 0000 5555 5555 5555 P.`.....UUUUUU 21:25:18.897853 IP (tos 0x0, ttl 63, id 53790, offset 0, flags [DF], proto: TCP (6), length: 40) lpq-client.1023 > print-serv.printer: ., cksum 0x19bc (correct), 10:10(0) ack 80 win 24820 0x0000: 4500 0028 d21e 4000 3f06 36a8 8071 1985 E..(..@.?.6..q.. 0x0010: 8071 18a2 03ff 0203 7e61 479f 37a3 fe74 .q......~aG.7..t 0x0020: 5010 60f4 19bc 0000 5555 5555 5555 P.`.....UUUUUU 21:25:18.899111 IP (tos 0x0, ttl 63, id 53791, offset 0, flags [DF], proto: TCP (6), length: 40) lpq-client.1023 > print-serv.printer: F, cksum 0x19bb (correct), 10:10(0) ack 80 win 24820 0x0000: 4500 0028 d21f 4000 3f06 36a7 8071 1985 E..(..@.?.6..q.. 0x0010: 8071 18a2 03ff 0203 7e61 479f 37a3 fe74 .q......~aG.7..t 0x0020: 5011 60f4 19bb 0000 5555 5555 5555 P.`.....UUUUUU 21:25:18.899149 IP (tos 0x0, ttl 64, id 4571, offset 0, flags [DF], proto: TCP (6), length: 40) print-serv.printer > lpq-client.1023: ., cksum 0x7ab0 (correct), 80:80(0) ack 11 win 65534 0x0000: 4500 0028 11db 4000 4006 f5eb 8071 18a2 E..(..@.@....q.. 0x0010: 8071 1985 0203 03ff 37a3 fe74 7e61 47a0 .q......7..t~aG. 0x0020: 5010 fffe 7ab0 0000 P...z... -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-stable@FreeBSD.ORG Fri Jul 28 06:51:17 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC21416A4E0 for ; Fri, 28 Jul 2006 06:51:17 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from kagate.punkt.de (kagate.punkt.de [217.29.33.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C1E943D49 for ; Fri, 28 Jul 2006 06:51:13 +0000 (GMT) (envelope-from hausen@punkt.de) Received: from hugo10.ka.punkt.de (hugo10.ka.punkt.de [10.0.0.110]) by kagate2.punkt.de with ESMTP id k6S6pC48008815 for ; Fri, 28 Jul 2006 08:51:12 +0200 (CEST) Received: from hugo10.ka.punkt.de (localhost [127.0.0.1]) by hugo10.ka.punkt.de (8.12.10/8.12.10) with ESMTP id k6S6pB6G070716; Fri, 28 Jul 2006 08:51:12 +0200 (CEST) (envelope-from ry93@hugo10.ka.punkt.de) Received: (from ry93@localhost) by hugo10.ka.punkt.de (8.12.10/8.12.10/Submit) id k6S6pBbW070715; Fri, 28 Jul 2006 08:51:11 +0200 (CEST) (envelope-from ry93) Date: Fri, 28 Jul 2006 08:51:11 +0200 From: "Patrick M. Hausen" To: "Arno J. Klaassen" Message-ID: <20060728065111.GA70610@hugo10.ka.punkt.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.10i Cc: wpaul@windriver.com, freebsd-stable@freebsd.org Subject: Re: nfs-client reveals MFC-if_re-probs (or vice-versa) ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 06:51:17 -0000 Good morning! On Thu, Jul 27, 2006 at 09:47:42PM +0200, Arno J. Klaassen wrote: > - I 'mount -o nfsv3,intr,noconn,-r=32768,-w=32768 > <-stable-server>:/files/bsd /files/bsd ' Does nfsv3 default to TCP? If not have you tried lowering your blocksite to, say, 8192? Regards, Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Vorholzstr. 25 Tel. 0721 9109 -0 Fax: -100 76137 Karlsruhe http://punkt.de From owner-freebsd-stable@FreeBSD.ORG Fri Jul 28 11:15:24 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7217216A4DA for ; Fri, 28 Jul 2006 11:15:24 +0000 (UTC) (envelope-from johan@stromnet.org) Received: from pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 438F043D7F for ; Fri, 28 Jul 2006 11:15:11 +0000 (GMT) (envelope-from johan@stromnet.org) Received: from elfi.stromnet.org (213.67.205.103) by pne-smtpout1-sn2.hy.skanova.net (7.2.075) id 44A2E86F005B8CA0 for freebsd-stable@freebsd.org; Fri, 28 Jul 2006 13:15:09 +0200 Received: from localhost (localhost [127.0.0.1]) by elfi.stromnet.org (Postfix) with ESMTP id C77AB61D77 for ; Fri, 28 Jul 2006 13:15:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at stromnet.org Received: from elfi.stromnet.org ([127.0.0.1]) by localhost (elfi.stromnet.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9h1yvHglCvh for ; Fri, 28 Jul 2006 13:15:04 +0200 (CEST) Received: from [IPv6:2001:16d8:ff20:2:211:24ff:fea2:8e01] (unknown [IPv6:2001:16d8:ff20:2:211:24ff:fea2:8e01]) by elfi.stromnet.org (Postfix) with ESMTP id EF47761D74 for ; Fri, 28 Jul 2006 13:15:03 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <44BBAF52.9080007@quip.cz> References: <8D08DDB6-6AC1-45B6-B2CE-08782F54968A@stromnet.org> <884C01BC-3E97-46EC-AA8B-E70C3931F3A4@stromnet.org> <36895211-2796-4213-B336-6279AB3AC3CB@stromnet.org> <20060713132357.Y61840@fledge.watson.org> <44B7EA39.4060509@quip.cz> <6.2.3.4.0.20060716185019.12a29240@64.7.153.2> <44BBAF52.9080007@quip.cz> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0B43BAB0-BBF0-4E2C-875D-6E1E00BAB1D4@stromnet.org> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Johan_Str=F6m?= Date: Fri, 28 Jul 2006 13:15:48 +0200 To: freebsd-stable@freebsd.org X-Mailer: Apple Mail (2.752.2) Subject: Re: ATA problems again ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 11:15:24 -0000 On 17 jul 2006, at 17.40, Miroslav Lachman wrote: > Mike Tancsa wrote: > [..] >> Install the smartmontools from >> /usr/ports/sysutils/smartmontools/ >> and post the output of >> smartctl -a /dev/ad8 > > smartmontools was previously installed and running as daemon > without any bad reports. > I can not run "smartctl -a /dev/ad8" now, because my server housing > provider replaced HDD with the new one and after an hour of > synchronization "ad8: FAILURE - device detached". So provider > replaced whole server, only ad4 is original piece of HW. > On new server synchronization was much faster then in previous > server (1:30 hour compared to 5 hours in previous server) - so I > think it was HW problem. > Now I am running stresstest with copying /usr/ports to another > partition in infinite loop. > I will post results later. (On bad server, test failed after about > 30 minutes. On another server the test is running fine second day, > so I think if disk will not fail after 1 day, problem is solved) > > At last - now I think this was not GEOM/gmirror related. I tried > remove ad8 provider from gmirror (gm0), boot up system from gm0 > with one provider (ad4) and test ad8 mounted separately - ad8 > failed again. Just got another one.. Jul 25 13:30:47 elfi kernel: ad4: FAILURE - device detached Jul 25 13:30:47 elfi kernel: subdisk4: detached Jul 25 13:30:47 elfi kernel: ad4: detached Jul 25 13:30:47 elfi kernel: GEOM_MIRROR: Device gm0s1: provider ad4s1 disconnected. Jul 25 13:30:47 elfi kernel: g_vfs_done():mirror/gm0s1f[READ (offset=46318008320, length=2048)]error = 6 Jul 25 13:30:47 elfi kernel: g_vfs_done():mirror/gm0s1f[READ (offset=77269614592, length=16384)]error = 6 6 days uptime when this occured... Both disks are tested with PowerMax without a single problem (same with smartctl), both SATA cables are new. So the only hwproblem that I cant rule out would be the mobo, but that is quite new too... Solutions? Try RELENG_6 as recommended earlier? Thanks Johan From owner-freebsd-stable@FreeBSD.ORG Fri Jul 28 11:24:25 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDD6216A4DD for ; Fri, 28 Jul 2006 11:24:25 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.21]) by mx1.FreeBSD.org (Postfix) with SMTP id 6989143D88 for ; Fri, 28 Jul 2006 11:24:19 +0000 (GMT) (envelope-from LoN_Kamikaze@gmx.de) Received: (qmail invoked by alias); 28 Jul 2006 11:24:17 -0000 Received: from p54A7F304.dip.t-dialin.net (EHLO [192.168.0.12]) [84.167.243.4] by mail.gmx.net (mp019) with SMTP; 28 Jul 2006 13:24:17 +0200 X-Authenticated: #5465401 Message-ID: <44C9F3D7.1000703@gmx.de> Date: Fri, 28 Jul 2006 13:24:07 +0200 From: "[LoN]Kamikaze" Organization: Lords of Nightmare User-Agent: Thunderbird 1.5.0.4 (X11/20060720) MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: /etc/rc.d/moused ignores moused_enable="NO" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 11:24:25 -0000 Just out of curiosity I'd like to know why and how the moused rc script ignores the moused_enable="NO" setting. From owner-freebsd-stable@FreeBSD.ORG Fri Jul 28 11:52:21 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B437016A4DD for ; Fri, 28 Jul 2006 11:52:21 +0000 (UTC) (envelope-from sw@gegenunendlich.de) Received: from mail.hamcom.de (mail2.hamcom.de [212.37.37.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42D7343D4C for ; Fri, 28 Jul 2006 11:52:21 +0000 (GMT) (envelope-from sw@gegenunendlich.de) Received: from adsl-dyn-88-208-147-24.heliweb.de ([88.208.147.24] helo=chikuku.dunkelkammer.void) by mail.hamcom.de with esmtp (Exim 4.60) (envelope-from ) id 1G6QtA-00031c-Dn for freebsd-stable@freebsd.org; Fri, 28 Jul 2006 13:52:20 +0200 Received: by chikuku.dunkelkammer.void (Postfix, from userid 1001) id 0EBA7BC75; Fri, 28 Jul 2006 13:52:20 +0200 (CEST) Date: Fri, 28 Jul 2006 13:52:19 +0200 From: Stefan Walter To: freebsd-stable@freebsd.org Message-ID: <20060728115219.GB28204@chikuku.dunkelkammer.void> References: <44C9F3D7.1000703@gmx.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dTy3Mrz/UPE2dbVg" Content-Disposition: inline In-Reply-To: <44C9F3D7.1000703@gmx.de> Organization: Infinity Approximation Task Force X-PGP-key: http://www.gegenunendlich.de/swalter-rsa.asc X-PGP-fingerprint: 85D8 6A49 22C7 6CD9 B011 5D6A 5691 111B 12B9 E0B3 User-Agent: Mutt/1.5.12-2006-07-14 Subject: Re: /etc/rc.d/moused ignores moused_enable="NO" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 11:52:21 -0000 --dTy3Mrz/UPE2dbVg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [LoN]Kamikaze, 28.07.06, 13:24h CEST: > Just out of curiosity I'd like to know why and how the moused rc script > ignores the moused_enable="NO" setting. It might be interesting to know how and why you come to think it does first, and what your configuration looks like (e.g. is your mouse connected via USB, PS/2 or serial cable). Regards, Stefan --dTy3Mrz/UPE2dbVg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iQGVAwUBRMn6claRERsSueCzAQKwKwwAgvMWk8gFzxnEopdmpSrmnj4ZfwDDbWSd k0OWfxjSCyKlpTUsvlse2Ic+0d90Rv4E+2MCWphlODrjsARNJlprUIfn/kf0w3+R e/Q4dT0SrKZU1qSw8vnqgWXhIyKOG6H269OaQ6DcmDpIh22RFbOvFlDVZqr6LAMh SSyM4Uppzkd26jfKgOtsgBV4rdLaE3Hi4RZZddo0pL8NrprLDw3xsjYjBUezHntj Rp5cY87/3vAi1O9YL3oL/yh/Js35rZnSyAdm4HvaxUvy9KueZMPBD27du+T62X9B wGcLQUru0dyQnFRZkGGmoPhl6yh2j3TS2y7hFgCp4IPQFkD/lpefqe0ZTN33qMPp zLoooSbJSEdxr0hqmWgMXEir2+QoReTKuoQ9FQFo/CuakUMW/gzXkFgFNu0n8j98 dZCRrOJDIGGXaifkOVovX7x5QKBJpVqqCXAK9Nl7NAM/Lnq9bxAha/qllmy3Opvb hEevuBPoJY2GfAunVxZp+GTwOi8Kx6QO =cTrC -----END PGP SIGNATURE----- --dTy3Mrz/UPE2dbVg-- From owner-freebsd-stable@FreeBSD.ORG Fri Jul 28 13:01:39 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA32C16A50A for ; Fri, 28 Jul 2006 13:01:39 +0000 (UTC) (envelope-from zkolic@sbb.co.yu) Received: from smtp2.sbb.co.yu (smtp2.sbb.co.yu [82.117.194.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C7CA43D46 for ; Fri, 28 Jul 2006 13:01:36 +0000 (GMT) (envelope-from zkolic@sbb.co.yu) Received: from faust.net (cable-87-116-181-151.dynamic.sbb.co.yu [87.116.181.151]) by smtp2.sbb.co.yu (8.13.7/8.13.7) with ESMTP id k6SD1Wd9005192 for ; Fri, 28 Jul 2006 15:01:32 +0200 Received: by faust.net (Postfix, from userid 1001) id B48DD1701C; Fri, 28 Jul 2006 15:02:05 +0200 (CEST) Date: Fri, 28 Jul 2006 15:02:05 +0200 From: Zoran Kolic To: freebsd-stable@freebsd.org Message-ID: <20060728130205.GA662@faust.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-SMTP-Vilter-Version: 1.3.2 X-SBB-Virus-Status: clean X-SBB-Spam-Score: 1.3 X-SBB-Spam-Level: XXX Subject: Re: Monitoring temperature with acpi (sysutils) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 13:01:39 -0000 Hi all! Does someone have any news about temperature monitoring for asus (or some other) gforce3 mobo? Mine is called k8n 250. 6.1, amd64. Zoran From owner-freebsd-stable@FreeBSD.ORG Fri Jul 28 13:37:13 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8708316A4DA for ; Fri, 28 Jul 2006 13:37:13 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from home.quip.cz (grimm.quip.cz [213.220.192.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C2D643D5D for ; Fri, 28 Jul 2006 13:37:09 +0000 (GMT) (envelope-from 000.fbsd@quip.cz) Received: from [192.168.1.2] (qwork.quip.test [192.168.1.2]) by home.quip.cz (Postfix) with ESMTP id 050EC56E7; Fri, 28 Jul 2006 15:37:06 +0200 (CEST) Message-ID: <44CA1302.2050600@quip.cz> Date: Fri, 28 Jul 2006 15:37:06 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cs, cz, en, en-us MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <8D08DDB6-6AC1-45B6-B2CE-08782F54968A@stromnet.org> <884C01BC-3E97-46EC-AA8B-E70C3931F3A4@stromnet.org> <36895211-2796-4213-B336-6279AB3AC3CB@stromnet.org> <20060713132357.Y61840@fledge.watson.org> <44B7EA39.4060509@quip.cz> <6.2.3.4.0.20060716185019.12a29240@64.7.153.2> <44BBAF52.9080007@quip.cz> <0B43BAB0-BBF0-4E2C-875D-6E1E00BAB1D4@stromnet.org> In-Reply-To: <0B43BAB0-BBF0-4E2C-875D-6E1E00BAB1D4@stromnet.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: =?ISO-8859-1?Q?Johan_Str=F6m?= Subject: Re: ATA problems again ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 13:37:13 -0000 Johan Ström wrote: [...] > On 17 jul 2006, at 17.40, Miroslav Lachman wrote: > >> Mike Tancsa wrote: >> [..] >> >>> Install the smartmontools from >>> /usr/ports/sysutils/smartmontools/ >>> and post the output of >>> smartctl -a /dev/ad8 >> >> >> smartmontools was previously installed and running as daemon without >> any bad reports. >> I can not run "smartctl -a /dev/ad8" now, because my server housing >> provider replaced HDD with the new one and after an hour of >> synchronization "ad8: FAILURE - device detached". So provider >> replaced whole server, only ad4 is original piece of HW. >> On new server synchronization was much faster then in previous server >> (1:30 hour compared to 5 hours in previous server) - so I think it >> was HW problem. >> Now I am running stresstest with copying /usr/ports to another >> partition in infinite loop. >> I will post results later. (On bad server, test failed after about 30 >> minutes. On another server the test is running fine second day, so I >> think if disk will not fail after 1 day, problem is solved) >> >> At last - now I think this was not GEOM/gmirror related. I tried >> remove ad8 provider from gmirror (gm0), boot up system from gm0 with >> one provider (ad4) and test ad8 mounted separately - ad8 failed again. > > > Just got another one.. > > Jul 25 13:30:47 elfi kernel: ad4: FAILURE - device detached > Jul 25 13:30:47 elfi kernel: subdisk4: detached > Jul 25 13:30:47 elfi kernel: ad4: detached > Jul 25 13:30:47 elfi kernel: GEOM_MIRROR: Device gm0s1: provider ad4s1 > disconnected. > Jul 25 13:30:47 elfi kernel: g_vfs_done():mirror/gm0s1f[READ > (offset=46318008320, length=2048)]error = 6 > Jul 25 13:30:47 elfi kernel: g_vfs_done():mirror/gm0s1f[READ > (offset=77269614592, length=16384)]error = 6 > > 6 days uptime when this occured... Both disks are tested with PowerMax > without a single problem (same with smartctl), both SATA cables are > new. So the only hwproblem that I cant rule out would be the mobo, but > that is quite new too... > > Solutions? Try RELENG_6 as recommended earlier? In my case, server (mobo) replacement solved the problem. In this time, I got same problem on the second server. :( You can try BIOS update first, then RELENG_6 (I do not thing it helps), at last - replace mobo. Please, send me info, if BIOS update solved your problem. Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Fri Jul 28 13:53:43 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F87F16A4DD; Fri, 28 Jul 2006 13:53:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id E671D43D45; Fri, 28 Jul 2006 13:53:42 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k6SDre2h086241; Fri, 28 Jul 2006 09:53:41 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-stable@freebsd.org Date: Fri, 28 Jul 2006 09:48:50 -0400 User-Agent: KMail/1.9.1 References: <44C63DFD.5040401@rogers.com> <44C85C4F.7030902@rogers.com> In-Reply-To: <44C85C4F.7030902@rogers.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607280948.51239.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [192.168.0.1]); Fri, 28 Jul 2006 09:53:42 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1624/Thu Jul 27 13:11:25 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: Mike Jakubik , stable@freebsd.org, Bruno Ducrot , Jiawei Ye , David Duchscher Subject: Re: Monitoring temperature with acpi (sysctls) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 13:53:43 -0000 On Thursday 27 July 2006 02:25, Mike Jakubik wrote: > Jiawei Ye wrote: > > On 7/27/06, Mike Jakubik wrote: > >> I don't want to spend $50 extra per system, just so i can read the > >> temperature, and not even use any of the IPMI functions. I need a simple > >> and scriptable way to get the values, acpi sysctls are ideal for this. > > What about using SMBus? Is it available on your system? xmbmon reads > > temperatures off the SMBus IIRC. > > I tried that, unfortunately it does not work. All i want to know is if > this a shortcoming of freebsd or the motherboard, if its the later, i > will contact the manufacturer. If ACPI doesn't include the sysctl's that's due to your BIOS, not FreeBSD. You can verify by doing an acpidump and seeing if you have any thermal zones listed in your ASL. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Jul 28 13:53:43 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F87F16A4DD; Fri, 28 Jul 2006 13:53:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id E671D43D45; Fri, 28 Jul 2006 13:53:42 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k6SDre2h086241; Fri, 28 Jul 2006 09:53:41 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-stable@freebsd.org Date: Fri, 28 Jul 2006 09:48:50 -0400 User-Agent: KMail/1.9.1 References: <44C63DFD.5040401@rogers.com> <44C85C4F.7030902@rogers.com> In-Reply-To: <44C85C4F.7030902@rogers.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607280948.51239.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [192.168.0.1]); Fri, 28 Jul 2006 09:53:42 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1624/Thu Jul 27 13:11:25 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: Mike Jakubik , stable@freebsd.org, Bruno Ducrot , Jiawei Ye , David Duchscher Subject: Re: Monitoring temperature with acpi (sysctls) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 13:53:43 -0000 On Thursday 27 July 2006 02:25, Mike Jakubik wrote: > Jiawei Ye wrote: > > On 7/27/06, Mike Jakubik wrote: > >> I don't want to spend $50 extra per system, just so i can read the > >> temperature, and not even use any of the IPMI functions. I need a simple > >> and scriptable way to get the values, acpi sysctls are ideal for this. > > What about using SMBus? Is it available on your system? xmbmon reads > > temperatures off the SMBus IIRC. > > I tried that, unfortunately it does not work. All i want to know is if > this a shortcoming of freebsd or the motherboard, if its the later, i > will contact the manufacturer. If ACPI doesn't include the sysctl's that's due to your BIOS, not FreeBSD. You can verify by doing an acpidump and seeing if you have any thermal zones listed in your ASL. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Jul 28 13:53:44 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C6D516A4DA for ; Fri, 28 Jul 2006 13:53:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id A344543D45 for ; Fri, 28 Jul 2006 13:53:43 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k6SDre2g086241; Fri, 28 Jul 2006 09:53:40 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-stable@freebsd.org Date: Fri, 28 Jul 2006 09:46:57 -0400 User-Agent: KMail/1.9.1 References: <44C52C20.6030104@intersonic.se> <44C52E57.8010906@datapipe.com> <44C5319B.3060508@intersonic.se> In-Reply-To: <44C5319B.3060508@intersonic.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607280946.58152.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [192.168.0.1]); Fri, 28 Jul 2006 09:53:41 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1624/Thu Jul 27 13:11:25 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: msaad@datapipe.com Subject: Re: 6-STABLE locks solid - current ok, why? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 13:53:44 -0000 On Monday 24 July 2006 16:46, Per olof Ljungmark wrote: > The 5300 have a battery backed up cache, I guess I should try to run the > box off the 5i to check. > > Have several 360/380 G1/2/3's here too and never saw this before. > > I did: > * Installed hw; iLO card + one Intel em0 + the 5300 > * Booted 6.1-REL CD, installed base system including ports tree and sources > * pkg_add -r cvsup-without-gui > * fetched 6-STABLE sources > * Edit the kernel config (took out 486/586, added SMP/APIC) > * rebuilt and installed world (I usually do this a few times over to > check for hardware problems) > * Installed postfix, that worked ok. > * Next app (don't remeber which one sorry) hung the box > * fetched 6-STABLE sources again > * rebuilt and installed world, worked fine > * tried again to complie apps, no joy. Hangs at random places, no error > messages, just locks. > * fetched 6-STABLE sources again > * rebuilt and installed world, worked fine > > and finally, > > fetched -CURRENT, rebuilt and now everything is just great. ACPI is enabled. > > Reason I'm running -STABE is that I expect this one to go into > production about the time 6.2 is released. When it hangs, can you break into ddb and get a coredump? (Break into the debugger and use 'panic' at the db> prompt.) You'll need DDB and KDB in your kernel config. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Jul 28 14:45:55 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A1B216A516 for ; Fri, 28 Jul 2006 14:45:55 +0000 (UTC) (envelope-from dominique.goncalves@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 039F443D8A for ; Fri, 28 Jul 2006 14:45:43 +0000 (GMT) (envelope-from dominique.goncalves@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so838864uge for ; Fri, 28 Jul 2006 07:45:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=R6aC+eWIh9KPc0KbclMddKviqXgfeN87Jh1yz6ADOfnwjV4xgHWP4abPAOczvE/1baZtj6DGlo7ZwShlIr/IK8f3OPgyi/uKyrRZLYz1cgRi4UEmnWSvkc4ON60EXzD8UO4xRcuKCmaT0jlm8hXAshLVEqBOh/0Kmkm6u/NdCsU= Received: by 10.78.180.15 with SMTP id c15mr206303huf; Fri, 28 Jul 2006 07:45:42 -0700 (PDT) Received: by 10.78.117.14 with HTTP; Fri, 28 Jul 2006 07:45:42 -0700 (PDT) Message-ID: <7daacbbe0607280745u2057170alc52162d341a89e48@mail.gmail.com> Date: Fri, 28 Jul 2006 16:45:42 +0200 From: "Dominique Goncalves" To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: "ifconfig: interface XX does not exist " on startup X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 14:45:55 -0000 Hi, I use a system with RELENG_6 (mergemaster is ok). And on startup, I can see some warnings like this: ifconfig: interface rl0 does not exist this warning appears for all my interfaces (rl0, rl1 and ral0), I guess I see these messages because my interfaces are renamed with ifconfig_rl0_name="net0" for example. /etc/pccard_ether: DEBUG: run_rc_command: evaluating pccard_ether_start(). ifconfig: interface rl0 does not exist /etc/rc.d/netif: DEBUG: run_rc_command: evaluating network_start(). ifconfig: interface rl0 does not exist extract of my /etc/rc.conf: ifconfig_rl0_name="net0" ifconfig_rl1_name="lan0" ifconfig_ral0_name="wifi0" ifconfig_net0="DHCP" ifconfig_lan0="192.168.0.254 netmask 255.255.255.0" ifconfig_wifi0="192.168.1.254 netmask 255.255.255.0 ssid BSDNetwork mode 11g mediaopt hostap" dmesg -a: http://djdomics.free.fr/FreeBSD/dmesg-a.txt BTW, my network works as expected. Thanks for your help. Regards. -- There's this old saying: "Give a man a fish, feed him for a day. Teach a man to fish, feed him for life." From owner-freebsd-stable@FreeBSD.ORG Fri Jul 28 14:51:45 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5232416A4E0; Fri, 28 Jul 2006 14:51:45 +0000 (UTC) (envelope-from spartak@aif.ru) Received: from mail.aif.ru (mail.aif.ru [87.245.132.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0495443D8F; Fri, 28 Jul 2006 14:51:31 +0000 (GMT) (envelope-from spartak@aif.ru) Received: from spartak.intranet ([192.168.71.10]) by mail.aif.ru with esmtps (TLSv1:AES256-SHA:256) (Exim 4.61 (FreeBSD)) (envelope-from ) id 1G6TgY-000IFL-Fz; Fri, 28 Jul 2006 18:51:30 +0400 Message-ID: <44CA2471.5080406@aif.ru> Date: Fri, 28 Jul 2006 18:51:29 +0400 From: Spartak Radchenko User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 References: <44C63DFD.5040401@rogers.com> <44C85C4F.7030902@rogers.com> <200607280948.51239.jhb@freebsd.org> In-Reply-To: <200607280948.51239.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.4 AWL AWL: From: address is in the auto white-list Cc: freebsd-stable@freebsd.org, John Baldwin Subject: Re: Monitoring temperature with acpi (sysctls) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 14:51:45 -0000 John Baldwin ?????: > If ACPI doesn't include the sysctl's that's due to your BIOS, not FreeBSD. > You can verify by doing an acpidump and seeing if you have any thermal > zones listed in your ASL. What if there is a thermal zone, but sysctl returns meaningless numbers? router# sysctl hw.acpi.thermal hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.tz0.temperature: -257.-1C 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: 50.0C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 60.0C hw.acpi.thermal.tz0._ACx: 50.0C -1 -1 -1 -1 -1 -1 -1 -1 -1 If I understand it correctly, the current temperature is -257C, or 16 degrees from absolute zero. Motherboard is Via MS8000. -- Spartak Radchenko SVR1-RIPE From owner-freebsd-stable@FreeBSD.ORG Fri Jul 28 15:24:54 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6A68A16A4E8 for ; Fri, 28 Jul 2006 15:24:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id E428543DC7 for ; Fri, 28 Jul 2006 15:24:29 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k6SFNslB086837; Fri, 28 Jul 2006 11:23:54 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Spartak Radchenko Date: Fri, 28 Jul 2006 11:14:21 -0400 User-Agent: KMail/1.9.1 References: <44C63DFD.5040401@rogers.com> <200607280948.51239.jhb@freebsd.org> <44CA2471.5080406@aif.ru> In-Reply-To: <44CA2471.5080406@aif.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607281114.22512.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 28 Jul 2006 11:23:54 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1624/Thu Jul 27 13:11:25 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: freebsd-stable@freebsd.org Subject: Re: Monitoring temperature with acpi (sysctls) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 15:24:54 -0000 On Friday 28 July 2006 10:51, Spartak Radchenko wrote: > John Baldwin ?????: > > If ACPI doesn't include the sysctl's that's due to your BIOS, not FreeBSD. > > You can verify by doing an acpidump and seeing if you have any thermal > > zones listed in your ASL. > What if there is a thermal zone, but sysctl returns meaningless numbers? > > router# sysctl hw.acpi.thermal > hw.acpi.thermal.min_runtime: 0 > hw.acpi.thermal.polling_rate: 10 > hw.acpi.thermal.tz0.temperature: -257.-1C > 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: 50.0C > hw.acpi.thermal.tz0._HOT: -1 > hw.acpi.thermal.tz0._CRT: 60.0C > hw.acpi.thermal.tz0._ACx: 50.0C -1 -1 -1 -1 -1 -1 -1 -1 -1 > > If I understand it correctly, the current temperature is -257C, or 16 > degrees from absolute zero. > Motherboard is Via MS8000. Well, that means your BIOS has a different sort of issue. It probably has a bogus _TMP method. That's still going to be your BIOS' fault. The temperature value is defined in the standard to be in units of .1 K. So a raw value of 160 would give 16.0 K, or the value you are seeing. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Jul 28 15:34:09 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A284616A4DD for ; Fri, 28 Jul 2006 15:34:09 +0000 (UTC) (envelope-from sean-freebsd@farley.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C70243D76 for ; Fri, 28 Jul 2006 15:34:09 +0000 (GMT) (envelope-from sean-freebsd@farley.org) Received: from thor.farley.org (thor.farley.org [IPv6:2001:470:1f01:290:1::5]) by mail.farley.org (8.13.4/8.13.1) with ESMTP id k6SFdZ3o063902; Fri, 28 Jul 2006 10:39:35 -0500 (CDT) (envelope-from sean-freebsd@farley.org) Date: Fri, 28 Jul 2006 10:34:03 -0500 (CDT) From: "Sean C. Farley" To: "[LoN]Kamikaze" In-Reply-To: <44C9F3D7.1000703@gmx.de> Message-ID: <20060728103235.P82732@thor.farley.org> References: <44C9F3D7.1000703@gmx.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: /etc/rc.d/moused ignores moused_enable="NO" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 15:34:09 -0000 On Fri, 28 Jul 2006, [LoN]Kamikaze wrote: > Just out of curiosity I'd like to know why and how the moused rc > script ignores the moused_enable="NO" setting. Do you also have moused_nondefault_enable set to "NO"? This is assuming you have a USB mouse. Sean -- sean-freebsd@farley.org From owner-freebsd-stable@FreeBSD.ORG Fri Jul 28 15:35:21 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C88B916A4DA for ; Fri, 28 Jul 2006 15:35:21 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2021443D76 for ; Fri, 28 Jul 2006 15:35:20 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (felopi@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id k6SFZDJ0086198 for ; Fri, 28 Jul 2006 17:35:18 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id k6SFZDGS086197; Fri, 28 Jul 2006 17:35:13 +0200 (CEST) (envelope-from olli) Date: Fri, 28 Jul 2006 17:35:13 +0200 (CEST) Message-Id: <200607281535.k6SFZDGS086197@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG In-Reply-To: <44CA2471.5080406@aif.ru> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.0-20051224 ("Ronay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Fri, 28 Jul 2006 17:35:19 +0200 (CEST) Cc: Subject: Re: Monitoring temperature with acpi (sysctls) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 15:35:21 -0000 Spartak Radchenko wrote: > router# sysctl hw.acpi.thermal > [...] > hw.acpi.thermal.tz0.temperature: -257.-1C > > If I understand it correctly, the current temperature is -257C, or 16 > degrees from absolute zero. > Motherboard is Via MS8000. Now that's _really_ cool. What kind of cooling equipment do you have, and how much did it cost? I need that stuff, too ... probably enables you to overclock to 10 GHz or something ... SCRN :-) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "... there are two ways of constructing a software design: One way is to make it so simple that there are _obviously_ no deficiencies and the other way is to make it so complicated that there are no _obvious_ deficiencies." -- C.A.R. Hoare, ACM Turing Award Lecture, 1980 From owner-freebsd-stable@FreeBSD.ORG Fri Jul 28 15:59:11 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 105E716A4E5 for ; Fri, 28 Jul 2006 15:59:11 +0000 (UTC) (envelope-from kirk@strauser.com) Received: from kanga.honeypot.net (kanga.honeypot.net [208.162.254.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7925343D45 for ; Fri, 28 Jul 2006 15:59:10 +0000 (GMT) (envelope-from kirk@strauser.com) Received: from localhost (localhost [127.0.0.1]) by kanga.honeypot.net (Postfix) with ESMTP id 5F43396816 for ; Fri, 28 Jul 2006 10:59:09 -0500 (CDT) X-Virus-Scanned: amavisd-new at honeypot.net Received: from kanga.honeypot.net ([127.0.0.1]) by localhost (kanga.honeypot.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J+lBO4B6EsAY for ; Fri, 28 Jul 2006 10:59:07 -0500 (CDT) Received: from janus.daycos.com (outbound.daycos.com [204.26.70.70]) (using TLSv1 with cipher EXP1024-RC4-SHA (56/128 bits)) (No client certificate requested) by kanga.honeypot.net (Postfix) with ESMTP id 0D2B2959AB for ; Fri, 28 Jul 2006 10:59:06 -0500 (CDT) From: Kirk Strauser To: freebsd-stable@freebsd.org Date: Fri, 28 Jul 2006 10:59:03 -0500 User-Agent: KMail/1.9.1 References: <20060716091925.GM32624@deviant.kiev.zoral.com.ua> In-Reply-To: X-Face: T+/_{qmjgbosI0J/e83I~w[&VF'w)!((xEpj///^bA/6?jHHS?nq+T8_+`nh"WnEWCWG, \}]Y2$)) =?utf-8?q?vLVz4ACChrEcb=7DCO=5EtYmMG=5C=0A=09ts=2Em=3F=5B7=5B6OwE*dAJ*9f+m?= =?utf-8?q?X=2E7R32qeN=5EDJ=5C?=(k@evW?IRQCy.^ MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607281059.04168.kirk@strauser.com> Subject: Ports via CVS? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 15:59:11 -0000 On Sunday 16 July 2006 4:47 am, Mark Knight wrote: > No; I was fast asleep! I think the panic happened while executing a > cron job that does a "cvs update" in /usr/ports. The same job ran > successfully every morning for the preceding 48 days. On an unrelated note, do you use CVS to synchronize your ports tree with FreeBSD's copy, and if so, why not cvsup or portsnap instead? I also use rsync to lock multiple machines on my LAN to a "master" ports and src server - something you might consider if you're using CVS to manage local synchronization. -- Kirk Strauser From owner-freebsd-stable@FreeBSD.ORG Fri Jul 28 15:59:44 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE7BA16A4DA for ; Fri, 28 Jul 2006 15:59:44 +0000 (UTC) (envelope-from karagodov@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by mx1.FreeBSD.org (Postfix) with ESMTP id D23CF43D5D for ; Fri, 28 Jul 2006 15:59:39 +0000 (GMT) (envelope-from karagodov@gmail.com) Received: by py-out-1112.google.com with SMTP id b36so569997pyb for ; Fri, 28 Jul 2006 08:59:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=WdLWvgimDxhIGJJAY+GUBp4x7s6z/yWqIQyhLFWj/4PuOvxiOcVIDUj/cYoMFkYQRY3EzUKv68hZKG+KUtylbdtT98A7XqQ59yXrVRwJwxZSCcaByOunN3/GtfhSaAuWqBSFgCVsILmCTBKVYoEzx7p9l1jgSXBK/BznDkDV4JQ= Received: by 10.35.78.13 with SMTP id f13mr14621224pyl; Fri, 28 Jul 2006 08:59:32 -0700 (PDT) Received: by 10.35.66.6 with HTTP; Fri, 28 Jul 2006 08:59:32 -0700 (PDT) Message-ID: Date: Fri, 28 Jul 2006 19:59:32 +0400 From: "Alexey Karagodov" To: freebsd-stable@freebsd.org In-Reply-To: <200607281535.k6SFZDGS086197@lurza.secnetix.de> MIME-Version: 1.0 References: <44CA2471.5080406@aif.ru> <200607281535.k6SFZDGS086197@lurza.secnetix.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Monitoring temperature with acpi (sysctls) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 15:59:44 -0000 yeeeh, me too need this cooling stuff! :) please, tell me, where to find info about ACPI in FreeBSD on E7520 chip-set my MB is SuperMicro X6-DH8XG2 thanx ... 2006/7/28, Oliver Fromme : > > Spartak Radchenko wrote: > > router# sysctl hw.acpi.thermal > > [...] > > hw.acpi.thermal.tz0.temperature: -257.-1C > > > > If I understand it correctly, the current temperature is -257C, or 16 > > degrees from absolute zero. > > Motherboard is Via MS8000. > > Now that's _really_ cool. What kind of cooling equipment > do you have, and how much did it cost? I need that stuff, > too ... probably enables you to overclock to 10 GHz or > something ... > > SCRN :-) > > Best regards > Oliver > > -- > Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing > Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd > Any opinions expressed in this message may be personal to the author > and may not necessarily reflect the opinions of secnetix in any way. > > "... there are two ways of constructing a software design: One way > is to make it so simple that there are _obviously_ no deficiencies and > the other way is to make it so complicated that there are no _obvious_ > deficiencies." -- C.A.R. Hoare, ACM Turing Award Lecture, 1980 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Fri Jul 28 16:03:39 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D97116A4FD for ; Fri, 28 Jul 2006 16:03:39 +0000 (UTC) (envelope-from kirk@strauser.com) Received: from kanga.honeypot.net (kanga.honeypot.net [208.162.254.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id C544B43DD0 for ; Fri, 28 Jul 2006 16:03:16 +0000 (GMT) (envelope-from kirk@strauser.com) Received: from localhost (localhost [127.0.0.1]) by kanga.honeypot.net (Postfix) with ESMTP id 6846996816 for ; Fri, 28 Jul 2006 11:03:15 -0500 (CDT) X-Virus-Scanned: amavisd-new at honeypot.net Received: from kanga.honeypot.net ([127.0.0.1]) by localhost (kanga.honeypot.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2DDIwgecYyX for ; Fri, 28 Jul 2006 11:03:13 -0500 (CDT) Received: from janus.daycos.com (outbound.daycos.com [204.26.70.70]) (using TLSv1 with cipher EXP1024-RC4-SHA (56/128 bits)) (No client certificate requested) by kanga.honeypot.net (Postfix) with ESMTP id 2ECB296772 for ; Fri, 28 Jul 2006 11:03:13 -0500 (CDT) From: Kirk Strauser To: freebsd-stable@freebsd.org Date: Fri, 28 Jul 2006 11:03:07 -0500 User-Agent: KMail/1.9.1 References: <20060718152306.X36995@godot.imp.ch> <7.0.1.0.2.20060719112609.0abfb010@tellurian.com> <20060719182732.D36995@godot.imp.ch> In-Reply-To: <20060719182732.D36995@godot.imp.ch> X-Face: T+/_{qmjgbosI0J/e83I~w[&VF'w)!((xEpj///^bA/6?jHHS?nq+T8_+`nh"WnEWCWG, \}]Y2$)) =?utf-8?q?vLVz4ACChrEcb=7DCO=5EtYmMG=5C=0A=09ts=2Em=3F=5B7=5B6OwE*dAJ*9f+m?= =?utf-8?q?X=2E7R32qeN=5EDJ=5C?=(k@evW?IRQCy.^ MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1169502.kIzgdrJC3c"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200607281103.11666.kirk@strauser.com> Subject: Re: Please confirm: top(1) cpu time broken on FreeBSD 6.1 (RELEASE/STABLE) SMP ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 16:03:39 -0000 --nextPart1169502.kIzgdrJC3c Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 19 July 2006 11:28 am, Martin Blapp wrote: > Off course this is a solution, but I don't like it. On a untuned, > unmodified, unpatched system top(1) should display the correct values > IMHO.=20 I agree. I think it should show the percentage used of *available* CPUs,=20 not every one present. =2D-=20 Kirk Strauser --nextPart1169502.kIzgdrJC3c Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iD8DBQBEyjU/5sRg+Y0CpvERAvr9AJ9/Mv9DAZK6QeGgGYEVNcqLlnYgRQCeJaND z5JGrJYn48VaK2ybuq4pWdo= =1FZj -----END PGP SIGNATURE----- --nextPart1169502.kIzgdrJC3c-- From owner-freebsd-stable@FreeBSD.ORG Fri Jul 28 18:44:41 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E7D316A4DE for ; Fri, 28 Jul 2006 18:44:41 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: from smtpout09-04.prod.mesa1.secureserver.net (smtpout09-04.prod.mesa1.secureserver.net [64.202.165.17]) by mx1.FreeBSD.org (Postfix) with SMTP id 7547543D5A for ; Fri, 28 Jul 2006 18:44:40 +0000 (GMT) (envelope-from Stephen.Clark@seclark.us) Received: (qmail 17584 invoked from network); 28 Jul 2006 18:44:39 -0000 Received: from unknown (24.144.77.138) by smtpout09-04.prod.mesa1.secureserver.net (64.202.165.17) with ESMTP; 28 Jul 2006 18:44:39 -0000 Message-ID: <44CA5B16.2040508@seclark.us> Date: Fri, 28 Jul 2006 14:44:38 -0400 From: Stephen Clark User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22smp i686; en-US; m18) Gecko/20010110 Netscape6/6.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: 6.1 smp kernel on uniprocessor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Stephen.Clark@seclark.us List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 18:44:41 -0000 Hi list, Should a 6.1 smp compiled kernel run Ok on a uniprocessor? We ship both single core and dual core systems and would like to use only one kernel. Thanks, Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-stable@FreeBSD.ORG Fri Jul 28 18:51:50 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 712B916A4DA for ; Fri, 28 Jul 2006 18:51:50 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFB3243D55 for ; Fri, 28 Jul 2006 18:51:49 +0000 (GMT) (envelope-from killing@multiplay.co.uk) Received: from vader ([212.135.219.179]) by multiplay.co.uk (multiplay.co.uk [85.236.96.23]) (MDaemon PRO v9.0.1) with ESMTP id md50002825933.msg for ; Fri, 28 Jul 2006 19:51:51 +0100 Message-ID: <0b0201c6b276$d63d6270$b3db87d4@multiplay.co.uk> From: "Steven Hartland" To: References: <44CA5B16.2040508@seclark.us> Date: Fri, 28 Jul 2006 19:51:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Processed: multiplay.co.uk, Fri, 28 Jul 2006 19:51:51 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 212.135.219.179 X-Return-Path: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@freebsd.org X-MDAV-Processed: multiplay.co.uk, Fri, 28 Jul 2006 19:51:51 +0100 Subject: Re: 6.1 smp kernel on uniprocessor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 18:51:50 -0000 Stephen Clark wrote: > Should a 6.1 smp compiled kernel run Ok on a uniprocessor? > > We ship both single core and dual core systems and would like to use > only one > kernel. Yes is should although you might see some performance loss. Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Fri Jul 28 18:55:04 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 504BB16A4DA for ; Fri, 28 Jul 2006 18:55:04 +0000 (UTC) (envelope-from oberman@es.net) Received: from postal4.es.net (postal4.es.net [198.124.252.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id D9BAA43D49 for ; Fri, 28 Jul 2006 18:55:03 +0000 (GMT) (envelope-from 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 GZF06403; Fri, 28 Jul 2006 11:55:03 -0700 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 126EA45053; Fri, 28 Jul 2006 11:55:02 -0700 (PDT) To: Stephen.Clark@seclark.us In-reply-to: Your message of "Fri, 28 Jul 2006 14:44:38 EDT." <44CA5B16.2040508@seclark.us> Date: Fri, 28 Jul 2006 11:55:02 -0700 From: "Kevin Oberman" Message-Id: <20060728185502.126EA45053@ptavv.es.net> Cc: freebsd-stable@freebsd.org Subject: Re: 6.1 smp kernel on uniprocessor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 18:55:04 -0000 > Date: Fri, 28 Jul 2006 14:44:38 -0400 > From: Stephen Clark > Sender: owner-freebsd-stable@freebsd.org > > Hi list, > > Should a 6.1 smp compiled kernel run Ok on a uniprocessor? > > We ship both single core and dual core systems and would like to use > only one > kernel. It should run on a uniprocessor just fine, but I believe that there will be a performance penalty as and SMP kernel does additional work for synchronization that is not needed on single CPUs. -- 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 From owner-freebsd-stable@FreeBSD.ORG Fri Jul 28 19:03:43 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7141116A4DA for ; Fri, 28 Jul 2006 19:03:43 +0000 (UTC) (envelope-from mike@jellydonut.org) Received: from mail.secureworks.net (mail.secureworks.net [65.114.32.155]) by mx1.FreeBSD.org (Postfix) with SMTP id CE8C943D46 for ; Fri, 28 Jul 2006 19:03:42 +0000 (GMT) (envelope-from mike@jellydonut.org) Received: (qmail 98439 invoked from network); 28 Jul 2006 19:03:41 -0000 Received: from unknown (HELO ?192.168.14.135?) (63.239.86.253) by 0 with SMTP; 28 Jul 2006 19:03:41 -0000 Message-ID: <44CA5F8D.2070609@jellydonut.org> Date: Fri, 28 Jul 2006 15:03:41 -0400 From: Michael Proto User-Agent: Thunderbird 1.5.0.4 (X11/20060627) MIME-Version: 1.0 To: Don Wilde References: <200607271822.k6RIMHp2097311@crimson.hydrus.org.uk> <200607272244.13115.max@love2party.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: iwi(4) in RELENG_6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 19:03:43 -0000 Don Wilde wrote: >> Okay, I've gotten it working with all encryption off (raw DHCP). All the >> nasty messages went away, so I'll see what's changed in the ifconfig >> options. >> >> ifconfig_iwi0="DHCP ssid rewired channel 11 authmode shared weptxkey 1 >> wepmode on wepkey 0x1234567890" >> >> Can anybody spot it off the top? >> > > By removing the hardwired 'channel 11 authmode shared' from both sides, I > have been able to connect successfully with WEP authentication. > Just a note (and someone please correct me if I'm wrong), but setting the channel in the client's ifconfig statement is invalid in BSS mode-- it will pull the appropriate channel from the AP during the association. -Proto From owner-freebsd-stable@FreeBSD.ORG Fri Jul 28 19:30:56 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3769F16A4DD for ; Fri, 28 Jul 2006 19:30:56 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [213.238.47.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE0ED43D5C for ; Fri, 28 Jul 2006 19:30:45 +0000 (GMT) (envelope-from stb@lassitu.de) Received: (from stb@koef.zs64.net) (authenticated) by koef.zs64.net (8.13.7/8.13.7) with ESMTP id k6SJUVtw008752 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 28 Jul 2006 21:30:42 +0200 (CEST) (envelope-from stb@lassitu.de) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Stefan Bethke Date: Fri, 28 Jul 2006 21:30:31 +0200 To: Garance A Drosihn X-Mailer: Apple Mail (2.752.2) Cc: freebsd-stable@freebsd.org Subject: Re: Weird problems with 'pf' (on both 5.x and 6.x) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 19:30:56 -0000 Am 28.07.2006 um 03:57 schrieb Garance A Drosihn: > It occurred to me that it might be more informative to > see the transaction from the *freebsd* side of things, > since that's the machine running pf! So, here is a > similar set of two lpq's, as seen from the print-server > side of the connection. It seems to be telling the > same basic story, as far as I can tell. It's just showing that no ACKs come back. Can you see if anything showing pflog0 with tcpdump? That output should also tell you which rule forced the rejection. What I do find curious is that the client keeps using port 1023 consistently. I was under the impression that reusing the same port number (thus having the same src-ip/port+dst-ip/port tuple) shouldn't work, because "old" packets could arrive after the original connection was closed; that's what the CLOSE_WAIT state in netstat is. Stefan -- Stefan Bethke Fon +49 170 346 0140 From owner-freebsd-stable@FreeBSD.ORG Fri Jul 28 20:20:28 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 57C9716A4EC for ; Fri, 28 Jul 2006 20:20:28 +0000 (UTC) (envelope-from drosih@rpi.edu) Received: from smtp6.server.rpi.edu (smtp6.server.rpi.edu [128.113.2.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA62443D46 for ; Fri, 28 Jul 2006 20:20:27 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp6.server.rpi.edu (8.13.1/8.13.1) with ESMTP id k6SKKOAw017685; Fri, 28 Jul 2006 16:20:26 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 28 Jul 2006 16:20:23 -0400 To: Stefan Bethke From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) Cc: freebsd-stable@freebsd.org Subject: Re: Weird problems with 'pf' (on both 5.x and 6.x) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 20:20:28 -0000 At 9:30 PM +0200 7/28/06, Stefan Bethke wrote: >Am 28.07.2006 um 03:57 schrieb Garance A Drosihn: > >>It occurred to me that it might be more informative to >>see the transaction from the *freebsd* side of things, >>since that's the machine running pf! So, here is a >>similar set of two lpq's, as seen from the print-server >>side of the connection. It seems to be telling the >>same basic story, as far as I can tell. > >It's just showing that no ACKs come back. Can you see >if anything showing pflog0 with tcpdump? Thanks for the reply. I'll check that when I get a chance to turn the machine back on. (the air-conditioning for our offices just died -- AGAIN -- so I had to shut down most of my machines today). >That output should also tell you which rule forced the >rejection. There is only one rule. The config file I'm testing with has three comment lines, and: pass out quick proto { tcp, udp } all keep state That's it. That's the entire /etc/pf.conf file. >What I do find curious is that the client keeps using >port 1023 consistently. I was under the impression that >reusing the same port number (thus having the same >src-ip/port+dst-ip/port tuple) shouldn't work, because >"old" packets could arrive after the original connection >was closed; that's what the CLOSE_WAIT state in netstat is. Hmm. Well, I did wait a few seconds between the two lpq's, just so it would be easier tell them apart in the packet dumps. Perhaps solaris is quicker to reuse ports, while 'pf' remembers that src-ip/port+dst-ip/port tuple for a longer stretch of time? But if so, there were seven seconds between the end of the first 'lpq' and the first attempt to start a connection for the second one. The 'pf' side didn't start returning ACK's until 111 seconds after the first connection had closed. That seems like a pretty long time to wait. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-stable@FreeBSD.ORG Fri Jul 28 21:50:24 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C84816A4DA for ; Fri, 28 Jul 2006 21:50:24 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [213.238.47.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id C452F43D46 for ; Fri, 28 Jul 2006 21:50:21 +0000 (GMT) (envelope-from stb@lassitu.de) Received: (from stb@koef.zs64.net) (authenticated) by koef.zs64.net (8.13.7/8.13.7) with ESMTP id k6SLo8G5010919 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 28 Jul 2006 23:50:19 +0200 (CEST) (envelope-from stb@lassitu.de) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Stefan Bethke Date: Fri, 28 Jul 2006 23:50:08 +0200 To: Garance A Drosihn X-Mailer: Apple Mail (2.752.2) Cc: freebsd-stable@freebsd.org Subject: Re: Weird problems with 'pf' (on both 5.x and 6.x) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 21:50:24 -0000 Am 28.07.2006 um 22:20 schrieb Garance A Drosihn: > At 9:30 PM +0200 7/28/06, Stefan Bethke wrote: >> What I do find curious is that the client keeps using >> port 1023 consistently. I was under the impression that >> reusing the same port number (thus having the same >> src-ip/port+dst-ip/port tuple) shouldn't work, because >> "old" packets could arrive after the original connection >> was closed; that's what the CLOSE_WAIT state in netstat is. > > Hmm. Well, I did wait a few seconds between the two lpq's, > just so it would be easier tell them apart in the packet dumps. > > Perhaps solaris is quicker to reuse ports, while 'pf' > remembers that src-ip/port+dst-ip/port tuple for a > longer stretch of time? Thinking about it, it must be pf's notion of when to forget about a closed TCP connection. lpq (in FreeBSD) is intent on using port 1023, tells the kernel it's OK to reuse it, and will try until it gets it, with an exponential backoff and an upper limit on the number of tries. I'd think the Solaris lpq does the same. Since the client and server "know" it's OK, they can deal with the not-yet-expired TIME_WAIT (by ignoring it). But pf obviously cannot know about it, and will drop packets that are received during TIME_WAIT, including a new SYN. For this case in particular, you should be able to use a pair of static rules (instead of keep state), since both source and destination ports will always be the same. Something like pass out quick proto tcp from $client 1023 to $server 515 pass in quick proto tcp from $server 515 to $client 1023 I'm not certain this is a bug in pf, maybe someone more knowledgeable can explain how the TCP state machine in pf works. Stefan -- Stefan Bethke Fon +49 170 346 0140 From owner-freebsd-stable@FreeBSD.ORG Fri Jul 28 22:13:08 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D672016A4DE for ; Fri, 28 Jul 2006 22:13:08 +0000 (UTC) (envelope-from ntai@smartfruit.com) Received: from spunkymail-a11.dreamhost.com (sd-green-bigip-176.dreamhost.com [208.97.132.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id A00FA43D45 for ; Fri, 28 Jul 2006 22:13:08 +0000 (GMT) (envelope-from ntai@smartfruit.com) Received: from [10.50.20.104] (gate.abinitio.com [65.170.40.132]) by spunkymail-a11.dreamhost.com (Postfix) with ESMTP id 32785B6A5B for ; Fri, 28 Jul 2006 15:13:07 -0700 (PDT) Message-ID: <44CA8BC1.8030004@smartfruit.com> Date: Fri, 28 Jul 2006 18:12:17 -0400 From: Naoyuki Tai User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: My FreeBSD 6.1 installed machine is haunted... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 22:13:08 -0000 Hello, I installed a i386 FreeBSD 6.1 to a brand new machine, CPU: Athlon 64 2GHz MB: BIOSTAR T-series TForce 6100-939 It installed fine, works fine for a while (15 - 20 minutes), then all of sudden, the machine goes down. It's not a freeze. It prints out something (which I cannot read) and turns itself off. Maybe it's trying to do sleep. The machine, then trys to start up. The fan spins, disk spins up, then stops again. Then, fans spins, disk spins, then stops again. It repeats the spin up and down a few times, and finally it stops. It is quite amusing, and looks like the machine is haunted. I reboot the machine. It runs for some time, and then does the same thing. It runs about 15minutes or so. Maybe longer, maybe shorter, but, it's long enough to do some operation. If I disable ACPI in the BIOS, it keeps running. If I enable ACPI in BIOS, but choose disable ACPI option for the boot, it keeps running. However, when I did acpiconf -s 1, it fails to sleep, citing that an USB is not willing to go sleep. I ended up giving up on 6.1, and reinstalled with 5.5. This works just fine. So, why does the machine act so oddly when I install 6.1? I don't have a strong reason to install 6.1, but, would be nice if I could use the keyboard multiplexing as I use USB KVM and would be very handy to have it. -- Naoyuki "Tai" Tai, ntai a t smartfruit d o t com From owner-freebsd-stable@FreeBSD.ORG Fri Jul 28 22:17:16 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E9AC16A4E1 for ; Fri, 28 Jul 2006 22:17:16 +0000 (UTC) (envelope-from dwilde1@gmail.com) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F79E43D67 for ; Fri, 28 Jul 2006 22:17:10 +0000 (GMT) (envelope-from dwilde1@gmail.com) Received: by wx-out-0102.google.com with SMTP id i26so1512641wxd for ; Fri, 28 Jul 2006 15:17:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=iHhDe1YGmRuWwDwSdPiFiTSX1HVG9w5O3MkDgXmfK8ciRvbY7cTqbySkh5pq1xq9r+rcgfJyvh+UGhxxob/fRwL/ocbrsf1nuXf7R4IvRcd68ED7LBbGoiV9tj8+m/i9rEnreE1OzBEghkG0NRYXDn2LOfZmVlwfR27t9688pUU= Received: by 10.70.125.2 with SMTP id x2mr2997081wxc; Fri, 28 Jul 2006 15:17:10 -0700 (PDT) Received: by 10.70.16.9 with HTTP; Fri, 28 Jul 2006 15:17:10 -0700 (PDT) Message-ID: Date: Fri, 28 Jul 2006 17:17:10 -0500 From: "Don Wilde" Sender: dwilde1@gmail.com To: "Michael Proto" In-Reply-To: <44CA5F8D.2070609@jellydonut.org> MIME-Version: 1.0 References: <200607271822.k6RIMHp2097311@crimson.hydrus.org.uk> <200607272244.13115.max@love2party.net> <44CA5F8D.2070609@jellydonut.org> X-Google-Sender-Auth: 4020901525ab1778 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: iwi(4) in RELENG_6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 22:17:16 -0000 On 7/28/06, Michael Proto wrote: > > > Don Wilde wrote: > >> Okay, I've gotten it working with all encryption off (raw DHCP). All > the > >> nasty messages went away, so I'll see what's changed in the ifconfig > >> options. > >> > >> ifconfig_iwi0="DHCP ssid rewired channel 11 authmode shared weptxkey 1 > >> wepmode on wepkey 0x1234567890" > >> > >> Can anybody spot it off the top? > >> > > > > By removing the hardwired 'channel 11 authmode shared' from both sides, > I > > have been able to connect successfully with WEP authentication. > > > > Just a note (and someone please correct me if I'm wrong), but setting > the channel in the client's ifconfig statement is invalid in BSS mode-- > it will pull the appropriate channel from the AP during the association. > > > -Proto > It used to work that way, so somebody must have updated the coding. Thanks, Michael, for the input. From owner-freebsd-stable@FreeBSD.ORG Fri Jul 28 23:00:40 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6CFBF16A55E for ; Fri, 28 Jul 2006 23:00:40 +0000 (UTC) (envelope-from fydernix@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id 539B443D49 for ; Fri, 28 Jul 2006 23:00:19 +0000 (GMT) (envelope-from fydernix@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so1771uge for ; Fri, 28 Jul 2006 16:00:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=tHG4hjmw+fNCe6PU1TG5UqjHBW6svGswUe6IgbQnNb+s6pJw+0P4m0DQtbDzSHZ8t+pnzU8vr/v6AKarKtKcPacE0wI2qSzHQKAilv7+U4Jl7xrrnu3iipAZgTf9WzMF3JkVWlalSJdV8zAdgU3UoHccKiJBqNxTanBULdnp1II= Received: by 10.78.158.11 with SMTP id g11mr1022894hue; Fri, 28 Jul 2006 16:00:18 -0700 (PDT) Received: by 10.78.119.15 with HTTP; Fri, 28 Jul 2006 16:00:18 -0700 (PDT) Message-ID: Date: Fri, 28 Jul 2006 19:00:18 -0400 From: "SigmaX asdf" To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Gateway X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 23:00:40 -0000 I'm trying to setup a gateway/firewall on my network in a similar setup to that shown in the in the handbook diagram at http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-natd.html. I've followed what I can figure out, adding the following to my /etc/rc.conf gateway_enable="YES" firewall_enable="YES" firewall_type="OPEN" natd_enabl="YES" natd_interface="rl0" My understanding is that in FreeBSD 6 it's not necessary to recompile a kernal with IPFIREWALL and IPDIVERT, but appropriate modules will be loaded automatically. That said, the NAT and gateway stuff doesn't seem to be working properly, leastwise not when I try to connect from my Ubuntu Linux client (See thread here: http://ubuntuforums.org/showthread.php?t=224843) What all am I supposed to do to setup this gateway? SigmaX From owner-freebsd-stable@FreeBSD.ORG Fri Jul 28 23:03:25 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 881E616A4DD; Fri, 28 Jul 2006 23:03:25 +0000 (UTC) (envelope-from prvs=ohartman=3577c8702@uni-mainz.de) Received: from mailgate02.zdv.uni-mainz.de (mailgate02.zdv.Uni-Mainz.DE [134.93.178.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89BFD43D45; Fri, 28 Jul 2006 23:03:21 +0000 (GMT) (envelope-from prvs=ohartman=3577c8702@uni-mainz.de) Received: from exfront02.zdv.uni-mainz.de ([134.93.176.56]) by mailgate02.zdv.uni-mainz.de with ESMTP; 29 Jul 2006 01:03:20 +0200 Received: from mail.uni-mainz.de ([134.93.176.49]) by exfront02.zdv.Uni-Mainz.DE with Microsoft SMTPSVC(6.0.3790.1830); Sat, 29 Jul 2006 01:03:20 +0200 Received: from [192.168.1.128] ([85.178.6.232] RDNS failed) by mail.uni-mainz.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Sat, 29 Jul 2006 01:03:17 +0200 Message-ID: <44CA97AB.2070100@mail.uni-mainz.de> Date: Sat, 29 Jul 2006 01:03:07 +0200 From: "O. Hartmann" User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: John Baldwin References: <44C63DFD.5040401@rogers.com> <44C85C4F.7030902@rogers.com> <200607280948.51239.jhb@freebsd.org> In-Reply-To: <200607280948.51239.jhb@freebsd.org> Content-Type: multipart/mixed; boundary="------------060902000402000309040604" X-OriginalArrivalTime: 28 Jul 2006 23:03:17.0192 (UTC) FILETIME=[0303B480:01C6B29A] X-Mailman-Approved-At: Fri, 28 Jul 2006 23:28:01 +0000 Cc: stable@freebsd.org, Bruno Ducrot , freebsd-stable@freebsd.org, Mike Jakubik , David Duchscher , Jiawei Ye Subject: Re: Monitoring temperature with acpi (sysctls) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 23:03:25 -0000 This is a multi-part message in MIME format. --------------060902000402000309040604 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit John Baldwin wrote: > On Thursday 27 July 2006 02:25, Mike Jakubik wrote: > >> Jiawei Ye wrote: >> >>> On 7/27/06, Mike Jakubik wrote: >>> >>>> I don't want to spend $50 extra per system, just so i can read the >>>> temperature, and not even use any of the IPMI functions. I need a simple >>>> and scriptable way to get the values, acpi sysctls are ideal for this. >>>> >>> What about using SMBus? Is it available on your system? xmbmon reads >>> temperatures off the SMBus IIRC. >>> >> I tried that, unfortunately it does not work. All i want to know is if >> this a shortcoming of freebsd or the motherboard, if its the later, i >> will contact the manufacturer. >> > > If ACPI doesn't include the sysctl's that's due to your BIOS, not FreeBSD. > You can verify by doing an acpidump and seeing if you have any thermal > zones listed in your ASL. > > This is a 'acpidump -d' of my BIOS, mainboard ASUS A8N32-SLI Deluxe, latest BIOS, V1205 as seen on ASUS homepage. Please see attachment. Oliver --------------060902000402000309040604 Content-Type: text/plain; name="acpi.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="acpi.txt" /* * Intel ACPI Component Architecture * AML Disassembler version 20041119 * * Disassembly of /tmp/acpidump.nhd4SF, Fri Jul 28 23:00:44 2006 */ DefinitionBlock ("DSDT.aml", "DSDT", 1, "A0371", "A0371001", 1) { Name (DP80, 0x1080) Name (DP90, 0x90) Name (SPIO, 0x2E) Name (IOPB, 0x0C00) Name (IOPL, 0x10) Name (IOEB, 0x0D00) Name (IOEL, 0x10) Name (IOGB, 0x0A20) Name (IOGL, 0x10) Name (IODB, 0x0A30) Name (IODL, 0x10) Name (IO1B, 0x0A20) Name (IO1L, 0x08) Name (IO3B, 0x0D00) Name (IO3L, 0x80) Name (PMBS, 0x0500) Name (PMLN, 0x0100) Name (SCBS, 0x0800) Name (SCLN, 0x0100) Name (ACBS, 0x0900) Name (ACLN, 0x0100) Name (SCIO, 0x0800) Name (SCTL, 0x0590) Name (EXTS, 0x00) Name (APIC, 0x01) Name (ABWV, 0xAB) Name (PCIB, 0xE0000000) Name (PCIL, 0x10000000) Name (SMBS, 0x0700) OperationRegion (BIOS, SystemMemory, 0x7FFBE064, 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, Offset (0x1C), CPB0, 32, CPB1, 32, CPB2, 32, CPB3, 32, ASSB, 8, AOTB, 8, AAXB, 32 } Method (RRIO, 4, NotSerialized) { Store ("RRIO", Debug) } Method (RDMA, 3, NotSerialized) { Store ("rDMA", Debug) } Name (PICM, 0x00) 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, 0x00)) { Store (0xAC, DBG8) } Store (0x01, OSVR) If (CondRefOf (\_OSI, Local1)) { If (\_OSI ("Windows 2001")) { Store (0x00, 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), 0x01, 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, 0x00)) Store (ShiftLeft (SS1, 0x01), Local0) Or (Local0, ShiftLeft (SS2, 0x02), Local0) Or (Local0, ShiftLeft (SS3, 0x03), Local0) Or (Local0, ShiftLeft (SS4, 0x04), Local0) If (And (ShiftLeft (0x01, Arg1), Local0)) { Store (Arg1, Index (PRWP, 0x01)) } Else { ShiftRight (Local0, 0x01, Local0) If (LOr (LEqual (OSFL (), 0x01), LEqual (OSFL (), 0x02))) { FindSetLeftBit (Local0, Index (PRWP, 0x01)) } Else { FindSetRightBit (Local0, Index (PRWP, 0x01)) } } Return (PRWP) } Name (WAKP, Package (0x02) { Zero, Zero }) OperationRegion (DEB0, SystemIO, DP80, 0x01) Field (DEB0, ByteAcc, NoLock, Preserve) { DBG8, 8 } OperationRegion (DEB1, SystemIO, DP90, 0x02) Field (DEB1, WordAcc, NoLock, Preserve) { DBG9, 16 } Scope (\_SB) { Name (PR00, Package (0x20) { Package (0x04) { 0x000AFFFF, 0x00, LSMB, 0x00 }, Package (0x04) { 0x000BFFFF, 0x00, LUB0, 0x00 }, Package (0x04) { 0x000BFFFF, 0x01, LUB2, 0x00 }, Package (0x04) { 0x0013FFFF, 0x00, LMAC, 0x00 }, Package (0x04) { 0x0010FFFF, 0x00, LSA0, 0x00 }, Package (0x04) { 0x0011FFFF, 0x00, LSA1, 0x00 }, Package (0x04) { 0x000DFFFF, 0x00, LACI, 0x00 }, Package (0x04) { 0x000DFFFF, 0x01, LMC9, 0x00 }, Package (0x04) { 0x0002FFFF, 0x00, LNKB, 0x00 }, Package (0x04) { 0x0002FFFF, 0x01, LNKC, 0x00 }, Package (0x04) { 0x0002FFFF, 0x02, LNKD, 0x00 }, Package (0x04) { 0x0002FFFF, 0x03, LNKA, 0x00 }, Package (0x04) { 0x0003FFFF, 0x00, LNKA, 0x00 }, Package (0x04) { 0x0003FFFF, 0x01, LNKB, 0x00 }, Package (0x04) { 0x0003FFFF, 0x02, LNKC, 0x00 }, Package (0x04) { 0x0003FFFF, 0x03, LNKD, 0x00 }, Package (0x04) { 0x0004FFFF, 0x00, LNKA, 0x00 }, Package (0x04) { 0x0004FFFF, 0x01, LNKB, 0x00 }, Package (0x04) { 0x0004FFFF, 0x02, LNKC, 0x00 }, Package (0x04) { 0x0004FFFF, 0x03, LNKD, 0x00 }, Package (0x04) { 0x0017FFFF, 0x00, LNKB, 0x00 }, Package (0x04) { 0x0017FFFF, 0x01, LNKC, 0x00 }, Package (0x04) { 0x0017FFFF, 0x02, LNKD, 0x00 }, Package (0x04) { 0x0017FFFF, 0x03, LNKA, 0x00 }, Package (0x04) { 0x0016FFFF, 0x00, LNKC, 0x00 }, Package (0x04) { 0x0016FFFF, 0x01, LNKD, 0x00 }, Package (0x04) { 0x0016FFFF, 0x02, LNKA, 0x00 }, Package (0x04) { 0x0016FFFF, 0x03, LNKB, 0x00 }, Package (0x04) { 0x0015FFFF, 0x00, LNKD, 0x00 }, Package (0x04) { 0x0015FFFF, 0x01, LNKA, 0x00 }, Package (0x04) { 0x0015FFFF, 0x02, LNKB, 0x00 }, Package (0x04) { 0x0015FFFF, 0x03, LNKC, 0x00 } }) Name (AR00, Package (0x20) { Package (0x04) { 0x000AFFFF, 0x00, LSMB, 0x00 }, Package (0x04) { 0x000BFFFF, 0x00, LUB0, 0x00 }, Package (0x04) { 0x000BFFFF, 0x01, LUB2, 0x00 }, Package (0x04) { 0x0013FFFF, 0x00, LMAC, 0x00 }, Package (0x04) { 0x0010FFFF, 0x00, LSA0, 0x00 }, Package (0x04) { 0x0011FFFF, 0x00, LSA1, 0x00 }, Package (0x04) { 0x000DFFFF, 0x00, LACI, 0x00 }, Package (0x04) { 0x000DFFFF, 0x01, LMC9, 0x00 }, Package (0x04) { 0x0002FFFF, 0x00, LNKB, 0x00 }, Package (0x04) { 0x0002FFFF, 0x01, LNKC, 0x00 }, Package (0x04) { 0x0002FFFF, 0x02, LNKD, 0x00 }, Package (0x04) { 0x0002FFFF, 0x03, LNKA, 0x00 }, Package (0x04) { 0x0003FFFF, 0x00, LNKA, 0x00 }, Package (0x04) { 0x0003FFFF, 0x01, LNKB, 0x00 }, Package (0x04) { 0x0003FFFF, 0x02, LNKC, 0x00 }, Package (0x04) { 0x0003FFFF, 0x03, LNKD, 0x00 }, Package (0x04) { 0x0004FFFF, 0x00, LNKA, 0x00 }, Package (0x04) { 0x0004FFFF, 0x01, LNKB, 0x00 }, Package (0x04) { 0x0004FFFF, 0x02, LNKC, 0x00 }, Package (0x04) { 0x0004FFFF, 0x03, LNKD, 0x00 }, Package (0x04) { 0x0017FFFF, 0x00, LNKB, 0x00 }, Package (0x04) { 0x0017FFFF, 0x01, LNKC, 0x00 }, Package (0x04) { 0x0017FFFF, 0x02, LNKD, 0x00 }, Package (0x04) { 0x0017FFFF, 0x03, LNKA, 0x00 }, Package (0x04) { 0x0016FFFF, 0x00, LNKC, 0x00 }, Package (0x04) { 0x0016FFFF, 0x01, LNKD, 0x00 }, Package (0x04) { 0x0016FFFF, 0x02, LNKA, 0x00 }, Package (0x04) { 0x0016FFFF, 0x03, LNKB, 0x00 }, Package (0x04) { 0x0015FFFF, 0x00, LNKD, 0x00 }, Package (0x04) { 0x0015FFFF, 0x01, LNKA, 0x00 }, Package (0x04) { 0x0015FFFF, 0x02, LNKB, 0x00 }, Package (0x04) { 0x0015FFFF, 0x03, LNKC, 0x00 } }) Name (PR01, Package (0x0D) { Package (0x04) { 0x000BFFFF, 0x00, LNKA, 0x00 }, Package (0x04) { 0x0006FFFF, 0x00, LNKA, 0x00 }, Package (0x04) { 0x0006FFFF, 0x01, LNKB, 0x00 }, Package (0x04) { 0x0006FFFF, 0x02, LNKC, 0x00 }, Package (0x04) { 0x0006FFFF, 0x03, LNKD, 0x00 }, Package (0x04) { 0x0007FFFF, 0x00, LNKB, 0x00 }, Package (0x04) { 0x0007FFFF, 0x01, LNKC, 0x00 }, Package (0x04) { 0x0007FFFF, 0x02, LNKD, 0x00 }, Package (0x04) { 0x0007FFFF, 0x03, LNKA, 0x00 }, Package (0x04) { 0x0008FFFF, 0x00, LNKC, 0x00 }, Package (0x04) { 0x0008FFFF, 0x01, LNKD, 0x00 }, Package (0x04) { 0x0008FFFF, 0x02, LNKA, 0x00 }, Package (0x04) { 0x0008FFFF, 0x03, LNKB, 0x00 } }) Name (AR01, Package (0x0D) { Package (0x04) { 0x000BFFFF, 0x00, LNKA, 0x00 }, Package (0x04) { 0x0006FFFF, 0x00, LNKA, 0x00 }, Package (0x04) { 0x0006FFFF, 0x01, LNKB, 0x00 }, Package (0x04) { 0x0006FFFF, 0x02, LNKC, 0x00 }, Package (0x04) { 0x0006FFFF, 0x03, LNKD, 0x00 }, Package (0x04) { 0x0007FFFF, 0x00, LNKB, 0x00 }, Package (0x04) { 0x0007FFFF, 0x01, LNKC, 0x00 }, Package (0x04) { 0x0007FFFF, 0x02, LNKD, 0x00 }, Package (0x04) { 0x0007FFFF, 0x03, LNKA, 0x00 }, Package (0x04) { 0x0008FFFF, 0x00, LNKC, 0x00 }, Package (0x04) { 0x0008FFFF, 0x01, LNKD, 0x00 }, Package (0x04) { 0x0008FFFF, 0x02, LNKA, 0x00 }, Package (0x04) { 0x0008FFFF, 0x03, LNKB, 0x00 } }) Name (PR02, Package (0x04) { Package (0x04) { 0xFFFF, 0x00, LNKB, 0x00 }, Package (0x04) { 0xFFFF, 0x01, LNKC, 0x00 }, Package (0x04) { 0xFFFF, 0x02, LNKD, 0x00 }, Package (0x04) { 0xFFFF, 0x03, LNKA, 0x00 } }) Name (AR02, Package (0x04) { Package (0x04) { 0xFFFF, 0x00, LNKB, 0x00 }, Package (0x04) { 0xFFFF, 0x01, LNKC, 0x00 }, Package (0x04) { 0xFFFF, 0x02, LNKD, 0x00 }, Package (0x04) { 0xFFFF, 0x03, LNKA, 0x00 } }) Name (PR03, Package (0x04) { Package (0x04) { 0xFFFF, 0x00, LNKA, 0x00 }, Package (0x04) { 0xFFFF, 0x01, LNKB, 0x00 }, Package (0x04) { 0xFFFF, 0x02, LNKC, 0x00 }, Package (0x04) { 0xFFFF, 0x03, LNKD, 0x00 } }) Name (AR03, Package (0x04) { Package (0x04) { 0xFFFF, 0x00, LNKA, 0x00 }, Package (0x04) { 0xFFFF, 0x01, LNKB, 0x00 }, Package (0x04) { 0xFFFF, 0x02, LNKC, 0x00 }, Package (0x04) { 0xFFFF, 0x03, LNKD, 0x00 } }) Name (PR04, Package (0x04) { Package (0x04) { 0xFFFF, 0x00, LNKA, 0x00 }, Package (0x04) { 0xFFFF, 0x01, LNKB, 0x00 }, Package (0x04) { 0xFFFF, 0x02, LNKC, 0x00 }, Package (0x04) { 0xFFFF, 0x03, LNKD, 0x00 } }) Name (AR04, Package (0x04) { Package (0x04) { 0xFFFF, 0x00, LNKA, 0x00 }, Package (0x04) { 0xFFFF, 0x01, LNKB, 0x00 }, Package (0x04) { 0xFFFF, 0x02, LNKC, 0x00 }, Package (0x04) { 0xFFFF, 0x03, LNKD, 0x00 } }) Name (PR05, Package (0x04) { Package (0x04) { 0xFFFF, 0x00, LNKB, 0x00 }, Package (0x04) { 0xFFFF, 0x01, LNKC, 0x00 }, Package (0x04) { 0xFFFF, 0x02, LNKD, 0x00 }, Package (0x04) { 0xFFFF, 0x03, LNKA, 0x00 } }) Name (AR05, Package (0x04) { Package (0x04) { 0xFFFF, 0x00, LNKB, 0x00 }, Package (0x04) { 0xFFFF, 0x01, LNKC, 0x00 }, Package (0x04) { 0xFFFF, 0x02, LNKD, 0x00 }, Package (0x04) { 0xFFFF, 0x03, LNKA, 0x00 } }) Name (PR06, Package (0x04) { Package (0x04) { 0xFFFF, 0x00, LNKC, 0x00 }, Package (0x04) { 0xFFFF, 0x01, LNKD, 0x00 }, Package (0x04) { 0xFFFF, 0x02, LNKA, 0x00 }, Package (0x04) { 0xFFFF, 0x03, LNKB, 0x00 } }) Name (AR06, Package (0x04) { Package (0x04) { 0xFFFF, 0x00, LNKC, 0x00 }, Package (0x04) { 0xFFFF, 0x01, LNKD, 0x00 }, Package (0x04) { 0xFFFF, 0x02, LNKA, 0x00 }, Package (0x04) { 0xFFFF, 0x03, LNKB, 0x00 } }) Name (PR07, Package (0x04) { Package (0x04) { 0xFFFF, 0x00, LNKD, 0x00 }, Package (0x04) { 0xFFFF, 0x01, LNKA, 0x00 }, Package (0x04) { 0xFFFF, 0x02, LNKB, 0x00 }, Package (0x04) { 0xFFFF, 0x03, LNKC, 0x00 } }) Name (AR07, Package (0x04) { Package (0x04) { 0xFFFF, 0x00, LNKD, 0x00 }, Package (0x04) { 0xFFFF, 0x01, LNKA, 0x00 }, Package (0x04) { 0xFFFF, 0x02, LNKB, 0x00 }, Package (0x04) { 0xFFFF, 0x03, LNKC, 0x00 } }) Name (PRSA, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {5,7,10,14,15} }) Alias (PRSA, PRSB) Alias (PRSA, PRSC) Alias (PRSA, PRSD) Alias (PRSA, RSMB) Alias (PRSA, RSB2) Name (RSA1, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {11} }) Alias (RSA1, RSA0) Alias (PRSA, RSB0) Alias (PRSA, RSAC) Alias (PRSA, RSCI) Alias (PRSA, RSC9) Alias (PRSA, RSTA) Name (RSIR, ResourceTemplate () { Interrupt (ResourceConsumer, Level, ActiveLow, Shared) { 0x00000010, 0x00000011, 0x00000012, 0x00000013, } }) Name (RSII, ResourceTemplate () { Interrupt (ResourceConsumer, Level, ActiveLow, Shared) { 0x00000014, 0x00000015, 0x00000016, 0x00000017, } }) Device (PCI0) { Name (_HID, EisaId ("PNP0A03")) Name (_ADR, 0x00180000) Method (^BN00, 0, NotSerialized) { Return (0x00) } Method (_BBN, 0, NotSerialized) { Return (BN00 ()) } Name (_UID, 0x00) Method (_PRT, 0, NotSerialized) { If (PICM) { Return (AR00) } Return (PR00) } Device (NB2N) { Name (_ADR, 0x00) Method (NPTS, 1, NotSerialized) { } Method (NWAK, 1, NotSerialized) { } } Device (PCLK) { Name (_ADR, 0x02) } Device (SBRG) { Name (_ADR, 0x000A0000) Method (SPTS, 1, NotSerialized) { Store (Arg0, \_SB.PCI0.IDE0.PTS0) Store (\_SB.PCI0.IDE0.ID20, \_SB.PCI0.IDE0.SID0) Store (\_SB.PCI0.IDE0.IDTS, \_SB.PCI0.IDE0.SID1) Store (\_SB.PCI0.IDE0.IDTP, \_SB.PCI0.IDE0.SID2) Store (\_SB.PCI0.IDE0.ID22, \_SB.PCI0.IDE0.SID3) Store (\_SB.PCI0.IDE0.UMSS, \_SB.PCI0.IDE0.SID4) Store (\_SB.PCI0.IDE0.UMSP, \_SB.PCI0.IDE0.SID5) Store (One, PS1S) Store (One, PS1E) Store (One, \_SB.SLPS) } Method (SWAK, 1, NotSerialized) { Store (Zero, \_SB.SLPS) Store (Zero, PS1E) Store (0x02, S1CT) Store (0x02, S3CT) Store (0x02, S4CT) Store (0x02, S5CT) } OperationRegion (SMIE, SystemIO, SCIO, 0x08) Field (SMIE, ByteAcc, NoLock, Preserve) { , 15, PS1S, 1, , 31, PS1E, 1, Offset (0x08) } OperationRegion (SXCT, SystemIO, SCTL, 0x10) Field (SXCT, ByteAcc, NoLock, Preserve) { S1CT, 2, Offset (0x04), S3CT, 2, Offset (0x08), S4CT, 2, Offset (0x0C), S5CT, 2, Offset (0x10) } Scope (\_SB) { Name (SLPS, 0x00) Device (SLPB) { Name (_HID, EisaId ("PNP0C0E")) Method (_STA, 0, NotSerialized) { If (EXTS) { Return (0x0F) } Return (0x00) } Method (SBEV, 0, NotSerialized) { If (SLPS) { Notify (SLPB, 0x02) } Else { Notify (SLPB, 0x80) } } Method (\_GPE._L01, 0, NotSerialized) { \_SB.SLPB.SBEV () } Method (_PRW, 0, NotSerialized) { Return (Package (0x02) { 0x01, 0x04 }) } } Scope (PCI0) { Method (_S3D, 0, NotSerialized) { If (LEqual (OSFL (), 0x02)) { Return (0x02) } Else { Return (0x03) } } Name (_S1D, 0x01) Name (NATA, Package (0x01) { 0x00100000 }) Device (NVRB) { Name (_HID, "NVRAIDBUS") Method (_STA, 0, NotSerialized) { If (And (CPB0, 0x01)) { Return (0x0F) } Else { Return (0x00) } } Name (_CRS, ResourceTemplate () { IO (Decode16, 0x04D2, 0x04D2, 0x01, 0x01) }) } } } 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 (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 (FDC) { Name (_HID, EisaId ("PNP0700")) Method (_FDE, 0, NotSerialized) { Name (FDEP, Package (0x05) { 0x00, 0x00, 0x02, 0x02, 0x02 }) If (_STA ()) { Store (0x01, Index (FDEP, 0x00)) } Return (FDEP) } Method (_STA, 0, NotSerialized) { Return (DSTA (0x03)) } Method (_DIS, 0, NotSerialized) { DCNT (0x03, 0x00) } Method (_CRS, 0, NotSerialized) { DCRS (0x03, 0x01) Store (IRQM, IRQE) Store (DMAM, DMAE) Store (IO11, IO21) Store (IO12, IO22) Store (0x06, LEN2) Add (IO21, 0x07, IO31) Store (IO31, IO32) Store (0x01, LEN3) Return (CRS2) } Method (_SRS, 1, NotSerialized) { DSRS (Arg0, 0x03) CreateWordField (Arg0, 0x11, IRQE) CreateByteField (Arg0, 0x14, DMAE) ENFG (CGLD (0x03)) If (IRQE) { FindSetRightBit (IRQE, Local0) Subtract (Local0, 0x01, INTR) } Else { Store (0x00, INTR) } If (DMAE) { FindSetRightBit (DMAE, Local0) Subtract (Local0, 0x01, DMCH) } Else { Store (0x04, DMCH) } EXFG () } Name (_PRS, ResourceTemplate () { StartDependentFn (0x00, 0x00) { IO (Decode16, 0x03F0, 0x03F0, 0x01, 0x06) IO (Decode16, 0x03F7, 0x03F7, 0x01, 0x01) IRQNoFlags () {6} DMA (Compatibility, NotBusMaster, Transfer8) {2} } StartDependentFnNoPri () { IO (Decode16, 0x03F0, 0x03F0, 0x01, 0x06) IO (Decode16, 0x03F7, 0x03F7, 0x01, 0x01) IRQNoFlags () {3,4,5,6,7,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8) {0,1,2,3} } StartDependentFnNoPri () { IO (Decode16, 0x0370, 0x0370, 0x01, 0x06) IO (Decode16, 0x0377, 0x0377, 0x01, 0x01) IRQNoFlags () {3,4,5,6,7,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8) {0,1,2,3} } EndDependentFn () }) } Device (LPTE) { Method (_HID, 0, NotSerialized) { If (LPTM (0x02)) { Return (0x0104D041) } Else { Return (0x0004D041) } } Method (_STA, 0, NotSerialized) { Return (DSTA (0x02)) } Method (_DIS, 0, NotSerialized) { DCNT (0x02, 0x00) } Method (_CRS, 0, NotSerialized) { DCRS (0x02, 0x01) If (LPTM (0x02)) { Store (IRQM, IRQE) Store (DMAM, DMAE) Store (IO11, IO21) Store (IO12, IO22) Store (LEN1, LEN2) Add (IO21, 0x0400, IO31) Store (IO31, IO32) Store (LEN2, LEN3) Return (CRS2) } Else { Return (CRS1) } } Method (_SRS, 1, NotSerialized) { DSRS (Arg0, 0x02) } Method (_PRS, 0, NotSerialized) { If (LPTM (0x02)) { Return (EPPR) } Else { Return (LPPR) } } Name (LPPR, ResourceTemplate () { StartDependentFnNoPri () { IO (Decode16, 0x0378, 0x0378, 0x01, 0x08) IRQNoFlags () {3,4,5,6,7,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8) {} } StartDependentFnNoPri () { IO (Decode16, 0x0278, 0x0278, 0x01, 0x08) IRQNoFlags () {3,4,5,6,7,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8) {} } StartDependentFnNoPri () { IO (Decode16, 0x03BC, 0x03BC, 0x01, 0x04) IRQNoFlags () {3,4,5,6,7,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8) {} } EndDependentFn () }) Name (EPPR, ResourceTemplate () { StartDependentFn (0x00, 0x00) { IO (Decode16, 0x0378, 0x0378, 0x01, 0x08) IO (Decode16, 0x0778, 0x0778, 0x01, 0x08) IRQNoFlags () {7} DMA (Compatibility, NotBusMaster, Transfer8) {3} } StartDependentFnNoPri () { IO (Decode16, 0x0378, 0x0378, 0x01, 0x08) IO (Decode16, 0x0778, 0x0778, 0x01, 0x08) IRQNoFlags () {3,4,5,6,7,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8) {0,1,2,3} } StartDependentFnNoPri () { IO (Decode16, 0x0278, 0x0278, 0x01, 0x08) IO (Decode16, 0x0678, 0x0678, 0x01, 0x08) IRQNoFlags () {3,4,5,6,7,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8) {0,1,2,3} } StartDependentFnNoPri () { IO (Decode16, 0x03BC, 0x03BC, 0x01, 0x04) IO (Decode16, 0x07BC, 0x07BC, 0x01, 0x04) IRQNoFlags () {3,4,5,6,7,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8) {0,1,2,3} } EndDependentFn () }) } Device (GAME) { Name (_HID, EisaId ("PNPB02F")) Method (_STA, 0, NotSerialized) { Return (DSTA (0x08)) } Method (_DIS, 0, NotSerialized) { DCNT (0x08, 0x00) } Name (GMCR, ResourceTemplate () { IO (Decode16, 0x0000, 0x0000, 0x08, 0x08) }) Method (_CRS, 0, NotSerialized) { CreateWordField (GMCR, 0x02, IOGL) CreateWordField (GMCR, 0x04, IOGH) ENFG (CGLD (0x08)) ShiftLeft (IOAH, 0x08, IOGL) Or (IOAL, IOGL, IOGL) Store (IOGL, IOGH) CreateByteField (GMCR, 0x06, IOAL) Store (0x01, IOAL) EXFG () Return (GMCR) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x02, IO11) ENFG (CGLD (0x08)) And (IO11, 0xFF, IOAL) ShiftRight (IO11, 0x08, IOAH) DCNT (0x08, 0x01) EXFG () } Name (_PRS, ResourceTemplate () { StartDependentFn (0x00, 0x00) { IO (Decode16, 0x0201, 0x0201, 0x01, 0x08) } EndDependentFn () }) } Device (MIDI) { Name (_HID, EisaId ("PNPB006")) Method (_STA, 0, NotSerialized) { Return (DSTA (0x05)) } Method (_DIS, 0, NotSerialized) { DCNT (0x05, 0x00) } Name (MDCR, ResourceTemplate () { IO (Decode16, 0x0000, 0x0000, 0x01, 0x02) IRQNoFlags () {5} }) Method (_CRS, 0, NotSerialized) { CreateWordField (MDCR, 0x02, IOML) CreateWordField (MDCR, 0x04, IOMH) CreateWordField (MDCR, 0x09, IRQM) ENFG (CGLD (0x05)) ShiftLeft (IOAH, 0x08, IOML) Or (IOAL, IOML, IOML) Store (IOML, IOMH) If (INTR) { ShiftLeft (0x01, INTR, IRQM) } Else { Store (0x00, IRQM) } EXFG () Return (MDCR) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x02, IO11) CreateWordField (Arg0, 0x09, IRQM) ENFG (CGLD (0x05)) And (IO11, 0xFF, IOAL) ShiftRight (IO11, 0x08, IOAH) If (IRQM) { FindSetRightBit (IRQM, Local0) Subtract (Local0, 0x01, INTR) } Else { Store (0x00, INTR) } DCNT (0x05, 0x01) EXFG () } Name (_PRS, ResourceTemplate () { StartDependentFnNoPri () { IO (Decode16, 0x0300, 0x0300, 0x01, 0x02) } StartDependentFnNoPri () { IO (Decode16, 0x0330, 0x0330, 0x01, 0x02) } EndDependentFn () IRQNoFlags () {5,7,9,10,11} }) } 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, 0x0062, 0x0062, 0x00, 0x02) IO (Decode16, 0x0065, 0x0065, 0x00, 0x0B) 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, 0x0800, 0x0800, 0x00, 0x10) IO (Decode16, 0x0000, 0x0000, 0x00, 0x00) IO (Decode16, 0x0000, 0x0000, 0x00, 0x00) IO (Decode16, 0x0000, 0x0000, 0x00, 0x00) IO (Decode16, 0x0000, 0x0000, 0x00, 0x00) IO (Decode16, 0x0000, 0x0000, 0x00, 0x00) IO (Decode16, 0x0000, 0x0000, 0x00, 0x00) Memory32Fixed (ReadOnly, 0xFEE01000, 0x000FF000) Memory32Fixed (ReadOnly, 0xFEFFF000, 0x00001000) Memory32Fixed (ReadWrite, 0xFFB00000, 0x004F0000) Memory32Fixed (ReadOnly, 0xFFF00000, 0x00100000) }) Method (_CRS, 0, NotSerialized) { CreateWordField (CRS, 0x7A, GP00) CreateWordField (CRS, 0x7C, GP01) CreateByteField (CRS, 0x7F, GP0L) CreateWordField (CRS, 0x82, GP10) CreateWordField (CRS, 0x84, GP11) CreateByteField (CRS, 0x87, GP1L) Store (PMBS, GP00) Store (PMBS, GP01) If (LNot (LLess (PMLN, 0x0100))) { ShiftRight (PMLN, 0x01, GP0L) Add (GP00, GP0L, GP10) Add (GP01, GP0L, GP11) Subtract (PMLN, GP0L, GP1L) } Else { Store (PMLN, GP0L) } If (SCBS) { CreateWordField (CRS, 0x8A, SC00) CreateWordField (CRS, 0x8C, SC01) CreateByteField (CRS, 0x8F, SC0L) CreateWordField (CRS, 0x92, SC10) CreateWordField (CRS, 0x94, SC11) CreateByteField (CRS, 0x97, SC1L) Store (SCBS, SC00) Store (SCBS, SC01) If (LNot (LLess (SCLN, 0x0100))) { ShiftRight (SCLN, 0x01, SC0L) Add (SC00, SC0L, SC10) Add (SC01, SC0L, SC11) Subtract (SCLN, SC0L, SC1L) } Else { Store (SCLN, SC0L) } } If (ACBS) { CreateWordField (CRS, 0x9A, AC00) CreateWordField (CRS, 0x9C, AC01) CreateByteField (CRS, 0x9F, AC0L) CreateWordField (CRS, 0xA2, AC10) CreateWordField (CRS, 0xA4, AC11) CreateByteField (CRS, 0xA7, AC1L) Store (ACBS, AC00) Store (ACBS, AC01) If (LNot (LLess (ACLN, 0x0100))) { ShiftRight (ACLN, 0x01, AC0L) Add (AC00, AC0L, AC10) Add (AC01, AC0L, AC11) Subtract (ACLN, AC0L, AC1L) } Else { Store (ACLN, AC0L) } } Return (CRS) } } Scope (\_SB.PCI0.SBRG) { Device (ASOC) { Name (_HID, "ATK0110") Name (_UID, 0x01010110) Method (_STA, 0, NotSerialized) { Return (0x0F) } } } OperationRegion (\_SB.PCI0.SBRG.LPDC, PCI_Config, 0xA0, 0x06) Field (\_SB.PCI0.SBRG.LPDC, ByteAcc, NoLock, Preserve) { S3F8, 1, S2F8, 1, , 3, S2E8, 1, , 1, S3E8, 1, , 4, M300, 1, , 2, M330, 1, , 4, FDC0, 1, Offset (0x03), P378, 1, P278, 1, P3BC, 1, Offset (0x04), G200, 8, G208, 8 } Method (RRIO, 4, NotSerialized) { If (LOr (LEqual (Arg0, 0x00), LEqual (Arg0, 0x01))) { If (LEqual (Arg2, 0x03F8)) { Store (Arg1, S3F8) } If (LEqual (Arg2, 0x02F8)) { Store (Arg1, S2F8) } If (LEqual (Arg2, 0x03E8)) { Store (Arg1, S3E8) } If (LEqual (Arg2, 0x02E8)) { Store (Arg1, S2E8) } } If (LEqual (Arg0, 0x02)) { If (LEqual (Arg2, 0x0378)) { Store (Arg1, P378) } If (LEqual (Arg2, 0x0278)) { Store (Arg1, P278) } If (LEqual (Arg2, 0x03BC)) { Store (Arg1, P3BC) } } If (LEqual (Arg0, 0x03)) { Store (Arg1, FDC0) } If (LEqual (Arg0, 0x05)) { If (LEqual (Arg2, 0x0330)) { Store (Arg1, M330) } If (LEqual (Arg2, 0x0300)) { Store (Arg1, M300) } } If (LEqual (Arg0, 0x08)) { Store (Zero, Local0) If (Arg1) { Store (0xFF, Local0) } If (LEqual (Arg2, 0x0200)) { Store (Local0, G200) } If (LEqual (Arg2, 0x0208)) { Store (Local0, G208) } } } Method (RDMA, 3, NotSerialized) { } Scope (\) { OperationRegion (\RAMW, SystemMemory, Subtract (TOPM, 0x00010000), 0x00010000) Field (\RAMW, ByteAcc, NoLock, Preserve) { PAR0, 32, PAR1, 32 } OperationRegion (IOB2, SystemIO, 0x082E, 0x02) Field (IOB2, ByteAcc, NoLock, Preserve) { SMIC, 8, SMIS, 8 } Method (ISMI, 1, Serialized) { Store (Arg0, SMIC) } Method (GNVS, 1, Serialized) { Store (Arg0, PAR0) ISMI (0x70) Return (PAR1) } Method (SNVS, 2, Serialized) { Store (Arg0, PAR0) Store (Arg1, PAR1) ISMI (0x71) } } Scope (\) { Field (\RAMW, ByteAcc, NoLock, Preserve) { Offset (0x08), ADSP, 32, FSBF, 16, FVCM, 8, AITU, 8, FIDV, 8, VIDV, 8, OCPI, 8, NOST, 8, NOS1, 8, DDRV, 8, CPUS, 1, CQFS, 3, CQFT, 4, AIDI, 8, OVID, 8, CCAQ, 8, MAXF, 8, MAXV, 8, CURF, 8, CURV, 8, PCEF, 8 } } OperationRegion (\_SB.PCI0.PCLK.MNCK, PCI_Config, 0x44, 0x04) Field (\_SB.PCI0.PCLK.MNCK, ByteAcc, NoLock, Preserve) { MMNN, 16, , 14, MNEN, 1, Offset (0x04) } OperationRegion (\_SB.PCI0.PCLK.SPRD, PCI_Config, 0x54, 0x04) Field (\_SB.PCI0.PCLK.SPRD, ByteAcc, NoLock, Preserve) { SPRE, 1, Offset (0x04) } OperationRegion (QDRV, SystemIO, IOGB, 0x03) Field (QDRV, ByteAcc, NoLock, Preserve) { Offset (0x02), , 1, QDDR, 4, Offset (0x03) } OperationRegion (DEB0, SystemIO, 0x1080, 0x02) Field (DEB0, ByteAcc, NoLock, Preserve) { DB16, 16 } Name (DDRT, Package (0x0A) { 0x0D, 0x0F, 0x0E, 0x0D, 0x0B, 0x07, 0x09, 0x08, 0x03, 0x02 }) Scope (\_SB.PCI0.SBRG.ASOC) { Name (MBIF, Package (0x08) { 0x01, "A8N32-SLI", 0x01, 0x01, 0x02, 0x00, 0x00, 0x00 }) Method (ASIF, 0, NotSerialized) { Return (MBIF) } Name (OC01, Package (0x06) { 0x01010000, "CPU FSB", 0x4E20, 0x9C40, 0xC9, 0x00010003 }) Name (OC02, Package (0x06) { 0x01060001, "CPU Multiplier", 0x04, 0x19, 0x16, 0x00010000 }) Name (OC03, Package (0x06) { 0x01060002, "FID VID Mode", 0x00, 0x01, 0x01, 0x00010000 }) Name (OC04, Package (0x06) { 0x07010003, "PCI Express", 0x2710, 0x332C, 0x65, 0x00 }) Name (OC05, Package (0x06) { 0x05050004, "OC Profile", 0x00, 0x04, 0x05, 0x00010001 }) Name (OC06, Package (0x06) { 0x08050005, "Turbo NOS", 0x00, 0x04, 0x05, 0x00010000 }) Name (OC07, Package (0x06) { 0x08060006, "NOS MODE", 0x00, 0x03, 0x04, 0x00 }) Name (OC08, Package (0x06) { 0x04060003, "CPU Q-Fan Control", 0x00, 0x01, 0x01, 0x00010003 }) Name (OC09, Package (0x06) { 0x01020008, "CPU VID", 0x1F40, 0x3D09, 0x3D, 0x00010000 }) Name (OC0A, Package (0x06) { 0x02020009, "DRAM Voltage", 0x0A28, 0x0BB8, 0x09, 0x00010003 }) Name (OC0B, Package (0x06) { 0x0906000C, "AI Overclock Tuner", 0x00, 0x04, 0x05, 0x00010003 }) Name (OC0C, Package (0x06) { 0x0106000B, "Cool&Quiet Support", 0x00, 0x01, 0x02, 0x00010003 }) Name (OBUF, Package (0x0C) { OC01, OC02, OC03, OC04, OC05, OC06, OC07, OC08, OC09, OC0A, OC0B, OC0C }) Name (OCVO, 0x00) Method (OCIF, 0, NotSerialized) { Store (ShiftLeft (MAXV, 0x01), Local1) Subtract (0x3D09, Multiply (Local1, 0x7D), Index (OC09, 0x03)) Subtract (0x3D, Local1, Index (OC09, 0x04)) Return (OBUF) } Name (TEM1, Package (0x11) { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }) Method (TEMP, 1, NotSerialized) { Store (FSBF, Index (TEM1, 0x00)) Store (FVCM, Index (TEM1, 0x01)) Store (AITU, Index (TEM1, 0x02)) Store (FIDV, Index (TEM1, 0x03)) Store (VIDV, Index (TEM1, 0x04)) Store (OCPI, Index (TEM1, 0x05)) Store (NOST, Index (TEM1, 0x06)) Store (NOS1, Index (TEM1, 0x07)) Store (DDRV, Index (TEM1, 0x08)) Store (CPUS, Index (TEM1, 0x09)) Store (CQFS, Index (TEM1, 0x0A)) Store (CQFT, Index (TEM1, 0x0B)) Store (AIDI, Index (TEM1, 0x0C)) Store (OVID, Index (TEM1, 0x0D)) Store (CCAQ, Index (TEM1, 0x0E)) Store (MAXF, Index (TEM1, 0x0F)) Store (MAXV, Index (TEM1, 0x10)) Return (TEM1) } Method (OCOP, 1, NotSerialized) { Store (DerefOf (Index (OC01, 0x00)), Local1) If (LEqual (Arg0, Local1)) { Store (FSBF, Local0) Multiply (Local0, 0x64, Local1) Store (Local1, Index (CPUO, 0x01)) Subtract (Local0, 0xC8, Local2) Store (Local2, Index (CPUO, 0x02)) Return (CPUO) } Store (DerefOf (Index (OC02, 0x00)), Local1) If (LEqual (Arg0, Local1)) { Store (Add (ShiftRight (CURF, 0x01), 0x04), Index (CPUM, 0x01)) Store (Add (ShiftRight (CURF, 0x01), 0x04), Index (CPUM, 0x02)) If (LEqual (FVCM, 0x01)) { Store (0x00010000, Index (OC02, 0x05)) Store (0x00, Index (CPUM, 0x03)) } Else { Store (0x00010000, Index (OC02, 0x05)) Store (0x00, Index (CPUM, 0x03)) } Store (Add (ShiftRight (MAXF, 0x01), 0x04), Index (OC02, 0x03)) Add (0x01, DerefOf (Index (OC02, 0x03)), Local0) Store (DerefOf (Index (OC02, 0x02)), Local1) Subtract (Local0, Local1, Index (OC02, 0x04)) Return (CPUM) } Store (DerefOf (Index (OC03, 0x00)), Local1) If (LEqual (Arg0, Local1)) { Store (FVCM, Index (CPFV, 0x02)) If (LEqual (CCAQ, 0x00)) { Store (0x00010000, Index (OC03, 0x05)) Store (0x00, Index (CPFV, 0x03)) } Else { Store (0x00010003, Index (OC03, 0x05)) Store (0x01, Index (CPFV, 0x03)) } Return (CPFV) } Store (DerefOf (Index (OC04, 0x00)), Local1) If (LEqual (Arg0, Local1)) { Return (PCIV) } Store (DerefOf (Index (OC05, 0x00)), Local1) If (LEqual (Arg0, Local1)) { Store (OCPI, Index (OCPR, 0x02)) If (LNot (LGreater (AITU, 0x03))) { Store (0x00010003, Index (OC05, 0x05)) Store (0x01, Index (OCPR, 0x03)) } Else { Store (0x00010003, Index (OC05, 0x05)) Store (0x01, Index (OCPR, 0x03)) } Return (OCPR) } Store (DerefOf (Index (OC06, 0x00)), Local1) If (LEqual (Arg0, Local1)) { If (LEqual (AITU, 0x04)) { Store (NOS1, Index (NOSP, 0x02)) } Else { Store (0x00, Index (NOSP, 0x02)) } Return (NOSP) } Store (DerefOf (Index (OC07, 0x00)), Local1) If (LEqual (Arg0, Local1)) { Store (NOST, Index (NOSM, 0x02)) Return (NOSM) } Store (DerefOf (Index (OC08, 0x00)), Local1) If (LEqual (Arg0, Local1)) { Store (CPUS, Index (FANB, 0x02)) Return (FANB) } Store (DerefOf (Index (OC09, 0x00)), Local1) If (LEqual (Arg0, Local1)) { Store (Subtract (CURV, MAXV), Local2) ShiftLeft (Local2, 0x01, Local2) And (OVID, 0x01, Local3) Or (Local2, Local3, Local2) Store (Local2, Index (CPUV, 0x02)) Store (ShiftLeft (MAXV, 0x01), Local2) Subtract (0x3D09, Multiply (Local2, 0x7D), Index (OC09, 0x03)) Subtract (0x3D, Local2, Index (OC09, 0x04)) Return (CPUV) } Store (DerefOf (Index (OC0A, 0x00)), Local1) If (LEqual (Arg0, Local1)) { Store (DDRV, Index (DDVO, 0x02)) Return (DDVO) } Store (DerefOf (Index (OC0B, 0x00)), Local1) If (LEqual (Arg0, Local1)) { Store (AITU, Index (AIOT, 0x02)) Return (AIOT) } Store (DerefOf (Index (OC0C, 0x00)), Local1) If (LEqual (Arg0, Local1)) { Store (CCAQ, Index (ACAQ, 0x02)) Return (ACAQ) } } Name (CPUO, Package (0x04) { 0x01010000, 0x4E20, 0x00, 0x01 }) Name (CPUM, Package (0x04) { 0x01060001, 0x00, 0x00, 0x00 }) Name (CPFV, Package (0x06) { 0x01060002, 0x00, 0x00, 0x00, "Auto", "Manual" }) Name (PCIV, Package (0x04) { 0x07010003, 0x2710, 0x64, 0x00 }) Name (OCPR, Package (0x09) { 0x05050004, 0x00, 0x00, 0x00, "Overclock 1%", "Overclock 3%", "Overclock 5%", "Overclock 8%", "Overclock 10%" }) Name (NOSP, Package (0x09) { 0x08050005, 0x00, 0x00, 0x01, "Overclock 1%", "Overclock 3%", "Overclock 5%", "Overclock 8%", "Overclock 10%" }) Name (NOSM, Package (0x08) { 0x08060006, 0x00, 0x00, 0x00, "Auto", "Standard%", "Sensitive", "Heavy Load" }) Name (FANB, Package (0x06) { 0x04040007, 0x00, 0x00, 0x01, "Disabled", "Enabled" }) Name (CPUV, Package (0x04) { 0x01020008, 0x00, 0x00, 0x01 }) Name (DDVO, Package (0x0E) { 0x02020009, 0x00, 0x00, 0x01, "Auto", "2.60V", "2.65V", "2.70V", "2.75V", "2.80V", "2.85V", "2.90V", "2.95V", "3.00V" }) Name (AIOT, Package (0x09) { 0x0906000C, 0x00, 0x00, 0x01, "Manual", "Auto", "Standard", "OverClock Profile", "AI NOS" }) Name (ACAQ, Package (0x06) { 0x0106000B, 0x00, 0x00, 0x00, "Enabled", "Disabled" }) Name (OCST, Package (0x0C) { Package (0x02) { 0x01010000, 0x01 }, Package (0x02) { 0x01060001, 0x01 }, Package (0x02) { 0x01060002, 0x01 }, Package (0x02) { 0x07010003, 0x01 }, Package (0x02) { 0x05050004, 0x01 }, Package (0x02) { 0x08050005, 0x01 }, Package (0x02) { 0x08060006, 0x01 }, Package (0x02) { 0x04060003, 0x01 }, Package (0x02) { 0x01020008, 0x01 }, Package (0x02) { 0x02020009, 0x01 }, Package (0x02) { 0x0906000C, 0x01 }, Package (0x02) { 0x0106000B, 0x01 } }) Method (PROC, 3, NotSerialized) { Store (DerefOf (Index (OC01, 0x00)), Local1) If (LEqual (Arg0, Local1)) { Store (Arg1, Local2) Add (Local2, 0xC8, Local2) If (LEqual (Arg2, 0x00)) { If (LNot (LGreater (AITU, 0x03))) { If (LNot (LLess (FSBF, Local2))) { Subtract (FSBF, Local2, Local0) } Else { Subtract (Local2, FSBF, Local0) } If (LGreater (Local0, 0x0A)) { Store (0x03, Index (DerefOf (Index (OCST, 0x00)), 0x01)) Return (0x03) } Store (0x01, Index (DerefOf (Index (OCST, 0x00)), 0x01)) Return (0x01) } Else { Store (0x03, Index (DerefOf (Index (OCST, 0x00)), 0x01)) Return (0x03) } } If (LNot (LLess (FSBF, Local2))) { Subtract (FSBF, Local2, Local0) } Else { Subtract (Local2, FSBF, Local0) } Store (Local2, FSBF) If (LNot (LGreater (AITU, 0x03))) { Store (0x00, SMIS) Store (0xAB, SMIC) Store (0x00, AITU) Store (0x02, SMIS) Store (0xAB, SMIC) If (LGreater (Local0, 0x0A)) { Store (0x03, Index (DerefOf (Index (OCST, 0x00)), 0x01)) Return (0x03) } Store (0xAA, SMIS) Store (0xAB, SMIC) Store (0x01, Index (DerefOf (Index (OCST, 0x00)), 0x01)) Return (0x01) } Store (0x00, SMIS) Store (0xAB, SMIC) Store (0x00, AITU) Store (0x02, SMIS) Store (0xAB, SMIC) Store (0x03, Index (DerefOf (Index (OCST, 0x00)), 0x01)) Return (0x03) } Store (DerefOf (Index (OC02, 0x00)), Local1) If (LEqual (Arg0, Local1)) { If (LEqual (Arg2, 0x00)) { Store (0x03, Index (DerefOf (Index (OCST, 0x01)), 0x01)) Return (0x03) } If (LEqual (CCQA, 0x00)) { Store (0x01, CCAQ) Store (0x0C, SMIS) Store (0xAB, SMIC) Store (0x01, FVCM) Store (0x01, SMIS) Store (0xAB, SMIC) Store (ShiftLeft (Subtract (Arg1, 0x04), 0x01), FIDV) Store (0x03, SMIS) Store (0xAB, SMIC) Store (0x03, Index (DerefOf (Index (OCST, 0x01)), 0x01)) Return (0x03) } If (LEqual (FVCM, 0x00)) { Store (0x01, FVCM) Store (0x01, SMIS) Store (0xAB, SMIC) Store (ShiftLeft (Subtract (Arg1, 0x04), 0x01), FIDV) Store (0x03, SMIS) Store (0xAB, SMIC) Store (0x03, Index (DerefOf (Index (OCST, 0x01)), 0x01)) Return (0x03) } Store (ShiftLeft (Subtract (Arg1, 0x04), 0x01), FIDV) Store (0x03, SMIS) Store (0xAB, SMIC) Store (0x03, Index (DerefOf (Index (OCST, 0x01)), 0x01)) Return (0x03) } Store (DerefOf (Index (OC03, 0x00)), Local1) If (LEqual (Arg0, Local1)) { If (LEqual (Arg2, 0x00)) { Store (0x03, Index (DerefOf (Index (OCST, 0x02)), 0x01)) Return (0x03) } If (LEqual (CCAQ, 0x00)) { Store (0x01, CCAQ) Store (0x0C, SMIS) Store (0xAB, SMIC) Store (Arg1, FVCM) Store (0x01, SMIS) Store (0xAB, SMIC) Store (0x03, Index (DerefOf (Index (OCST, 0x02)), 0x01)) Return (0x03) } Store (Arg1, FVCM) Store (0x01, SMIS) Store (0xAB, SMIC) Store (0x03, Index (DerefOf (Index (OCST, 0x02)), 0x01)) Return (0x03) } Store (DerefOf (Index (OC04, 0x00)), Local1) If (LEqual (Arg0, Local1)) { Store (0x03, Index (DerefOf (Index (OCST, 0x03)), 0x01)) Return (0x03) } Store (DerefOf (Index (OC05, 0x00)), Local1) If (LEqual (Arg0, Local1)) { If (LEqual (Arg2, 0x00)) { If (LNot (LGreater (AITU, 0x03))) { Store (0x01, Index (DerefOf (Index (OCST, 0x04)), 0x01)) Return (0x01) } Store (0x03, Index (DerefOf (Index (OCST, 0x04)), 0x01)) Return (0x03) } If (LNot (LGreater (AITU, 0x03))) { Store (0x03, AITU) Store (0x02, SMIS) Store (0xAB, SMIC) Store (Arg1, OCPI) Store (0x05, SMIS) Store (0xAB, SMIC) If (LEqual (Arg1, 0x00)) { Store (0xCA, FSBF) Store (0x00, SMIS) Store (0xAB, SMIC) } If (LEqual (Arg1, 0x01)) { Store (0xCE, FSBF) Store (0x00, SMIS) Store (0xAB, SMIC) } If (LEqual (Arg1, 0x02)) { Store (0xD2, FSBF) Store (0x00, SMIS) Store (0xAB, SMIC) } If (LEqual (Arg1, 0x03)) { Store (0xD8, FSBF) Store (0x00, SMIS) Store (0xAB, SMIC) } If (LEqual (Arg1, 0x04)) { Store (0xDC, FSBF) Store (0x00, SMIS) Store (0xAB, SMIC) } Store (0xAA, SMIS) Store (0xAB, SMIC) Store (0x01, Index (DerefOf (Index (OCST, 0x04)), 0x01)) Return (0x01) } Store (0x03, AITU) Store (0x02, SMIS) Store (0xAB, SMIC) Store (Arg1, OCPI) Store (0x05, SMIS) Store (0xAB, SMIC) Store (0x03, Index (DerefOf (Index (OCST, 0x04)), 0x01)) Return (0x03) } Store (DerefOf (Index (OC06, 0x00)), Local1) If (LEqual (Arg0, Local1)) { If (LEqual (Arg2, 0x00)) { If (LNot (LGreater (AITU, 0x03))) { Store (0x03, Index (DerefOf (Index (OCST, 0x05)), 0x01)) Return (0x03) } If (LEqual (Arg1, 0x00)) { Store (0x03, Index (DerefOf (Index (OCST, 0x05)), 0x01)) Return (0x03) } Store (0x01, Index (DerefOf (Index (OCST, 0x05)), 0x01)) Return (0x01) } If (LNot (LGreater (AITU, 0x03))) { Store (0x04, AITU) Store (0x02, SMIS) Store (0xAB, SMIC) Store (Arg1, NOS1) Store (0x07, SMIS) Store (0xAB, SMIC) Store (0x03, Index (DerefOf (Index (OCST, 0x05)), 0x01)) Return (0x03) } If (LEqual (Arg1, 0x00)) { Store (0x01, AITU) Store (0x02, SMIS) Store (0xAB, SMIC) Store (Arg1, NOS1) Store (0x07, SMIS) Store (0xAB, SMIC) Store (0x03, Index (DerefOf (Index (OCST, 0x05)), 0x01)) Return (0x03) } Store (Arg1, NOS1) Store (0x07, SMIS) Store (0xAB, SMIC) Store (0x01, Index (DerefOf (Index (OCST, 0x05)), 0x01)) Return (0x01) } Store (DerefOf (Index (OC07, 0x00)), Local1) If (LEqual (Arg0, Local1)) { Store (0x01, Index (DerefOf (Index (OCST, 0x06)), 0x01)) Return (0x01) } Store (DerefOf (Index (OC08, 0x00)), Local1) If (LEqual (Arg0, Local1)) { If (LEqual (Arg2, 0x00)) { Store (0x01, Index (DerefOf (Index (OCST, 0x07)), 0x01)) Return (0x01) } Store (Arg1, CPUS) Store (0x09, SMIS) Store (0xAB, SMIC) Store (0xBB, SMIS) Store (0xAB, SMIC) Store (0x01, Index (DerefOf (Index (OCST, 0x07)), 0x01)) Return (0x01) } Store (DerefOf (Index (OC09, 0x00)), Local1) If (LEqual (Arg0, Local1)) { If (LEqual (Arg2, 0x00)) { Store (0x03, Index (DerefOf (Index (OCST, 0x08)), 0x01)) Return (0x03) } Store (CURF, FIDV) Store (0x03, SMIS) Store (0xAB, SMIC) Store (0x01, CCAQ) Store (0x0C, SMIS) Store (0xAB, SMIC) Store (0x01, FVCM) Store (0x01, SMIS) Store (0xAB, SMIC) Store (Add (Arg1, ShiftLeft (MAXV, 0x01)), OVID) Store (0x0B, SMIS) Store (0xAB, SMIC) Store (ShiftRight (Add (Arg1, ShiftLeft (MAXV, 0x01)), 0x01), VIDV) Store (0x04, SMIS) Store (0xAB, SMIC) Store (0x03, Index (DerefOf (Index (OCST, 0x08)), 0x01)) Return (0x03) } Store (DerefOf (Index (OC0A, 0x00)), Local1) If (LEqual (Arg0, Local1)) { If (LEqual (Arg2, 0x00)) { Store (0x01, Index (DerefOf (Index (OCST, 0x09)), 0x01)) Return (0x01) } If (LEqual (Arg1, DDRV)) { Store (0x01, Index (DerefOf (Index (OCST, 0x09)), 0x01)) Return (0x01) } Store (Arg1, DDRV) Store (0x08, SMIS) Store (0xAB, SMIC) Store (DerefOf (Index (DDRT, Arg1)), QDDR) Store (0x01, Index (DerefOf (Index (OCST, 0x09)), 0x01)) Return (0x01) } Store (DerefOf (Index (OC0B, 0x00)), Local1) If (LEqual (Arg0, Local1)) { If (LEqual (Arg2, 0x00)) { If (LNot (LEqual (Arg1, AITU))) { Store (0x03, Index (DerefOf (Index (OCST, 0x0A)), 0x01)) Return (0x03) } Store (0x01, Index (DerefOf (Index (OCST, 0x0A)), 0x01)) Return (0x01) } If (LNot (LEqual (Arg1, AITU))) { Store (Arg1, AITU) Store (0x02, SMIS) Store (0xAB, SMIC) Store (0x03, Index (DerefOf (Index (OCST, 0x0A)), 0x01)) Return (0x03) } Store (Arg1, AITU) Store (0x02, SMIS) Store (0xAB, SMIC) Store (0x01, Index (DerefOf (Index (OCST, 0x0A)), 0x01)) Return (0x01) } Store (DerefOf (Index (OC0C, 0x00)), Local1) If (LEqual (Arg0, Local1)) { If (LEqual (Arg2, 0x00)) { If (LEqual (Arg1, CCAQ)) { Store (0x01, Index (DerefOf (Index (OCST, 0x0B)), 0x01)) Return (0x01) } Store (0x03, Index (DerefOf (Index (OCST, 0x0B)), 0x01)) Return (0x03) } If (LEqual (Arg1, CCAQ)) { Store (0x01, Index (DerefOf (Index (OCST, 0x0B)), 0x01)) Return (0x01) } Store (Arg1, CCAQ) Store (0x09, SMIS) Store (0xAB, SMIC) Store (0x03, Index (DerefOf (Index (OCST, 0x0B)), 0x01)) Return (0x03) } } Method (GETM, 1, NotSerialized) { Multiply (Add (Arg0, 0x01), 0x03E8, Local0) Store (0xFFFF, Local6) Store (0x10, Local1) While (LNot (LGreater (Local1, 0x80))) { Store (0x10, Local2) While (LNot (LGreater (Local2, 0x80))) { Store (Divide (Multiply (Local2, 0x0005E9AC), Multiply (Local1, 0x04), ), Local3) Multiply (Local3, 0x02, Local3) If (LGreater (Local3, Local0)) { Store (Subtract (Local3, Local0), Local3) } Else { Store (Subtract (Local0, Local3), Local3) } If (LLess (Local3, Local6)) { Store (Local1, Local4) Store (Local2, Local5) Store (Local3, Local6) } Increment (Local2) } Increment (Local1) } ShiftLeft (Local5, 0x08, Local1) Or (Local1, Local4, Local6) And (Local6, 0xFFFF, Local6) Return (Local6) } } Device (\_SB.PCI0.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 (\_PR) { Processor (CPU1, 0x01, 0x00005010, 0x06) { Name (_PCT, Package (0x02) { ResourceTemplate () { Register (FFixedHW, 0x00, 0x00, 0x0000000000000000) }, ResourceTemplate () { Register (FFixedHW, 0x00, 0x00, 0x0000000000000000) } }) Name (_PSS, Package (0x04) { Package (0x06) { 0x00000898, 0x000105B8, 0x00000064, 0x00000007, 0xE020298E, 0x0000018E }, Package (0x06) { 0x000007D0, 0x0000DAC0, 0x00000064, 0x00000007, 0xE0202A0C, 0x0000020C }, Package (0x06) { 0x00000708, 0x0000B3B0, 0x00000064, 0x00000007, 0xE0202A8A, 0x0000028A }, Package (0x06) { 0x000003E8, 0x00004E20, 0x00000064, 0x00000007, 0xE0202C82, 0x00000482 } }) Name (PSXG, Buffer (0x18) { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }) Name (PSXF, Buffer (0x18) { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }) Name (PSXE, Buffer (0x18) { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }) Name (PSXD, Buffer (0x18) { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }) Name (PSXC, Buffer (0x18) { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }) Name (PSXB, Buffer (0x18) { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }) Method (_PPC, 0, NotSerialized) { Return (0x00) } } Processor (CPU2, 0x02, 0x00000000, 0x00) { Name (APCT, Package (0x02) { ResourceTemplate () { Register (FFixedHW, 0x00, 0x00, 0x0000000000000000) }, ResourceTemplate () { Register (FFixedHW, 0x00, 0x00, 0x0000000000000000) } }) Name (APSS, Package (0x0A) { Package (0x06) { 0x09999999, 0x00099999, 0x00999999, 0x00999999, 0x99999999, 0x99999999 }, Package (0x06) { 0x09999999, 0x00099999, 0x00999999, 0x00999999, 0x99999999, 0x99999999 }, Package (0x06) { 0x09999999, 0x00099999, 0x00999999, 0x00999999, 0x99999999, 0x99999999 }, Package (0x06) { 0x09999999, 0x00099999, 0x00999999, 0x00999999, 0x99999999, 0x99999999 }, Package (0x06) { 0x09999999, 0x00099999, 0x00999999, 0x00999999, 0x99999999, 0x99999999 }, Package (0x06) { 0x09999999, 0x00099999, 0x00999999, 0x00999999, 0x99999999, 0x99999999 }, Package (0x06) { 0x09999999, 0x00099999, 0x00999999, 0x00999999, 0x99999999, 0x99999999 }, Package (0x06) { 0x09999999, 0x00099999, 0x00999999, 0x00999999, 0x99999999, 0x99999999 }, Package (0x06) { 0x09999999, 0x00099999, 0x00999999, 0x00999999, 0x99999999, 0x99999999 }, Package (0x06) { 0x09999999, 0x00099999, 0x00999999, 0x00999999, 0x99999999, 0x99999999 } }) Method (APPC, 0, NotSerialized) { Return (0x00) } } } Device (OMSC) { Name (_HID, EisaId ("PNP0C02")) Name (_UID, 0x00) 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 (\_SB.RMEM) { Name (_HID, EisaId ("PNP0C01")) Name (_UID, 0x01) 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) Add (MG2B, MG2L, BAS4) Subtract (0x00, BAS4, LEN4) Return (CRS) } } Device (PS2K) { Name (_HID, EisaId ("PNP0303")) Name (_CID, 0x0B03D041) Method (_STA, 0, NotSerialized) { ShiftLeft (0x01, 0x0A, Local0) If (And (IOST, Local0)) { Return (0x0F) } Return (0x00) } Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0060, 0x0060, 0x00, 0x01) IO (Decode16, 0x0064, 0x0064, 0x00, 0x01) IRQNoFlags () {1} }) } Method (PS2K._PRW, 0, NotSerialized) { Return (GPRW (0x10, 0x04)) } Device (PS2M) { Name (_HID, EisaId ("PNP0F03")) Name (_CID, 0x130FD041) Method (_STA, 0, NotSerialized) { ShiftLeft (0x01, 0x0C, Local0) If (And (IOST, Local0)) { Return (0x0F) } Return (0x00) } Name (CRS1, ResourceTemplate () { IRQNoFlags () {12} }) Name (CRS2, ResourceTemplate () { IO (Decode16, 0x0060, 0x0060, 0x00, 0x01) IO (Decode16, 0x0064, 0x0064, 0x00, 0x01) IRQNoFlags () {12} }) Method (_CRS, 0, NotSerialized) { ShiftLeft (0x01, 0x0A, Local0) If (And (IOST, Local0)) { Return (CRS1) } Else { Return (CRS2) } } } Method (PS2M._PRW, 0, NotSerialized) { Return (GPRW (0x10, 0x04)) } Device (UAR1) { Name (_UID, 0x01) Method (_HID, 0, NotSerialized) { Return (UHID (0x00)) } Method (_STA, 0, NotSerialized) { Return (DSTA (0x00)) } Method (_DIS, 0, NotSerialized) { DCNT (0x00, 0x00) } Method (_CRS, 0, NotSerialized) { Return (DCRS (0x00, 0x01)) } Method (_SRS, 1, NotSerialized) { DSRS (Arg0, 0x00) } Method (_PRS, 0, NotSerialized) { Return (CMPR) } Name (CMPR, ResourceTemplate () { StartDependentFn (0x00, 0x00) { IO (Decode16, 0x03F8, 0x03F8, 0x01, 0x08) IRQNoFlags () {4} DMA (Compatibility, NotBusMaster, Transfer8) {} } StartDependentFnNoPri () { IO (Decode16, 0x03F8, 0x03F8, 0x01, 0x08) IRQNoFlags () {3,4,5,6,7,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8) {} } StartDependentFnNoPri () { IO (Decode16, 0x02F8, 0x02F8, 0x01, 0x08) IRQNoFlags () {3,4,5,6,7,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8) {} } StartDependentFnNoPri () { IO (Decode16, 0x03E8, 0x03E8, 0x01, 0x08) IRQNoFlags () {3,4,5,6,7,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8) {} } StartDependentFnNoPri () { IO (Decode16, 0x02E8, 0x02E8, 0x01, 0x08) IRQNoFlags () {3,4,5,6,7,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8) {} } StartDependentFnNoPri () { IO (Decode16, 0x03F8, 0x03F8, 0x01, 0x08) IRQNoFlags () {3,4,5,6,7,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8) {0,1,2,3} } StartDependentFnNoPri () { IO (Decode16, 0x02F8, 0x02F8, 0x01, 0x08) IRQNoFlags () {3,4,5,6,7,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8) {0,1,2,3} } StartDependentFnNoPri () { IO (Decode16, 0x03E8, 0x03E8, 0x01, 0x08) IRQNoFlags () {3,4,5,6,7,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8) {0,1,2,3} } StartDependentFnNoPri () { IO (Decode16, 0x02E8, 0x02E8, 0x01, 0x08) IRQNoFlags () {3,4,5,6,7,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8) {0,1,2,3} } EndDependentFn () }) } Method (UAR1._PRW, 0, NotSerialized) { Return (GPRW (0x03, 0x04)) } Device (SIOR) { Name (_HID, EisaId ("PNP0C02")) Method (_UID, 0, NotSerialized) { Return (SPIO) } Name (CRS, ResourceTemplate () { IO (Decode16, 0x0000, 0x0000, 0x00, 0x00) IO (Decode16, 0x0000, 0x0000, 0x00, 0x00) IO (Decode16, 0x0000, 0x0000, 0x00, 0x00) IO (Decode16, 0x0000, 0x0000, 0x00, 0x00) IO (Decode16, 0x0000, 0x0000, 0x00, 0x00) }) Method (_CRS, 0, NotSerialized) { If (LAnd (LNot (LEqual (SPIO, 0x03F0)), LGreater (SPIO, 0xF0))) { CreateWordField (CRS, 0x02, GP10) CreateWordField (CRS, 0x04, GP11) CreateByteField (CRS, 0x07, GPL1) Store (SPIO, GP10) Store (SPIO, GP11) Store (0x02, GPL1) } If (IOPB) { CreateWordField (CRS, 0x0A, GP20) CreateWordField (CRS, 0x0C, GP21) CreateByteField (CRS, 0x0F, GPL2) Store (IOPB, GP20) Store (IOPB, GP21) Store (IOPL, GPL2) } If (IOEB) { CreateWordField (CRS, 0x12, GP30) CreateWordField (CRS, 0x14, GP31) CreateByteField (CRS, 0x17, GPL3) Store (IOEB, GP30) Store (IOEB, GP31) Store (IOEL, GPL3) } If (IOGB) { CreateWordField (CRS, 0x1A, GP40) CreateWordField (CRS, 0x1C, GP41) CreateByteField (CRS, 0x1F, GPL4) Store (IOGB, GP40) Store (IOGB, GP41) Store (IOGL, GPL4) } If (IODB) { CreateWordField (CRS, 0x22, GP50) CreateWordField (CRS, 0x24, GP51) CreateByteField (CRS, 0x27, GPL5) Store (IODB, GP50) Store (IODB, GP51) Store (IODL, GPL5) } Return (CRS) } } Name (DCAT, Package (0x16) { 0x01, 0x02, 0x03, 0x00, 0xFF, 0x08, 0xFF, 0xFF, 0x09, 0xFF, 0x05, 0x04, 0xFF, 0xFF, 0xFF, 0xFF, 0x0A, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF }) Name (IKEY, Package (0x02) { Package (0x04) { 0x87, 0x01, 0x55, 0x55 }, Package (0x04) { 0x87, 0x01, 0x55, 0xAA } }) Name (KBFG, 0x01) Name (MSFG, 0x01) Name (UR1F, 0x01) Method (ENFG, 1, NotSerialized) { Store (0x00, Local1) If (LEqual (SPIO, 0x2E)) { Store (0x00, Local1) } If (LEqual (SPIO, 0x4E)) { Store (0x01, Local1) } Store (0x00, Local0) While (LNot (LEqual (Local0, 0x04))) { Store (DerefOf (Index (DerefOf (Index (IKEY, Local1)), Local0)), INDX) Increment (Local0) } Store (Arg0, LDN) } Method (ENTR, 0, NotSerialized) { Store (0x87, INDX) Store (0x01, INDX) Store (0x55, INDX) If (LEqual (SPIO, 0x2E)) { Store (0x55, INDX) } Else { Store (0xAA, INDX) } } Method (EXFG, 0, NotSerialized) { Store (0x02, INDX) Store (0x02, DATA) } Method (LPTM, 1, NotSerialized) { ENFG (CGLD (Arg0)) And (OPT0, 0x02, Local0) EXFG () Return (Local0) } Method (UHID, 1, NotSerialized) { ENFG (CGLD (Arg0)) And (OPT0, 0x70, Local0) EXFG () If (Local0) { Return (0x1005D041) } Return (0x0105D041) } Method (ORF0, 1, NotSerialized) { ENTR () Or (OPT0, Arg0, OPT0) EXFG () } Method (ORF1, 1, NotSerialized) { ENTR () Or (OPT1, Arg0, OPT1) EXFG () } Method (ORF2, 1, NotSerialized) { ENTR () Or (OPT2, Arg0, OPT2) EXFG () } Method (ANF0, 1, NotSerialized) { ENTR () And (OPT0, Arg0, OPT0) EXFG () } Method (ANF2, 1, NotSerialized) { ENTR () And (OPT2, Arg0, OPT2) EXFG () } Method (ANF4, 1, NotSerialized) { ENTR () And (OPT4, Arg0, OPT4) EXFG () } Method (STF0, 1, NotSerialized) { ENTR () Store (Arg0, OPT0) EXFG () } Method (STF1, 1, NotSerialized) { ENTR () Store (Arg0, OPT1) EXFG () } Method (SIOS, 1, NotSerialized) { Store ("SIOS", Debug) Store (0x00, GP10) If (LLess (Arg0, 0x05)) { ENFG (0x04) Store (0x01, ACTR) EXFG () ANF4 (0xFC) ORF1 (0x18) If (KBFG) { ORF0 (0x08) } Else { ANF0 (0xF7) } If (MSFG) { ORF0 (0x10) } Else { ANF0 (0xEF) ENFG (0x06) Store (0x00, ACTR) EXFG () } ENFG (0x04) ANF2 (0xF0) ENFG (0x07) And (OPF9, 0xFE, OPF9) And (OPC0, 0xFE, OPC0) And (OPC3, 0xFE, OPC3) And (OP29, 0xEF, OP29) EXFG () } Else { ENFG (0x07) And (OPC0, 0x00, OPC0) Or (OPC0, 0x01, OPC0) And (OPC3, 0x00, OPC3) Or (OPC3, 0x01, OPC3) Or (OPF9, 0x01, OPF9) And (OP29, 0xEF, OP29) EXFG () } } Method (SIOW, 1, NotSerialized) { Store (0x01, GP10) Store (0x01, GP40) Store ("SIOW", Debug) ENFG (0x04) Store (0x00, ACTR) EXFG () STF0 (0x00) STF1 (0xFF) ENFG (0x07) Or (OP29, 0x10, OP29) Or (OPC0, 0x01, OPC0) Or (OPC3, 0x01, OPC3) EXFG () ENFG (0x05) Or (ACTR, 0x01, ACTR) EXFG () ENFG (0x06) Or (ACTR, 0x01, ACTR) EXFG () ENFG (0x04) Store (0x01, ACTR) EXFG () } Method (SIOH, 0, NotSerialized) { Store ("SIOH", Debug) } OperationRegion (IOID, SystemIO, SPIO, 0x02) Field (IOID, ByteAcc, NoLock, Preserve) { INDX, 8, DATA, 8 } IndexField (INDX, DATA, ByteAcc, NoLock, Preserve) { Offset (0x07), LDN, 8, Offset (0x29), OP29, 8, Offset (0x30), ACTR, 8, Offset (0x60), IOAH, 8, IOAL, 8, IOH2, 8, IOL2, 8, Offset (0x70), INTR, 8, Offset (0x74), DMCH, 8, Offset (0xC0), OPC0, 8, OPC1, 8, OPC2, 8, OPC3, 8, Offset (0xF0), OPT0, 8, OPT1, 8, OPT2, 8, OPT3, 8, OPT4, 8, Offset (0xF8), OPF8, 8, OPF9, 8, OPFA, 8, OPFB, 8 } Method (PS2K._PSW, 1, NotSerialized) { If (Arg0) { Store (0x01, KBFG) } Else { Store (0x00, KBFG) } } Method (PS2M._PSW, 1, NotSerialized) { If (Arg0) { Store (0x01, MSFG) } Else { Store (0x00, MSFG) } } Method (CGLD, 1, NotSerialized) { Return (DerefOf (Index (DCAT, Arg0))) } Method (DSTA, 1, NotSerialized) { ENFG (CGLD (Arg0)) Store (ACTR, Local0) EXFG () If (LEqual (Local0, 0xFF)) { Return (0x00) } And (Local0, 0x01, Local0) Or (IOST, ShiftLeft (Local0, Arg0), IOST) If (Local0) { Return (0x0F) } Else { If (And (ShiftLeft (0x01, Arg0), IOST)) { Return (0x0D) } Else { Return (0x00) } } } Method (DCNT, 2, NotSerialized) { ENFG (CGLD (Arg0)) ShiftLeft (IOAH, 0x08, Local1) Or (IOAL, Local1, Local1) RRIO (Arg0, Arg1, Local1, 0x08) If (LAnd (LLess (DMCH, 0x04), LNot (LEqual (And (DMCH, 0x03, Local1), 0x00)))) { RDMA (Arg0, Arg1, Increment (Local1)) } Store (Arg1, ACTR) EXFG () } Name (CRS1, ResourceTemplate () { IO (Decode16, 0x0000, 0x0000, 0x01, 0x00) IRQNoFlags () {} DMA (Compatibility, NotBusMaster, Transfer8) {} }) CreateWordField (CRS1, 0x09, IRQM) CreateByteField (CRS1, 0x0C, DMAM) CreateWordField (CRS1, 0x02, IO11) CreateWordField (CRS1, 0x04, IO12) CreateByteField (CRS1, 0x07, LEN1) Name (CRS2, ResourceTemplate () { IO (Decode16, 0x0000, 0x0000, 0x01, 0x00) IO (Decode16, 0x0000, 0x0000, 0x01, 0x00) IRQNoFlags () {6} DMA (Compatibility, NotBusMaster, Transfer8) {2} }) CreateWordField (CRS2, 0x11, IRQE) CreateByteField (CRS2, 0x14, DMAE) CreateWordField (CRS2, 0x02, IO21) CreateWordField (CRS2, 0x04, IO22) CreateByteField (CRS2, 0x07, LEN2) CreateWordField (CRS2, 0x0A, IO31) CreateWordField (CRS2, 0x0C, IO32) CreateByteField (CRS2, 0x0F, LEN3) Method (DCRS, 2, NotSerialized) { ENFG (CGLD (Arg0)) ShiftLeft (IOAH, 0x08, IO11) Or (IOAL, IO11, IO11) Store (IO11, IO12) Subtract (FindSetRightBit (IO11), 0x01, Local0) ShiftLeft (0x01, Local0, LEN1) If (INTR) { ShiftLeft (0x01, INTR, IRQM) } Else { Store (0x00, IRQM) } If (LOr (LGreater (DMCH, 0x03), LEqual (Arg1, 0x00))) { Store (0x00, DMAM) } Else { And (DMCH, 0x03, Local1) ShiftLeft (0x01, Local1, DMAM) } EXFG () Return (CRS1) } Method (DSRS, 2, NotSerialized) { CreateWordField (Arg0, 0x09, IRQM) CreateByteField (Arg0, 0x0C, DMAM) CreateWordField (Arg0, 0x02, IO11) ENFG (CGLD (Arg1)) And (IO11, 0xFF, IOAL) ShiftRight (IO11, 0x08, IOAH) If (IRQM) { FindSetRightBit (IRQM, Local0) Subtract (Local0, 0x01, INTR) } Else { Store (0x00, INTR) } If (DMAM) { FindSetRightBit (DMAM, Local0) Subtract (Local0, 0x01, DMCH) } Else { Store (0x04, DMCH) } EXFG () DCNT (Arg1, 0x01) } OperationRegion (GPIO, SystemIO, IO1B, 0x04) Field (GPIO, ByteAcc, NoLock, Preserve) { GP10, 1, GP11, 1, GP12, 1, GP13, 1, GO14, 1, GO15, 1, GO16, 1, GO17, 1, GP20, 1, GP21, 1, GP22, 1, GP23, 1, GO24, 1, GO25, 1, GO26, 1, GO27, 1, GP30, 1, GP31, 1, GP32, 1, GP33, 1, GO34, 1, GO35, 1, GO36, 1, GO37, 1, GP40, 1, GP41, 1, GP42, 1, GP43, 1, GO44, 1, GO45, 1, GO46, 1, GO47, 1 } } Device (NSMB) { Name (_ADR, 0x000A0001) Method (_PRW, 0, NotSerialized) { Return (GPRW (0x09, 0x04)) } } Device (USB0) { Name (_ADR, 0x000B0000) Name (_S1D, 0x01) Method (_S3D, 0, NotSerialized) { If (LOr (LEqual (OSFL (), 0x01), LEqual (OSFL (), 0x02))) { Return (0x02) } Else { Return (0x03) } } Method (_PRW, 0, NotSerialized) { Return (GPRW (0x0D, 0x04)) } } Device (USB2) { Name (_ADR, 0x000B0001) Name (_S1D, 0x01) Method (_S3D, 0, NotSerialized) { If (LOr (LEqual (OSFL (), 0x01), LEqual (OSFL (), 0x02))) { Return (0x02) } Else { Return (0x03) } } Method (_PRW, 0, NotSerialized) { Return (GPRW (0x05, 0x04)) } } Device (NMAC) { Name (_ADR, 0x00130000) Name (_PRW, Package (0x02) { 0x0B, 0x05 }) Scope (\_GPE) { Method (_L0B, 0, NotSerialized) { Notify (\_SB.PCI0.NMAC, 0x02) Notify (\_SB.PWRB, 0x02) } } } Device (IDE0) { Name (_ADR, 0x000F0000) Name (PTS0, 0x00) Name (SID0, 0x00) Name (SID1, 0x00) Name (SID2, 0x00) Name (SID3, 0x00) Name (SID4, 0x00) Name (SID5, 0x00) OperationRegion (IRQM, SystemIO, 0x21, 0x01) Field (IRQM, ByteAcc, NoLock, Preserve) { IR0M, 1 } Name (REGF, 0x01) Method (_REG, 2, NotSerialized) { If (LEqual (Arg0, 0x02)) { Store (Arg1, REGF) } } OperationRegion (A090, PCI_Config, 0x50, 0x18) Field (A090, DWordAcc, NoLock, Preserve) { ID20, 16, Offset (0x08), IDTS, 16, IDTP, 16, ID22, 32, UMSS, 16, UMSP, 16 } Name (TIM0, Package (0x07) { Package (0x05) { 0x3C, 0x78, 0xB4, 0xF0, 0x0384 }, Package (0x05) { 0x11, 0x20, 0x22, 0x47, 0xA8 }, Package (0x07) { 0x78, 0x5A, 0x3C, 0x2D, 0x1E, 0x14, 0x0F }, Package (0x05) { 0x05, 0x04, 0x03, 0x02, 0x00 }, Package (0x04) { 0x02, 0x01, 0x00, 0x00 }, Package (0x08) { 0x02, 0x01, 0x00, 0x00, 0x03, 0x04, 0x05, 0x06 }, Package (0x07) { 0x02, 0x01, 0x00, 0x04, 0x05, 0x06, 0x07 } }) Name (TMD0, Buffer (0x14) {}) CreateDWordField (TMD0, 0x00, PIO0) CreateDWordField (TMD0, 0x04, DMA0) CreateDWordField (TMD0, 0x08, PIO1) CreateDWordField (TMD0, 0x0C, DMA1) CreateDWordField (TMD0, 0x10, CHNF) OperationRegion (CFG2, PCI_Config, 0x58, 0x0C) Field (CFG2, DWordAcc, NoLock, Preserve) { SSPT, 8, SMPT, 8, PSPT, 8, PMPT, 8, SSAS, 2, SMAS, 2, PSAS, 2, PMAS, 2, Offset (0x06), SDDR, 4, SDDA, 4, PDDR, 4, PDDA, 4, SSUT, 3, , 3, SSUE, 2, SMUT, 3, , 3, SMUE, 2, PSUT, 3, , 3, PSUE, 2, PMUT, 3, , 3, PMUE, 2 } Name (GMPT, 0x00) Name (GMUE, 0x00) Name (GMUT, 0x00) Name (GSPT, 0x00) Name (GSUE, 0x00) Name (GSUT, 0x00) Device (CHN0) { Name (_ADR, 0x00) Method (_GTM, 0, NotSerialized) { Store ("GTM_CHN0", Debug) Return (GTM (PMPT, PMUE, PMUT, PSPT, PSUE, PSUT)) } Method (_STM, 3, NotSerialized) { Store ("STM_CHN0", Debug) Store (Arg0, Debug) Store (Arg0, TMD0) Store (PMPT, GMPT) Store (PMUE, GMUE) Store (PMUT, GMUT) Store (PSPT, GSPT) Store (PSUE, GSUE) Store (PSUT, GSUT) STM () Store (GMPT, PMPT) Store (GMUE, PMUE) Store (GMUT, PMUT) Store (GSPT, PSPT) Store (GSUE, PSUE) Store (GSUT, PSUT) Store (GTF (0x00, Arg1), ATA0) Store (GTF (0x01, Arg2), ATA1) } Device (DRV0) { Name (_ADR, 0x00) Method (_GTF, 0, NotSerialized) { Store ("_GTF_CHN0_DRV0", Debug) Return (RATA (ATA0)) } } Device (DRV1) { Name (_ADR, 0x01) Method (_GTF, 0, NotSerialized) { Store ("_GTF_CHN0_DRV1", Debug) Return (RATA (ATA1)) } } } Device (CHN1) { Name (_ADR, 0x01) Method (_GTM, 0, NotSerialized) { Store ("GTM_CHN1", Debug) Return (GTM (SMPT, SMUE, SMUT, SSPT, SSUE, SSUT)) } Method (_STM, 3, NotSerialized) { Store (Arg0, Debug) Store (Arg0, TMD0) Store (SMPT, GMPT) Store (SMUE, GMUE) Store (SMUT, GMUT) Store (SSPT, GSPT) Store (SSUE, GSUE) Store (SSUT, GSUT) STM () Store (GMPT, SMPT) Store (GMUE, SMUE) Store (GMUT, SMUT) Store (GSPT, SSPT) Store (GSUE, SSUE) Store (GSUT, SSUT) Store (GTF (0x00, Arg1), ATA2) Store (GTF (0x01, Arg2), ATA3) } Device (DRV0) { Name (_ADR, 0x00) Method (_GTF, 0, NotSerialized) { Store ("_GTF_CHN1_DRV0", Debug) Return (RATA (ATA2)) } } Device (DRV1) { Name (_ADR, 0x01) Method (_GTF, 0, NotSerialized) { Store ("_GTF_CHN1_DRV1", Debug) Return (RATA (ATA3)) } } } Method (DRMP, 0, NotSerialized) { ShiftRight (CPB0, 0x04, Local1) And (Local1, 0x0F, Local0) Return (Local0) } Method (GTM, 6, Serialized) { Store (Ones, PIO0) Store (Ones, PIO1) Store (Ones, DMA0) Store (Ones, DMA1) Store (0x10, CHNF) If (REGF) {} Else { Return (TMD0) } If (LEqual (PTS0, 0x01)) { If (OSFL ()) { Store (0x01, IR0M) } } Store (Match (DerefOf (Index (TIM0, 0x01)), MEQ, Arg0, MTR, 0x00, 0x00), Local6) Store (DerefOf (Index (DerefOf (Index (TIM0, 0x00)), Local6)), Local7) Store (Local7, DMA0) Store (Local7, PIO0) Store (Match (DerefOf (Index (TIM0, 0x01)), MEQ, Arg3, MTR, 0x00, 0x00), Local6) Store (DerefOf (Index (DerefOf (Index (TIM0, 0x00)), Local6)), Local7) Store (Local7, DMA1) Store (Local7, PIO1) If (Arg1) { Store (DerefOf (Index (DerefOf (Index (TIM0, 0x05)), Arg2)), Local5) Store (DerefOf (Index (DerefOf (Index (TIM0, 0x02)), Local5)), DMA0) Or (CHNF, 0x01, CHNF) } If (Arg4) { Store (DerefOf (Index (DerefOf (Index (TIM0, 0x05)), Arg5)), Local5) Store (DerefOf (Index (DerefOf (Index (TIM0, 0x02)), Local5)), DMA1) Or (CHNF, 0x04, CHNF) } Store (TMD0, Debug) Return (TMD0) } Method (STM, 0, Serialized) { If (REGF) {} Else { Return (0x00) } If (PTS0) { Store (SID0, ID20) Store (SID1, IDTS) Store (SID2, IDTP) Store (SID3, ID22) Store (SID4, UMSS) Store (SID5, UMSP) } Else { Store (ID20, SID0) Store (IDTS, SID1) Store (IDTP, SID2) Store (ID22, SID3) Store (UMSS, SID4) Store (UMSP, SID5) } Store (0x00, PTS0) Store (0x00, GMUE) Store (0x00, GMUT) Store (0x00, GSUE) Store (0x00, GSUT) If (And (CHNF, 0x01)) { Store (Match (DerefOf (Index (TIM0, 0x02)), MLE, DMA0, MTR, 0x00, 0x00), Local0) If (LGreater (Local0, 0x06)) { Store (0x06, Local0) } Store (DerefOf (Index (DerefOf (Index (TIM0, 0x06)), Local0)), GMUT) Or (GMUE, 0x03, GMUE) } Else { If (Or (LEqual (PIO0, Ones), LEqual (PIO0, 0x00))) { If (And (LLess (DMA0, Ones), LGreater (DMA0, 0x00))) { Store (DMA0, PIO0) } } } If (And (CHNF, 0x04)) { Store (Match (DerefOf (Index (TIM0, 0x02)), MLE, DMA1, MTR, 0x00, 0x00), Local0) If (LGreater (Local0, 0x06)) { Store (0x06, Local0) } Store (DerefOf (Index (DerefOf (Index (TIM0, 0x06)), Local0)), GSUT) Or (GSUE, 0x03, GSUE) } Else { If (Or (LEqual (PIO1, Ones), LEqual (PIO1, 0x00))) { If (And (LLess (DMA1, Ones), LGreater (DMA1, 0x00))) { Store (DMA1, PIO1) } } } And (Match (DerefOf (Index (TIM0, 0x00)), MGE, PIO0, MTR, 0x00, 0x00), 0x07, Local0) Store (DerefOf (Index (DerefOf (Index (TIM0, 0x01)), Local0)), Local1) Store (Local1, GMPT) And (Match (DerefOf (Index (TIM0, 0x00)), MGE, PIO1, MTR, 0x00, 0x00), 0x07, Local0) Store (DerefOf (Index (DerefOf (Index (TIM0, 0x01)), Local0)), Local1) Store (Local1, GSPT) Return (0x00) } 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, 0x00, 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 ("GTF_Entry", Debug) Store (Arg1, Debug) Store (0x00, CMDC) Name (ID49, 0x0C00) Name (ID59, 0x00) Name (ID53, 0x04) Name (ID63, 0x0F00) Name (ID88, 0x0F00) Name (IRDY, 0x01) Name (PIOT, 0x00) Name (DMAT, 0x00) 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, 0x01)) { Store (DMA0, DMAT) } } If (LAnd (LAnd (And (ID53, 0x04), And (ID88, 0xFF00)), DMAT)) { Store (Match (DerefOf (Index (TIM0, 0x02)), MLE, DMAT, MTR, 0x00, 0x00), Local1) If (LGreater (Local1, 0x06)) { Store (0x06, Local1) } GTFB (AT01, Or (0x40, Local1), Local7) } Else { If (LAnd (And (ID63, 0xFF00), PIOT)) { And (Match (DerefOf (Index (TIM0, 0x00)), MGE, PIOT, MTR, 0x00, 0x00), 0x03, Local0) Or (0x20, DerefOf (Index (DerefOf (Index (TIM0, 0x04)), Local0)), Local1) GTFB (AT01, Local1, Local7) } } If (IRDY) { And (Match (DerefOf (Index (TIM0, 0x00)), MGE, PIOT, MTR, 0x00, 0x00), 0x07, Local0) Or (0x08, DerefOf (Index (DerefOf (Index (TIM0, 0x03)), Local0)), Local1) GTFB (AT01, Local1, Local7) } Else { If (And (ID49, 0x0400)) { GTFB (AT01, 0x01, Local7) } } If (LAnd (And (ID59, 0x0100), And (ID59, 0xFF))) { GTFB (AT03, And (ID59, 0xFF), Local7) } Store ("ATAB_GTF", Debug) Store (ATAB, Debug) Return (ATAB) } Method (RATA, 1, NotSerialized) { CreateByteField (Arg0, 0x00, CMDN) Multiply (CMDN, 0x38, Local0) CreateField (Arg0, 0x08, Local0, RETB) Store (RETB, Debug) Return (RETB) } } Device (ATA0) { Name (_ADR, 0x00100000) Device (PRI0) { Name (_ADR, 0x00) Name (SPTM, Buffer (0x14) { 0x78, 0x00, 0x00, 0x00, 0x0F, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x13, 0x00, 0x00, 0x00 }) Method (_GTM, 0, NotSerialized) { Return (SPTM) } Method (_STM, 3, NotSerialized) { Store (Arg0, SPTM) } Device (MAST) { Name (_ADR, 0x00) Method (_GTF, 0, NotSerialized) { Store (Buffer (0x07) { 0x03, 0x46, 0x00, 0x00, 0x00, 0xA0, 0xEF }, Local0) Return (Local0) } } } Device (SEC0) { Name (_ADR, 0x01) Name (SSTM, Buffer (0x14) { 0x78, 0x00, 0x00, 0x00, 0x0F, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x13, 0x00, 0x00, 0x00 }) Method (_GTM, 0, NotSerialized) { Return (SSTM) } Method (_STM, 3, NotSerialized) { Store (Arg0, SSTM) } Device (MAST) { Name (_ADR, 0x00) Method (_GTF, 0, NotSerialized) { Store (Buffer (0x07) { 0x03, 0x46, 0x00, 0x00, 0x00, 0xA0, 0xEF }, Local0) Return (Local0) } } } Method (DRMP, 0, NotSerialized) { Store (0x0C, Local0) If (LEqual (_ADR, 0x00100000)) { Store (0x08, Local0) } ShiftRight (CPB0, Local0, Local1) And (Local1, 0x0F, Local0) Return (Local0) } } Device (ATA1) { Name (_ADR, 0x00110000) Device (PRI0) { Name (_ADR, 0x00) Name (SPTM, Buffer (0x14) { 0x78, 0x00, 0x00, 0x00, 0x0F, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x13, 0x00, 0x00, 0x00 }) Method (_GTM, 0, NotSerialized) { Return (SPTM) } Method (_STM, 3, NotSerialized) { Store (Arg0, SPTM) } Device (MAST) { Name (_ADR, 0x00) Method (_GTF, 0, NotSerialized) { Store (Buffer (0x07) { 0x03, 0x46, 0x00, 0x00, 0x00, 0xA0, 0xEF }, Local0) Return (Local0) } } } Device (SEC0) { Name (_ADR, 0x01) Name (SSTM, Buffer (0x14) { 0x78, 0x00, 0x00, 0x00, 0x0F, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x13, 0x00, 0x00, 0x00 }) Method (_GTM, 0, NotSerialized) { Return (SSTM) } Method (_STM, 3, NotSerialized) { Store (Arg0, SSTM) } Device (MAST) { Name (_ADR, 0x00) Method (_GTF, 0, NotSerialized) { Store (Buffer (0x07) { 0x03, 0x46, 0x00, 0x00, 0x00, 0xA0, 0xEF }, Local0) Return (Local0) } } } Method (DRMP, 0, NotSerialized) { Store (0x0C, Local0) If (LEqual (_ADR, 0x00100000)) { Store (0x08, Local0) } ShiftRight (CPB0, Local0, Local1) And (Local1, 0x0F, Local0) Return (Local0) } } Device (PB2P) { Name (_ADR, 0x00120000) Method (_PRW, 0, NotSerialized) { Return (GPRW (0x00, 0x04)) } Method (_PRT, 0, NotSerialized) { If (PICM) { Return (AR01) } Return (PR01) } } Device (MC97) { Name (_ADR, 0x000D0001) Method (_PRW, 0, NotSerialized) { Return (GPRW (0x07, 0x04)) } } Device (PCE0) { Name (_ADR, 0x00020000) Method (_PRW, 0, NotSerialized) { Return (GPRW (0x11, 0x04)) } Method (_PRT, 0, NotSerialized) { If (PICM) { Return (AR02) } Return (PR02) } } Device (PCE1) { Name (_ADR, 0x00030000) Method (_PRW, 0, NotSerialized) { Return (GPRW (0x11, 0x04)) } Method (_PRT, 0, NotSerialized) { If (PICM) { Return (AR03) } Return (PR03) } } Device (PCE2) { Name (_ADR, 0x00040000) Method (_PRW, 0, NotSerialized) { Return (GPRW (0x11, 0x04)) } Method (_PRT, 0, NotSerialized) { If (PICM) { Return (AR04) } Return (PR04) } } Device (PCE3) { Name (_ADR, 0x00170000) Method (_PRW, 0, NotSerialized) { Return (GPRW (0x11, 0x04)) } Method (_PRT, 0, NotSerialized) { If (PICM) { Return (AR05) } Return (PR05) } } Device (PCE4) { Name (_ADR, 0x00160000) Method (_PRW, 0, NotSerialized) { Return (GPRW (0x11, 0x04)) } Method (_PRT, 0, NotSerialized) { If (PICM) { Return (AR06) } Return (PR06) } } Device (PCE5) { Name (_ADR, 0x00150000) Method (_PRW, 0, NotSerialized) { Return (GPRW (0x11, 0x04)) } Method (_PRT, 0, NotSerialized) { If (PICM) { Return (AR07) } Return (PR07) } } } Scope (\_GPE) { Method (_L10, 0, NotSerialized) { \_SB.PCI0.SBRG.SIOH () Notify (\_SB.PWRB, 0x02) } Method (_L03, 0, NotSerialized) { \_SB.PCI0.SBRG.SIOH () Notify (\_SB.PWRB, 0x02) } Method (_L09, 0, NotSerialized) { Notify (\_SB.PCI0.NSMB, 0x02) Notify (\_SB.PWRB, 0x02) } Method (_L0D, 0, NotSerialized) { Notify (\_SB.PCI0.USB0, 0x02) Notify (\_SB.PWRB, 0x02) } Method (_L05, 0, NotSerialized) { Notify (\_SB.PCI0.USB2, 0x02) Notify (\_SB.PWRB, 0x02) } Method (_L00, 0, NotSerialized) { Notify (\_SB.PCI0.PB2P, 0x02) Notify (\_SB.PWRB, 0x02) } Method (_L07, 0, NotSerialized) { Notify (\_SB.PCI0.MC97, 0x02) Notify (\_SB.PWRB, 0x02) } Method (_L11, 0, NotSerialized) { Notify (\_SB.PCI0.PCE0, 0x02) Notify (\_SB.PCI0.PCE1, 0x02) Notify (\_SB.PCI0.PCE2, 0x02) Notify (\_SB.PCI0.PCE3, 0x02) Notify (\_SB.PCI0.PCE4, 0x02) Notify (\_SB.PCI0.PCE5, 0x02) Notify (\_SB.PWRB, 0x02) } } Device (PWRB) { Name (_HID, EisaId ("PNP0C0C")) Name (_UID, 0xAA) Name (_STA, 0x0B) Method (_PRW, 0, NotSerialized) { Return (GPRW (0x03, 0x04)) } } } OperationRegion (\_SB.PCI0.SBRG.PIMC, PCI_Config, 0x7C, 0x0C) Field (\_SB.PCI0.SBRG.PIMC, ByteAcc, NoLock, Preserve) { PIRA, 4, PIRB, 4, PIRC, 4, PIRD, 4, , 4, PIRF, 4, PIRG, 4, Offset (0x05), PIRM, 4, PIU2, 4, Offset (0x07), SIID, 4, PIID, 4, PIU0, 4, Offset (0x09), PILN, 4, Offset (0x0A), PAUI, 4, PIMO, 4, PR0E, 4, PR0F, 4 } Scope (\_SB) { Name (BUFA, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {15} }) CreateWordField (BUFA, 0x01, ICRS) Method (LSTA, 1, NotSerialized) { If (Arg0) { Return (0x0B) } Else { Return (0x09) } } Method (LPRS, 2, NotSerialized) { If (PICM) { Return (Arg1) } Else { Return (Arg0) } } Method (LCRS, 1, NotSerialized) { If (PICM) { Name (BUFB, ResourceTemplate () { Interrupt (ResourceConsumer, Level, ActiveLow, Shared) { 0x00000011, } }) CreateByteField (BUFB, 0x05, AIRQ) Store (Arg0, AIRQ) If (LEqual (Arg0, 0x01)) { Store (0x11, AIRQ) } If (LEqual (Arg0, 0x02)) { Store (0x12, AIRQ) } If (LEqual (Arg0, 0x08)) { Store (0x10, AIRQ) } If (LEqual (Arg0, 0x0D)) { Store (0x13, AIRQ) } Return (BUFB) } Else { ShiftLeft (0x01, Arg0, ICRS) Return (BUFA) } } Method (LCRO, 1, NotSerialized) { If (PICM) { Name (BUFB, ResourceTemplate () { Interrupt (ResourceConsumer, Level, ActiveLow, Shared) { 0x00000014, } }) CreateByteField (BUFB, 0x05, AIRQ) Store (Arg0, AIRQ) If (LEqual (Arg0, 0x01)) { Store (0x17, AIRQ) } If (LEqual (Arg0, 0x02)) { Store (0x16, AIRQ) } If (LEqual (Arg0, 0x08)) { Store (0x14, AIRQ) } If (LEqual (Arg0, 0x0D)) { Store (0x15, AIRQ) } Return (BUFB) } Else { ShiftLeft (0x01, Arg0, ICRS) Return (BUFA) } } Method (LSRS, 1, NotSerialized) { If (PICM) { CreateByteField (Arg0, 0x05, SAIR) Store (SAIR, Local0) If (LEqual (Local0, 0x10)) { Store (0x08, Local0) } If (LEqual (Local0, 0x11)) { Store (0x01, Local0) } If (LEqual (Local0, 0x12)) { Store (0x02, Local0) } If (LEqual (Local0, 0x13)) { Store (0x0D, Local0) } Return (Local0) } Else { CreateWordField (Arg0, 0x01, ISRS) FindSetRightBit (ISRS, Local0) Return (Decrement (Local0)) } } Method (LSRO, 1, NotSerialized) { If (PICM) { CreateByteField (Arg0, 0x05, SAIR) Store (SAIR, Local0) If (LEqual (Local0, 0x14)) { Store (0x08, Local0) } If (LEqual (Local0, 0x15)) { Store (0x0D, Local0) } If (LEqual (Local0, 0x16)) { Store (0x02, Local0) } If (LEqual (Local0, 0x17)) { Store (0x01, Local0) } Return (Local0) } Else { CreateWordField (Arg0, 0x01, ISRS) FindSetRightBit (ISRS, Local0) Return (Decrement (Local0)) } } Device (LNKA) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x01) Method (_STA, 0, NotSerialized) { Return (LSTA (PIRA)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (PRSA, RSIR)) } Method (_DIS, 0, NotSerialized) { Store (0x00, PIRA) } Method (_CRS, 0, NotSerialized) { Return (LCRS (PIRA)) } Method (_SRS, 1, NotSerialized) { Store (LSRS (Arg0), PIRA) } } Device (LNKB) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x02) Method (_STA, 0, NotSerialized) { Return (LSTA (PIRB)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (PRSB, RSIR)) } Method (_DIS, 0, NotSerialized) { Store (0x00, PIRB) } Method (_CRS, 0, NotSerialized) { Return (LCRS (PIRB)) } Method (_SRS, 1, NotSerialized) { Store (LSRS (Arg0), PIRB) } } Device (LNKC) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x03) Method (_STA, 0, NotSerialized) { Return (LSTA (PIRC)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (PRSC, RSIR)) } Method (_DIS, 0, NotSerialized) { Store (0x00, PIRC) } Method (_CRS, 0, NotSerialized) { Return (LCRS (PIRC)) } Method (_SRS, 1, NotSerialized) { Store (LSRS (Arg0), PIRC) } } Device (LNKD) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x04) Method (_STA, 0, NotSerialized) { Return (LSTA (PIRD)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (PRSD, RSIR)) } Method (_DIS, 0, NotSerialized) { Store (0x00, PIRD) } Method (_CRS, 0, NotSerialized) { Return (LCRS (PIRD)) } Method (_SRS, 1, NotSerialized) { Store (LSRS (Arg0), PIRD) } } Device (LUB0) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x05) Method (_STA, 0, NotSerialized) { Return (LSTA (PIU0)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (RSB0, RSII)) } Method (_DIS, 0, NotSerialized) { Store (0x00, PIU0) } Method (_CRS, 0, NotSerialized) { Return (LCRO (PIU0)) } Method (_SRS, 1, NotSerialized) { Store (LSRO (Arg0), PIU0) } } Device (LUB2) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x07) Method (_STA, 0, NotSerialized) { Return (LSTA (PIU2)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (RSB2, RSII)) } Method (_DIS, 0, NotSerialized) { Store (0x00, PIU2) } Method (_CRS, 0, NotSerialized) { Return (LCRO (PIU2)) } Method (_SRS, 1, NotSerialized) { Store (LSRO (Arg0), PIU2) } } Device (LMAC) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x08) Method (_STA, 0, NotSerialized) { Return (LSTA (PILN)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (RSAC, RSII)) } Method (_DIS, 0, NotSerialized) { Store (0x00, PILN) } Method (_CRS, 0, NotSerialized) { Return (LCRO (PILN)) } Method (_SRS, 1, NotSerialized) { Store (LSRO (Arg0), PILN) } } Device (LACI) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x09) Method (_STA, 0, NotSerialized) { Return (LSTA (PAUI)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (RSCI, RSII)) } Method (_DIS, 0, NotSerialized) { Store (0x00, PAUI) } Method (_CRS, 0, NotSerialized) { Return (LCRO (PAUI)) } Method (_SRS, 1, NotSerialized) { Store (LSRO (Arg0), PAUI) } } Device (LMC9) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x0A) Method (_STA, 0, NotSerialized) { Return (LSTA (PIMO)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (RSC9, RSII)) } Method (_DIS, 0, NotSerialized) { Store (0x00, PIMO) } Method (_CRS, 0, NotSerialized) { Return (LCRO (PIMO)) } Method (_SRS, 1, NotSerialized) { Store (LSRO (Arg0), PIMO) } } Device (LSMB) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x0B) Method (_STA, 0, NotSerialized) { Return (LSTA (PIRM)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (RSMB, RSII)) } Method (_DIS, 0, NotSerialized) { Store (0x00, PIRM) } Method (_CRS, 0, NotSerialized) { Return (LCRO (PIRM)) } Method (_SRS, 1, NotSerialized) { Store (LSRO (Arg0), PIRM) } } Device (LSA0) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x0C) Method (_STA, 0, NotSerialized) { Return (LSTA (PIID)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (RSA0, RSII)) } Method (_DIS, 0, NotSerialized) { Store (0x00, PIID) Store (0x00, PIRG) } Method (_CRS, 0, NotSerialized) { Return (LCRO (PIID)) } Method (_SRS, 1, NotSerialized) { Store (LSRO (Arg0), Local0) Store (Local0, PIID) Store (Local0, PIRG) } } Device (LSA1) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x0D) Method (_STA, 0, NotSerialized) { Return (LSTA (SIID)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (RSA1, RSII)) } Method (_DIS, 0, NotSerialized) { Store (0x00, SIID) Store (0x00, PIRF) } Method (_CRS, 0, NotSerialized) { Return (LCRO (SIID)) } Method (_SRS, 1, NotSerialized) { Store (LSRO (Arg0), Local0) Store (Local0, SIID) Store (Local0, PIRF) } } Device (LATA) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x0E) Method (_STA, 0, NotSerialized) { Return (LSTA (PR0E)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (RSTA, RSII)) } Method (_DIS, 0, NotSerialized) { Store (0x00, PR0E) Store (0x00, PR0F) } Method (_CRS, 0, NotSerialized) { If (OSFL ()) { Return (0x00) } Else { Return (LCRO (PR0E)) } } Method (_SRS, 1, NotSerialized) { Store (LSRO (Arg0), PR0E) Store (LSRO (Arg0), PR0F) } } } Scope (\_SB) { Name (XCPD, 0x00) Name (XNPT, 0x01) 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, 0x01) 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, 0x01) 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 (\_SB.RDPE (Local0), Local1) If (LEqual (Local1, 0xFFFFFFFF)) { Return (0x00) } Else { If (LAnd (Local1, 0x00010000)) { \_SB.WDPE (Local0, And (Local1, 0x00010000)) Return (0x01) } Return (0x00) } } } Scope (\_SB.PCI0.SBRG.SIOR) { Device (IT87) { Name (_HID, EisaId ("PNP0C02")) Name (_UID, 0x00) Method (HWV0, 0, NotSerialized) { Return (Multiply (VIV0, 0x10)) } Method (HWV1, 0, NotSerialized) { Return (Multiply (VIV1, 0x10)) } Method (HWV2, 0, NotSerialized) { Return (Multiply (VIV2, 0x10)) } Method (HWV3, 0, NotSerialized) { Return (Multiply (VIV3, 0x10)) } Method (HWV4, 0, NotSerialized) { Return (Multiply (VIV4, 0x10)) } Method (HWV5, 0, NotSerialized) { Return (Multiply (VIV5, 0x10)) } Method (HWV6, 0, NotSerialized) { Return (Multiply (VIV6, 0x10)) } Method (HWV7, 0, NotSerialized) { Return (Multiply (VIV7, 0x10)) } Method (HWT1, 0, NotSerialized) { Store (TPI1, Local0) If (LGreater (Local0, 0x80)) { Subtract (0x0100, Local0, Local0) } Return (Multiply (Local0, 0x0A)) } Method (HWT2, 0, NotSerialized) { Store (TPI2, Local0) If (LGreater (Local0, 0x80)) { Subtract (0x0100, Local0, Local0) } Return (Multiply (Local0, 0x0A)) } Method (HWT3, 0, NotSerialized) { Store (TPI3, Local0) If (LGreater (Local0, 0x80)) { Subtract (0x0100, Local0, Local0) } Return (Multiply (Local0, 0x0A)) } Method (HWF1, 0, NotSerialized) { And (ETDE, 0x01, Local0) While (0x01) { ShiftLeft (0x01, FTD1, Local1) If (LEqual (Local0, 0x01)) { Add (Multiply (EFN1, 0x0100), FTC1, Local2) } Else { Store (FTC1, Local2) } If (LEqual (Local0, 0x01)) { If (LNot (LLess (Local2, 0xF000))) { If (LNot (LEqual (Local1, 0x80))) { Add (FTD1, 0x01, FTD1) Sleep (0x64) } Else { Return (0x00) } } Else { If (LNot (LGreater (Local2, 0x1000))) { If (LNot (LEqual (Local1, 0x01))) { Subtract (FTD1, 0x01, FTD1) Sleep (0x64) } Else { Return (0xFFFF) } } Else { Divide (0x00149970, Multiply (Local1, Local2), , Local1) Return (Local1) } } } Else { If (LNot (LLess (Local2, 0xF0))) { If (LNot (LEqual (Local1, 0x80))) { Add (FTD1, 0x01, FTD1) Sleep (0x64) } Else { Return (0x00) } } Else { If (LNot (LGreater (Local2, 0x32))) { If (LNot (LEqual (Local1, 0x01))) { Subtract (FTD1, 0x01, FTD1) Sleep (0x64) } Else { Return (0xFFFF) } } Else { Divide (0x00149970, Multiply (Local1, Local2), , Local1) Return (Local1) } } } } } Method (HWF2, 0, NotSerialized) { And (ETDE, 0x02, Local0) While (0x01) { ShiftLeft (0x01, FTD2, Local1) If (LEqual (Local0, 0x02)) { Add (Multiply (EFN2, 0x0100), FTC2, Local2) } Else { Store (FTC2, Local2) } If (LEqual (Local0, 0x02)) { If (LNot (LLess (Local2, 0xF000))) { If (LNot (LEqual (Local1, 0x80))) { Add (FTD2, 0x01, FTD2) Sleep (0x64) } Else { Return (0x00) } } Else { If (LNot (LGreater (Local2, 0x1000))) { If (LNot (LEqual (Local1, 0x01))) { Subtract (FTD2, 0x01, FTD2) Sleep (0x64) } Else { Return (0xFFFF) } } Else { Divide (0x00149970, Multiply (Local1, Local2), , Local1) Return (Local1) } } } Else { If (LNot (LLess (Local2, 0xF0))) { If (LNot (LEqual (Local1, 0x80))) { Add (FTD2, 0x01, FTD2) Sleep (0x64) } Else { Return (0x00) } } Else { If (LNot (LGreater (Local2, 0x32))) { If (LNot (LEqual (Local1, 0x01))) { Subtract (FTD2, 0x01, FTD2) Sleep (0x64) } Else { Return (0xFFFF) } } Else { Divide (0x00149970, Multiply (Local1, Local2), , Local1) Return (Local1) } } } } } Method (HWF3, 0, NotSerialized) { And (ETDE, 0x04, Local0) While (0x01) { If (LEqual (FTD3, 0x01)) { Store (0x08, Local1) } Else { Store (0x02, Local1) } If (LEqual (Local0, 0x04)) { Add (Multiply (EFN3, 0x0100), FTC3, Local2) } Else { Store (FTC3, Local2) } If (LEqual (Local0, 0x04)) { If (LNot (LLess (Local2, 0xF000))) { If (LNot (LEqual (Local1, 0x08))) { Add (FTD3, 0x01, FTD3) Sleep (0x64) } Else { Return (0x00) } } Else { If (LNot (LGreater (Local2, 0x1000))) { If (LNot (LEqual (Local1, 0x00))) { Subtract (FTD3, 0x01, FTD3) Sleep (0x64) } Else { Return (0xFFFF) } } Else { Divide (0x00149970, Multiply (Local1, Local2), , Local1) Return (Local1) } } } Else { If (LNot (LLess (Local2, 0xF0))) { If (LNot (LEqual (Local1, 0x08))) { Add (FTD3, 0x01, FTD3) Sleep (0x64) } Else { Return (0x00) } } Else { If (LNot (LGreater (Local2, 0x10))) { If (LNot (LEqual (Local1, 0x00))) { Subtract (FTD3, 0x01, FTD3) Sleep (0x64) } Else { Return (0xFFFF) } } Else { Divide (0x00149970, Multiply (Local1, Local2), , Local1) Return (Local1) } } } } } OperationRegion (ECRE, SystemIO, IOEB, 0x20) Field (ECRE, ByteAcc, NoLock, Preserve) { Offset (0x05), HIDX, 8, HDAT, 8 } IndexField (HIDX, HDAT, ByteAcc, NoLock, Preserve) { Offset (0x0B), FTD1, 3, FTD2, 3, FTD3, 1, Offset (0x0C), ETDE, 8, FTC1, 8, FTC2, 8, FTC3, 8, Offset (0x18), EFN1, 8, EFN2, 8, EFN3, 8, Offset (0x20), VIV0, 8, VIV1, 8, VIV2, 8, VIV3, 8, VIV4, 8, VIV5, 8, VIV6, 8, VIV7, 8, Offset (0x29), TPI1, 8, TPI2, 8, TPI3, 8 } } } Scope (\) { Field (\RAMW, ByteAcc, NoLock, Preserve) { Offset (0x20), CPUQ, 8, CPVL, 16, CPVH, 16, CPVC, 1 } } Scope (\_SB.PCI0.SBRG.ASOC) { Name (CORV, Package (0x05) { 0x06020000, "Vcore Voltage", 0x0320, 0x0708, 0x01 }) Name (V3VV, Package (0x05) { 0x06020001, " +3.3 Voltage", 0x0B9A, 0x0E2E, 0x01 }) Name (V5VV, Package (0x05) { 0x06020002, " +5 Voltage", 0x1194, 0x157C, 0x01 }) Name (VV12, Package (0x05) { 0x06020003, " +12 Voltage", 0x27D8, 0x35E8, 0x01 }) Name (VPAR, Package (0x04) { Package (0x03) { 0x00, 0x01, 0x00 }, Package (0x03) { 0x00, 0x01, 0x00 }, Package (0x03) { 0x22, 0x32, 0x00 }, Package (0x03) { 0x0F, 0x05, 0x00 } }) Name (VBUF, Package (0x05) { 0x04, CORV, V3VV, V5VV, VV12 }) Method (VGET, 1, NotSerialized) { If (LEqual (Arg0, 0x00)) { Return (^^SIOR.IT87.HWV0 ()) } If (LEqual (Arg0, 0x01)) { Return (^^SIOR.IT87.HWV2 ()) } If (LEqual (Arg0, 0x02)) { Return (^^SIOR.IT87.HWV3 ()) } If (LEqual (Arg0, 0x03)) { Return (^^SIOR.IT87.HWV4 ()) } } Name (CPUT, Package (0x05) { 0x06030000, "CPU Temperature", 0x0258, 0x03B6, 0x00010001 }) Name (MBTP, Package (0x05) { 0x06030001, "MB Temperature", 0x01C2, 0x03B6, 0x00010001 }) Name (TBUF, Package (0x03) { 0x02, CPUT, MBTP }) Method (TGET, 1, NotSerialized) { If (LEqual (Arg0, 0x00)) { Return (^^SIOR.IT87.HWT1 ()) } If (LEqual (Arg0, 0x01)) { Return (^^SIOR.IT87.HWT2 ()) } } Name (CPUF, Package (0x05) { 0x06040000, "CPU FAN Speed", 0x0320, 0x1C20, 0x00010001 }) Name (CHA1, Package (0x05) { 0x06040001, "CHASSIS FAN Speed", 0x0320, 0x1C20, 0x00010001 }) Name (PWRF, Package (0x05) { 0x06040002, "POWER FAN Speed", 0x0320, 0x1C20, 0x00010001 }) Name (FBUF, Package (0x04) { 0x03, CPUF, CHA1, PWRF }) Method (FGET, 1, NotSerialized) { If (LEqual (Arg0, 0x00)) { Return (^^SIOR.IT87.HWF1 ()) } If (LEqual (Arg0, 0x01)) { Return (^^SIOR.IT87.HWF2 ()) } If (LEqual (Arg0, 0x02)) { Return (^^SIOR.IT87.HWF3 ()) } } Name (QBUF, Package (0x01) { 0x00 }) Method (VSIF, 0, NotSerialized) { Return (VBUF) } Method (RVLT, 1, NotSerialized) { And (Arg0, 0xFFFF, Local0) Store (VGET (Local0), Local1) Store (DerefOf (Index (DerefOf (Index (VPAR, Local0)), 0x00)), Local2) Store (DerefOf (Index (DerefOf (Index (VPAR, Local0)), 0x01)), Local3) Store (DerefOf (Index (DerefOf (Index (VPAR, Local0)), 0x02)), Local4) Multiply (Local1, Add (Local2, Local3), Local5) Divide (Local5, Local3, , Local5) Add (Local5, Local4, Local5) Return (Local5) } Method (SVLT, 1, NotSerialized) { And (DerefOf (Index (Arg0, 0x00)), 0xFFFF, Local0) Store (DerefOf (Index (VBUF, 0x00)), Local1) If (LNot (LLess (Local0, Local1))) { Return (0x00) } Increment (Local0) Store (DerefOf (Index (Arg0, 0x01)), Index (DerefOf (Index (VBUF, Local0)), 0x01)) Store (DerefOf (Index (Arg0, 0x02)), Index (DerefOf (Index (VBUF, Local0)), 0x02)) Store (DerefOf (Index (Arg0, 0x03)), Index (DerefOf (Index (VBUF, Local0)), 0x03)) Store (DerefOf (Index (Arg0, 0x04)), Index (DerefOf (Index (VBUF, Local0)), 0x04)) Return (0x01) } Method (TSIF, 0, NotSerialized) { Return (TBUF) } Method (RTMP, 1, NotSerialized) { And (Arg0, 0xFFFF, Local0) Store (TGET (Local0), Local1) Return (Local1) } Method (STMP, 1, NotSerialized) { Store (And (DerefOf (Index (Arg0, 0x00)), 0xFFFF), Local0) Store (DerefOf (Index (TBUF, 0x00)), Local1) If (LNot (LLess (Local0, Local1))) { Return (0x00) } Increment (Local0) Store (DerefOf (Index (Arg0, 0x01)), Index (DerefOf (Index (TBUF, Local0)), 0x01)) Store (DerefOf (Index (Arg0, 0x02)), Index (DerefOf (Index (TBUF, Local0)), 0x02)) Store (DerefOf (Index (Arg0, 0x03)), Index (DerefOf (Index (TBUF, Local0)), 0x03)) Store (DerefOf (Index (Arg0, 0x04)), Index (DerefOf (Index (TBUF, Local0)), 0x04)) Return (0x01) } Method (FSIF, 0, NotSerialized) { Return (FBUF) } Method (RFAN, 1, NotSerialized) { And (Arg0, 0xFFFF, Local0) Store (FGET (Local0), Local1) Return (Local1) } Method (SFAN, 1, NotSerialized) { And (DerefOf (Index (Arg0, 0x00)), 0xFFFF, Local0) Store (DerefOf (Index (FBUF, 0x00)), Local1) If (LNot (LLess (Local0, Local1))) { Return (0x00) } Increment (Local0) Store (DerefOf (Index (Arg0, 0x01)), Index (DerefOf (Index (FBUF, Local0)), 0x01)) Store (DerefOf (Index (Arg0, 0x02)), Index (DerefOf (Index (FBUF, Local0)), 0x02)) Store (DerefOf (Index (Arg0, 0x03)), Index (DerefOf (Index (FBUF, Local0)), 0x03)) Store (DerefOf (Index (Arg0, 0x04)), Index (DerefOf (Index (FBUF, Local0)), 0x04)) Return (0x01) } Method (QFIF, 0, NotSerialized) { If (LEqual (CPUQ, 0x00)) { And (DerefOf (Index (QCFN, 0x05)), 0xFFFDFFFF, Local0) Store (Local0, Index (QCFN, 0x05)) } Else { Or (DerefOf (Index (QCFN, 0x05)), 0x00020000, Local0) Store (Local0, Index (QCFN, 0x05)) } Return (QBUF) } Method (GCQV, 1, NotSerialized) { If (LEqual (Arg0, 0x00)) { Return (CPVL) } If (LEqual (Arg0, 0x01)) { Return (CPVH) } If (LEqual (Arg0, 0x02)) { Return (CPVC) } Return (0x00) } Method (QFST, 1, NotSerialized) { If (LEqual (Arg0, DerefOf (Index (QCFN, 0x00)))) { Return (CQST) } Return (0x00) } } 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) }) CreateDWordField (CRS, 0x5C, MIN5) CreateDWordField (CRS, 0x60, MAX5) CreateDWordField (CRS, 0x68, LEN5) CreateDWordField (CRS, 0x76, MIN6) CreateDWordField (CRS, 0x7A, MAX6) CreateDWordField (CRS, 0x82, LEN6) 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) Return (CRS) } } } Name (WOTB, 0x00) Name (WSSB, 0x00) Name (WAXB, 0x00) Method (_PTS, 1, NotSerialized) { Store (Arg0, DBG8) PTS (Arg0) Store (0x00, Index (WAKP, 0x00)) Store (0x00, Index (WAKP, 0x01)) 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) } Method (_WAK, 1, NotSerialized) { ShiftLeft (Arg0, 0x04, DBG8) WAK (Arg0) If (ASSB) { Store (WSSB, ASSB) Store (WOTB, AOTB) Store (WAXB, AAXB) } If (DerefOf (Index (WAKP, 0x00))) { Store (0x00, Index (WAKP, 0x01)) } Else { Store (Arg0, Index (WAKP, 0x01)) } Return (WAKP) } Name (\_S0, Package (0x04) { 0x00, 0x00, 0x00, 0x00 }) If (SS1) { Name (\_S1, Package (0x04) { 0x01, 0x00, 0x00, 0x00 }) } If (SS3) { Name (\_S3, Package (0x04) { 0x05, 0x00, 0x00, 0x00 }) } If (SS4) { Name (\_S4, Package (0x04) { 0x06, 0x00, 0x00, 0x00 }) } Name (\_S5, Package (0x04) { 0x07, 0x00, 0x00, 0x00 }) Method (PTS, 1, NotSerialized) { If (Arg0) { \_SB.PCI0.SBRG.SIOS (Arg0) \_SB.PCI0.NB2N.NPTS (Arg0) \_SB.PCI0.SBRG.SPTS (Arg0) } } Method (WAK, 1, NotSerialized) { \_SB.PCI0.SBRG.SIOW (Arg0) \_SB.PCI0.NB2N.NWAK (Arg0) \_SB.PCI0.SBRG.SWAK (Arg0) } } --------------060902000402000309040604-- From owner-freebsd-stable@FreeBSD.ORG Fri Jul 28 23:03:25 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 881E616A4DD; Fri, 28 Jul 2006 23:03:25 +0000 (UTC) (envelope-from prvs=ohartman=3577c8702@uni-mainz.de) Received: from mailgate02.zdv.uni-mainz.de (mailgate02.zdv.Uni-Mainz.DE [134.93.178.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89BFD43D45; Fri, 28 Jul 2006 23:03:21 +0000 (GMT) (envelope-from prvs=ohartman=3577c8702@uni-mainz.de) Received: from exfront02.zdv.uni-mainz.de ([134.93.176.56]) by mailgate02.zdv.uni-mainz.de with ESMTP; 29 Jul 2006 01:03:20 +0200 Received: from mail.uni-mainz.de ([134.93.176.49]) by exfront02.zdv.Uni-Mainz.DE with Microsoft SMTPSVC(6.0.3790.1830); Sat, 29 Jul 2006 01:03:20 +0200 Received: from [192.168.1.128] ([85.178.6.232] RDNS failed) by mail.uni-mainz.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Sat, 29 Jul 2006 01:03:17 +0200 Message-ID: <44CA97AB.2070100@mail.uni-mainz.de> Date: Sat, 29 Jul 2006 01:03:07 +0200 From: "O. Hartmann" User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: John Baldwin References: <44C63DFD.5040401@rogers.com> <44C85C4F.7030902@rogers.com> <200607280948.51239.jhb@freebsd.org> In-Reply-To: <200607280948.51239.jhb@freebsd.org> Content-Type: multipart/mixed; boundary="------------060902000402000309040604" X-OriginalArrivalTime: 28 Jul 2006 23:03:17.0192 (UTC) FILETIME=[0303B480:01C6B29A] X-Mailman-Approved-At: Fri, 28 Jul 2006 23:28:12 +0000 Cc: stable@freebsd.org, Bruno Ducrot , freebsd-stable@freebsd.org, Mike Jakubik , David Duchscher , Jiawei Ye Subject: Re: Monitoring temperature with acpi (sysctls) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 23:03:25 -0000 This is a multi-part message in MIME format. --------------060902000402000309040604 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit John Baldwin wrote: > On Thursday 27 July 2006 02:25, Mike Jakubik wrote: > >> Jiawei Ye wrote: >> >>> On 7/27/06, Mike Jakubik wrote: >>> >>>> I don't want to spend $50 extra per system, just so i can read the >>>> temperature, and not even use any of the IPMI functions. I need a simple >>>> and scriptable way to get the values, acpi sysctls are ideal for this. >>>> >>> What about using SMBus? Is it available on your system? xmbmon reads >>> temperatures off the SMBus IIRC. >>> >> I tried that, unfortunately it does not work. All i want to know is if >> this a shortcoming of freebsd or the motherboard, if its the later, i >> will contact the manufacturer. >> > > If ACPI doesn't include the sysctl's that's due to your BIOS, not FreeBSD. > You can verify by doing an acpidump and seeing if you have any thermal > zones listed in your ASL. > > This is a 'acpidump -d' of my BIOS, mainboard ASUS A8N32-SLI Deluxe, latest BIOS, V1205 as seen on ASUS homepage. Please see attachment. Oliver --------------060902000402000309040604 Content-Type: text/plain; name="acpi.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="acpi.txt" /* * Intel ACPI Component Architecture * AML Disassembler version 20041119 * * Disassembly of /tmp/acpidump.nhd4SF, Fri Jul 28 23:00:44 2006 */ DefinitionBlock ("DSDT.aml", "DSDT", 1, "A0371", "A0371001", 1) { Name (DP80, 0x1080) Name (DP90, 0x90) Name (SPIO, 0x2E) Name (IOPB, 0x0C00) Name (IOPL, 0x10) Name (IOEB, 0x0D00) Name (IOEL, 0x10) Name (IOGB, 0x0A20) Name (IOGL, 0x10) Name (IODB, 0x0A30) Name (IODL, 0x10) Name (IO1B, 0x0A20) Name (IO1L, 0x08) Name (IO3B, 0x0D00) Name (IO3L, 0x80) Name (PMBS, 0x0500) Name (PMLN, 0x0100) Name (SCBS, 0x0800) Name (SCLN, 0x0100) Name (ACBS, 0x0900) Name (ACLN, 0x0100) Name (SCIO, 0x0800) Name (SCTL, 0x0590) Name (EXTS, 0x00) Name (APIC, 0x01) Name (ABWV, 0xAB) Name (PCIB, 0xE0000000) Name (PCIL, 0x10000000) Name (SMBS, 0x0700) OperationRegion (BIOS, SystemMemory, 0x7FFBE064, 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, Offset (0x1C), CPB0, 32, CPB1, 32, CPB2, 32, CPB3, 32, ASSB, 8, AOTB, 8, AAXB, 32 } Method (RRIO, 4, NotSerialized) { Store ("RRIO", Debug) } Method (RDMA, 3, NotSerialized) { Store ("rDMA", Debug) } Name (PICM, 0x00) 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, 0x00)) { Store (0xAC, DBG8) } Store (0x01, OSVR) If (CondRefOf (\_OSI, Local1)) { If (\_OSI ("Windows 2001")) { Store (0x00, 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), 0x01, 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, 0x00)) Store (ShiftLeft (SS1, 0x01), Local0) Or (Local0, ShiftLeft (SS2, 0x02), Local0) Or (Local0, ShiftLeft (SS3, 0x03), Local0) Or (Local0, ShiftLeft (SS4, 0x04), Local0) If (And (ShiftLeft (0x01, Arg1), Local0)) { Store (Arg1, Index (PRWP, 0x01)) } Else { ShiftRight (Local0, 0x01, Local0) If (LOr (LEqual (OSFL (), 0x01), LEqual (OSFL (), 0x02))) { FindSetLeftBit (Local0, Index (PRWP, 0x01)) } Else { FindSetRightBit (Local0, Index (PRWP, 0x01)) } } Return (PRWP) } Name (WAKP, Package (0x02) { Zero, Zero }) OperationRegion (DEB0, SystemIO, DP80, 0x01) Field (DEB0, ByteAcc, NoLock, Preserve) { DBG8, 8 } OperationRegion (DEB1, SystemIO, DP90, 0x02) Field (DEB1, WordAcc, NoLock, Preserve) { DBG9, 16 } Scope (\_SB) { Name (PR00, Package (0x20) { Package (0x04) { 0x000AFFFF, 0x00, LSMB, 0x00 }, Package (0x04) { 0x000BFFFF, 0x00, LUB0, 0x00 }, Package (0x04) { 0x000BFFFF, 0x01, LUB2, 0x00 }, Package (0x04) { 0x0013FFFF, 0x00, LMAC, 0x00 }, Package (0x04) { 0x0010FFFF, 0x00, LSA0, 0x00 }, Package (0x04) { 0x0011FFFF, 0x00, LSA1, 0x00 }, Package (0x04) { 0x000DFFFF, 0x00, LACI, 0x00 }, Package (0x04) { 0x000DFFFF, 0x01, LMC9, 0x00 }, Package (0x04) { 0x0002FFFF, 0x00, LNKB, 0x00 }, Package (0x04) { 0x0002FFFF, 0x01, LNKC, 0x00 }, Package (0x04) { 0x0002FFFF, 0x02, LNKD, 0x00 }, Package (0x04) { 0x0002FFFF, 0x03, LNKA, 0x00 }, Package (0x04) { 0x0003FFFF, 0x00, LNKA, 0x00 }, Package (0x04) { 0x0003FFFF, 0x01, LNKB, 0x00 }, Package (0x04) { 0x0003FFFF, 0x02, LNKC, 0x00 }, Package (0x04) { 0x0003FFFF, 0x03, LNKD, 0x00 }, Package (0x04) { 0x0004FFFF, 0x00, LNKA, 0x00 }, Package (0x04) { 0x0004FFFF, 0x01, LNKB, 0x00 }, Package (0x04) { 0x0004FFFF, 0x02, LNKC, 0x00 }, Package (0x04) { 0x0004FFFF, 0x03, LNKD, 0x00 }, Package (0x04) { 0x0017FFFF, 0x00, LNKB, 0x00 }, Package (0x04) { 0x0017FFFF, 0x01, LNKC, 0x00 }, Package (0x04) { 0x0017FFFF, 0x02, LNKD, 0x00 }, Package (0x04) { 0x0017FFFF, 0x03, LNKA, 0x00 }, Package (0x04) { 0x0016FFFF, 0x00, LNKC, 0x00 }, Package (0x04) { 0x0016FFFF, 0x01, LNKD, 0x00 }, Package (0x04) { 0x0016FFFF, 0x02, LNKA, 0x00 }, Package (0x04) { 0x0016FFFF, 0x03, LNKB, 0x00 }, Package (0x04) { 0x0015FFFF, 0x00, LNKD, 0x00 }, Package (0x04) { 0x0015FFFF, 0x01, LNKA, 0x00 }, Package (0x04) { 0x0015FFFF, 0x02, LNKB, 0x00 }, Package (0x04) { 0x0015FFFF, 0x03, LNKC, 0x00 } }) Name (AR00, Package (0x20) { Package (0x04) { 0x000AFFFF, 0x00, LSMB, 0x00 }, Package (0x04) { 0x000BFFFF, 0x00, LUB0, 0x00 }, Package (0x04) { 0x000BFFFF, 0x01, LUB2, 0x00 }, Package (0x04) { 0x0013FFFF, 0x00, LMAC, 0x00 }, Package (0x04) { 0x0010FFFF, 0x00, LSA0, 0x00 }, Package (0x04) { 0x0011FFFF, 0x00, LSA1, 0x00 }, Package (0x04) { 0x000DFFFF, 0x00, LACI, 0x00 }, Package (0x04) { 0x000DFFFF, 0x01, LMC9, 0x00 }, Package (0x04) { 0x0002FFFF, 0x00, LNKB, 0x00 }, Package (0x04) { 0x0002FFFF, 0x01, LNKC, 0x00 }, Package (0x04) { 0x0002FFFF, 0x02, LNKD, 0x00 }, Package (0x04) { 0x0002FFFF, 0x03, LNKA, 0x00 }, Package (0x04) { 0x0003FFFF, 0x00, LNKA, 0x00 }, Package (0x04) { 0x0003FFFF, 0x01, LNKB, 0x00 }, Package (0x04) { 0x0003FFFF, 0x02, LNKC, 0x00 }, Package (0x04) { 0x0003FFFF, 0x03, LNKD, 0x00 }, Package (0x04) { 0x0004FFFF, 0x00, LNKA, 0x00 }, Package (0x04) { 0x0004FFFF, 0x01, LNKB, 0x00 }, Package (0x04) { 0x0004FFFF, 0x02, LNKC, 0x00 }, Package (0x04) { 0x0004FFFF, 0x03, LNKD, 0x00 }, Package (0x04) { 0x0017FFFF, 0x00, LNKB, 0x00 }, Package (0x04) { 0x0017FFFF, 0x01, LNKC, 0x00 }, Package (0x04) { 0x0017FFFF, 0x02, LNKD, 0x00 }, Package (0x04) { 0x0017FFFF, 0x03, LNKA, 0x00 }, Package (0x04) { 0x0016FFFF, 0x00, LNKC, 0x00 }, Package (0x04) { 0x0016FFFF, 0x01, LNKD, 0x00 }, Package (0x04) { 0x0016FFFF, 0x02, LNKA, 0x00 }, Package (0x04) { 0x0016FFFF, 0x03, LNKB, 0x00 }, Package (0x04) { 0x0015FFFF, 0x00, LNKD, 0x00 }, Package (0x04) { 0x0015FFFF, 0x01, LNKA, 0x00 }, Package (0x04) { 0x0015FFFF, 0x02, LNKB, 0x00 }, Package (0x04) { 0x0015FFFF, 0x03, LNKC, 0x00 } }) Name (PR01, Package (0x0D) { Package (0x04) { 0x000BFFFF, 0x00, LNKA, 0x00 }, Package (0x04) { 0x0006FFFF, 0x00, LNKA, 0x00 }, Package (0x04) { 0x0006FFFF, 0x01, LNKB, 0x00 }, Package (0x04) { 0x0006FFFF, 0x02, LNKC, 0x00 }, Package (0x04) { 0x0006FFFF, 0x03, LNKD, 0x00 }, Package (0x04) { 0x0007FFFF, 0x00, LNKB, 0x00 }, Package (0x04) { 0x0007FFFF, 0x01, LNKC, 0x00 }, Package (0x04) { 0x0007FFFF, 0x02, LNKD, 0x00 }, Package (0x04) { 0x0007FFFF, 0x03, LNKA, 0x00 }, Package (0x04) { 0x0008FFFF, 0x00, LNKC, 0x00 }, Package (0x04) { 0x0008FFFF, 0x01, LNKD, 0x00 }, Package (0x04) { 0x0008FFFF, 0x02, LNKA, 0x00 }, Package (0x04) { 0x0008FFFF, 0x03, LNKB, 0x00 } }) Name (AR01, Package (0x0D) { Package (0x04) { 0x000BFFFF, 0x00, LNKA, 0x00 }, Package (0x04) { 0x0006FFFF, 0x00, LNKA, 0x00 }, Package (0x04) { 0x0006FFFF, 0x01, LNKB, 0x00 }, Package (0x04) { 0x0006FFFF, 0x02, LNKC, 0x00 }, Package (0x04) { 0x0006FFFF, 0x03, LNKD, 0x00 }, Package (0x04) { 0x0007FFFF, 0x00, LNKB, 0x00 }, Package (0x04) { 0x0007FFFF, 0x01, LNKC, 0x00 }, Package (0x04) { 0x0007FFFF, 0x02, LNKD, 0x00 }, Package (0x04) { 0x0007FFFF, 0x03, LNKA, 0x00 }, Package (0x04) { 0x0008FFFF, 0x00, LNKC, 0x00 }, Package (0x04) { 0x0008FFFF, 0x01, LNKD, 0x00 }, Package (0x04) { 0x0008FFFF, 0x02, LNKA, 0x00 }, Package (0x04) { 0x0008FFFF, 0x03, LNKB, 0x00 } }) Name (PR02, Package (0x04) { Package (0x04) { 0xFFFF, 0x00, LNKB, 0x00 }, Package (0x04) { 0xFFFF, 0x01, LNKC, 0x00 }, Package (0x04) { 0xFFFF, 0x02, LNKD, 0x00 }, Package (0x04) { 0xFFFF, 0x03, LNKA, 0x00 } }) Name (AR02, Package (0x04) { Package (0x04) { 0xFFFF, 0x00, LNKB, 0x00 }, Package (0x04) { 0xFFFF, 0x01, LNKC, 0x00 }, Package (0x04) { 0xFFFF, 0x02, LNKD, 0x00 }, Package (0x04) { 0xFFFF, 0x03, LNKA, 0x00 } }) Name (PR03, Package (0x04) { Package (0x04) { 0xFFFF, 0x00, LNKA, 0x00 }, Package (0x04) { 0xFFFF, 0x01, LNKB, 0x00 }, Package (0x04) { 0xFFFF, 0x02, LNKC, 0x00 }, Package (0x04) { 0xFFFF, 0x03, LNKD, 0x00 } }) Name (AR03, Package (0x04) { Package (0x04) { 0xFFFF, 0x00, LNKA, 0x00 }, Package (0x04) { 0xFFFF, 0x01, LNKB, 0x00 }, Package (0x04) { 0xFFFF, 0x02, LNKC, 0x00 }, Package (0x04) { 0xFFFF, 0x03, LNKD, 0x00 } }) Name (PR04, Package (0x04) { Package (0x04) { 0xFFFF, 0x00, LNKA, 0x00 }, Package (0x04) { 0xFFFF, 0x01, LNKB, 0x00 }, Package (0x04) { 0xFFFF, 0x02, LNKC, 0x00 }, Package (0x04) { 0xFFFF, 0x03, LNKD, 0x00 } }) Name (AR04, Package (0x04) { Package (0x04) { 0xFFFF, 0x00, LNKA, 0x00 }, Package (0x04) { 0xFFFF, 0x01, LNKB, 0x00 }, Package (0x04) { 0xFFFF, 0x02, LNKC, 0x00 }, Package (0x04) { 0xFFFF, 0x03, LNKD, 0x00 } }) Name (PR05, Package (0x04) { Package (0x04) { 0xFFFF, 0x00, LNKB, 0x00 }, Package (0x04) { 0xFFFF, 0x01, LNKC, 0x00 }, Package (0x04) { 0xFFFF, 0x02, LNKD, 0x00 }, Package (0x04) { 0xFFFF, 0x03, LNKA, 0x00 } }) Name (AR05, Package (0x04) { Package (0x04) { 0xFFFF, 0x00, LNKB, 0x00 }, Package (0x04) { 0xFFFF, 0x01, LNKC, 0x00 }, Package (0x04) { 0xFFFF, 0x02, LNKD, 0x00 }, Package (0x04) { 0xFFFF, 0x03, LNKA, 0x00 } }) Name (PR06, Package (0x04) { Package (0x04) { 0xFFFF, 0x00, LNKC, 0x00 }, Package (0x04) { 0xFFFF, 0x01, LNKD, 0x00 }, Package (0x04) { 0xFFFF, 0x02, LNKA, 0x00 }, Package (0x04) { 0xFFFF, 0x03, LNKB, 0x00 } }) Name (AR06, Package (0x04) { Package (0x04) { 0xFFFF, 0x00, LNKC, 0x00 }, Package (0x04) { 0xFFFF, 0x01, LNKD, 0x00 }, Package (0x04) { 0xFFFF, 0x02, LNKA, 0x00 }, Package (0x04) { 0xFFFF, 0x03, LNKB, 0x00 } }) Name (PR07, Package (0x04) { Package (0x04) { 0xFFFF, 0x00, LNKD, 0x00 }, Package (0x04) { 0xFFFF, 0x01, LNKA, 0x00 }, Package (0x04) { 0xFFFF, 0x02, LNKB, 0x00 }, Package (0x04) { 0xFFFF, 0x03, LNKC, 0x00 } }) Name (AR07, Package (0x04) { Package (0x04) { 0xFFFF, 0x00, LNKD, 0x00 }, Package (0x04) { 0xFFFF, 0x01, LNKA, 0x00 }, Package (0x04) { 0xFFFF, 0x02, LNKB, 0x00 }, Package (0x04) { 0xFFFF, 0x03, LNKC, 0x00 } }) Name (PRSA, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {5,7,10,14,15} }) Alias (PRSA, PRSB) Alias (PRSA, PRSC) Alias (PRSA, PRSD) Alias (PRSA, RSMB) Alias (PRSA, RSB2) Name (RSA1, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {11} }) Alias (RSA1, RSA0) Alias (PRSA, RSB0) Alias (PRSA, RSAC) Alias (PRSA, RSCI) Alias (PRSA, RSC9) Alias (PRSA, RSTA) Name (RSIR, ResourceTemplate () { Interrupt (ResourceConsumer, Level, ActiveLow, Shared) { 0x00000010, 0x00000011, 0x00000012, 0x00000013, } }) Name (RSII, ResourceTemplate () { Interrupt (ResourceConsumer, Level, ActiveLow, Shared) { 0x00000014, 0x00000015, 0x00000016, 0x00000017, } }) Device (PCI0) { Name (_HID, EisaId ("PNP0A03")) Name (_ADR, 0x00180000) Method (^BN00, 0, NotSerialized) { Return (0x00) } Method (_BBN, 0, NotSerialized) { Return (BN00 ()) } Name (_UID, 0x00) Method (_PRT, 0, NotSerialized) { If (PICM) { Return (AR00) } Return (PR00) } Device (NB2N) { Name (_ADR, 0x00) Method (NPTS, 1, NotSerialized) { } Method (NWAK, 1, NotSerialized) { } } Device (PCLK) { Name (_ADR, 0x02) } Device (SBRG) { Name (_ADR, 0x000A0000) Method (SPTS, 1, NotSerialized) { Store (Arg0, \_SB.PCI0.IDE0.PTS0) Store (\_SB.PCI0.IDE0.ID20, \_SB.PCI0.IDE0.SID0) Store (\_SB.PCI0.IDE0.IDTS, \_SB.PCI0.IDE0.SID1) Store (\_SB.PCI0.IDE0.IDTP, \_SB.PCI0.IDE0.SID2) Store (\_SB.PCI0.IDE0.ID22, \_SB.PCI0.IDE0.SID3) Store (\_SB.PCI0.IDE0.UMSS, \_SB.PCI0.IDE0.SID4) Store (\_SB.PCI0.IDE0.UMSP, \_SB.PCI0.IDE0.SID5) Store (One, PS1S) Store (One, PS1E) Store (One, \_SB.SLPS) } Method (SWAK, 1, NotSerialized) { Store (Zero, \_SB.SLPS) Store (Zero, PS1E) Store (0x02, S1CT) Store (0x02, S3CT) Store (0x02, S4CT) Store (0x02, S5CT) } OperationRegion (SMIE, SystemIO, SCIO, 0x08) Field (SMIE, ByteAcc, NoLock, Preserve) { , 15, PS1S, 1, , 31, PS1E, 1, Offset (0x08) } OperationRegion (SXCT, SystemIO, SCTL, 0x10) Field (SXCT, ByteAcc, NoLock, Preserve) { S1CT, 2, Offset (0x04), S3CT, 2, Offset (0x08), S4CT, 2, Offset (0x0C), S5CT, 2, Offset (0x10) } Scope (\_SB) { Name (SLPS, 0x00) Device (SLPB) { Name (_HID, EisaId ("PNP0C0E")) Method (_STA, 0, NotSerialized) { If (EXTS) { Return (0x0F) } Return (0x00) } Method (SBEV, 0, NotSerialized) { If (SLPS) { Notify (SLPB, 0x02) } Else { Notify (SLPB, 0x80) } } Method (\_GPE._L01, 0, NotSerialized) { \_SB.SLPB.SBEV () } Method (_PRW, 0, NotSerialized) { Return (Package (0x02) { 0x01, 0x04 }) } } Scope (PCI0) { Method (_S3D, 0, NotSerialized) { If (LEqual (OSFL (), 0x02)) { Return (0x02) } Else { Return (0x03) } } Name (_S1D, 0x01) Name (NATA, Package (0x01) { 0x00100000 }) Device (NVRB) { Name (_HID, "NVRAIDBUS") Method (_STA, 0, NotSerialized) { If (And (CPB0, 0x01)) { Return (0x0F) } Else { Return (0x00) } } Name (_CRS, ResourceTemplate () { IO (Decode16, 0x04D2, 0x04D2, 0x01, 0x01) }) } } } 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 (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 (FDC) { Name (_HID, EisaId ("PNP0700")) Method (_FDE, 0, NotSerialized) { Name (FDEP, Package (0x05) { 0x00, 0x00, 0x02, 0x02, 0x02 }) If (_STA ()) { Store (0x01, Index (FDEP, 0x00)) } Return (FDEP) } Method (_STA, 0, NotSerialized) { Return (DSTA (0x03)) } Method (_DIS, 0, NotSerialized) { DCNT (0x03, 0x00) } Method (_CRS, 0, NotSerialized) { DCRS (0x03, 0x01) Store (IRQM, IRQE) Store (DMAM, DMAE) Store (IO11, IO21) Store (IO12, IO22) Store (0x06, LEN2) Add (IO21, 0x07, IO31) Store (IO31, IO32) Store (0x01, LEN3) Return (CRS2) } Method (_SRS, 1, NotSerialized) { DSRS (Arg0, 0x03) CreateWordField (Arg0, 0x11, IRQE) CreateByteField (Arg0, 0x14, DMAE) ENFG (CGLD (0x03)) If (IRQE) { FindSetRightBit (IRQE, Local0) Subtract (Local0, 0x01, INTR) } Else { Store (0x00, INTR) } If (DMAE) { FindSetRightBit (DMAE, Local0) Subtract (Local0, 0x01, DMCH) } Else { Store (0x04, DMCH) } EXFG () } Name (_PRS, ResourceTemplate () { StartDependentFn (0x00, 0x00) { IO (Decode16, 0x03F0, 0x03F0, 0x01, 0x06) IO (Decode16, 0x03F7, 0x03F7, 0x01, 0x01) IRQNoFlags () {6} DMA (Compatibility, NotBusMaster, Transfer8) {2} } StartDependentFnNoPri () { IO (Decode16, 0x03F0, 0x03F0, 0x01, 0x06) IO (Decode16, 0x03F7, 0x03F7, 0x01, 0x01) IRQNoFlags () {3,4,5,6,7,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8) {0,1,2,3} } StartDependentFnNoPri () { IO (Decode16, 0x0370, 0x0370, 0x01, 0x06) IO (Decode16, 0x0377, 0x0377, 0x01, 0x01) IRQNoFlags () {3,4,5,6,7,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8) {0,1,2,3} } EndDependentFn () }) } Device (LPTE) { Method (_HID, 0, NotSerialized) { If (LPTM (0x02)) { Return (0x0104D041) } Else { Return (0x0004D041) } } Method (_STA, 0, NotSerialized) { Return (DSTA (0x02)) } Method (_DIS, 0, NotSerialized) { DCNT (0x02, 0x00) } Method (_CRS, 0, NotSerialized) { DCRS (0x02, 0x01) If (LPTM (0x02)) { Store (IRQM, IRQE) Store (DMAM, DMAE) Store (IO11, IO21) Store (IO12, IO22) Store (LEN1, LEN2) Add (IO21, 0x0400, IO31) Store (IO31, IO32) Store (LEN2, LEN3) Return (CRS2) } Else { Return (CRS1) } } Method (_SRS, 1, NotSerialized) { DSRS (Arg0, 0x02) } Method (_PRS, 0, NotSerialized) { If (LPTM (0x02)) { Return (EPPR) } Else { Return (LPPR) } } Name (LPPR, ResourceTemplate () { StartDependentFnNoPri () { IO (Decode16, 0x0378, 0x0378, 0x01, 0x08) IRQNoFlags () {3,4,5,6,7,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8) {} } StartDependentFnNoPri () { IO (Decode16, 0x0278, 0x0278, 0x01, 0x08) IRQNoFlags () {3,4,5,6,7,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8) {} } StartDependentFnNoPri () { IO (Decode16, 0x03BC, 0x03BC, 0x01, 0x04) IRQNoFlags () {3,4,5,6,7,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8) {} } EndDependentFn () }) Name (EPPR, ResourceTemplate () { StartDependentFn (0x00, 0x00) { IO (Decode16, 0x0378, 0x0378, 0x01, 0x08) IO (Decode16, 0x0778, 0x0778, 0x01, 0x08) IRQNoFlags () {7} DMA (Compatibility, NotBusMaster, Transfer8) {3} } StartDependentFnNoPri () { IO (Decode16, 0x0378, 0x0378, 0x01, 0x08) IO (Decode16, 0x0778, 0x0778, 0x01, 0x08) IRQNoFlags () {3,4,5,6,7,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8) {0,1,2,3} } StartDependentFnNoPri () { IO (Decode16, 0x0278, 0x0278, 0x01, 0x08) IO (Decode16, 0x0678, 0x0678, 0x01, 0x08) IRQNoFlags () {3,4,5,6,7,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8) {0,1,2,3} } StartDependentFnNoPri () { IO (Decode16, 0x03BC, 0x03BC, 0x01, 0x04) IO (Decode16, 0x07BC, 0x07BC, 0x01, 0x04) IRQNoFlags () {3,4,5,6,7,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8) {0,1,2,3} } EndDependentFn () }) } Device (GAME) { Name (_HID, EisaId ("PNPB02F")) Method (_STA, 0, NotSerialized) { Return (DSTA (0x08)) } Method (_DIS, 0, NotSerialized) { DCNT (0x08, 0x00) } Name (GMCR, ResourceTemplate () { IO (Decode16, 0x0000, 0x0000, 0x08, 0x08) }) Method (_CRS, 0, NotSerialized) { CreateWordField (GMCR, 0x02, IOGL) CreateWordField (GMCR, 0x04, IOGH) ENFG (CGLD (0x08)) ShiftLeft (IOAH, 0x08, IOGL) Or (IOAL, IOGL, IOGL) Store (IOGL, IOGH) CreateByteField (GMCR, 0x06, IOAL) Store (0x01, IOAL) EXFG () Return (GMCR) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x02, IO11) ENFG (CGLD (0x08)) And (IO11, 0xFF, IOAL) ShiftRight (IO11, 0x08, IOAH) DCNT (0x08, 0x01) EXFG () } Name (_PRS, ResourceTemplate () { StartDependentFn (0x00, 0x00) { IO (Decode16, 0x0201, 0x0201, 0x01, 0x08) } EndDependentFn () }) } Device (MIDI) { Name (_HID, EisaId ("PNPB006")) Method (_STA, 0, NotSerialized) { Return (DSTA (0x05)) } Method (_DIS, 0, NotSerialized) { DCNT (0x05, 0x00) } Name (MDCR, ResourceTemplate () { IO (Decode16, 0x0000, 0x0000, 0x01, 0x02) IRQNoFlags () {5} }) Method (_CRS, 0, NotSerialized) { CreateWordField (MDCR, 0x02, IOML) CreateWordField (MDCR, 0x04, IOMH) CreateWordField (MDCR, 0x09, IRQM) ENFG (CGLD (0x05)) ShiftLeft (IOAH, 0x08, IOML) Or (IOAL, IOML, IOML) Store (IOML, IOMH) If (INTR) { ShiftLeft (0x01, INTR, IRQM) } Else { Store (0x00, IRQM) } EXFG () Return (MDCR) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x02, IO11) CreateWordField (Arg0, 0x09, IRQM) ENFG (CGLD (0x05)) And (IO11, 0xFF, IOAL) ShiftRight (IO11, 0x08, IOAH) If (IRQM) { FindSetRightBit (IRQM, Local0) Subtract (Local0, 0x01, INTR) } Else { Store (0x00, INTR) } DCNT (0x05, 0x01) EXFG () } Name (_PRS, ResourceTemplate () { StartDependentFnNoPri () { IO (Decode16, 0x0300, 0x0300, 0x01, 0x02) } StartDependentFnNoPri () { IO (Decode16, 0x0330, 0x0330, 0x01, 0x02) } EndDependentFn () IRQNoFlags () {5,7,9,10,11} }) } 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, 0x0062, 0x0062, 0x00, 0x02) IO (Decode16, 0x0065, 0x0065, 0x00, 0x0B) 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, 0x0800, 0x0800, 0x00, 0x10) IO (Decode16, 0x0000, 0x0000, 0x00, 0x00) IO (Decode16, 0x0000, 0x0000, 0x00, 0x00) IO (Decode16, 0x0000, 0x0000, 0x00, 0x00) IO (Decode16, 0x0000, 0x0000, 0x00, 0x00) IO (Decode16, 0x0000, 0x0000, 0x00, 0x00) IO (Decode16, 0x0000, 0x0000, 0x00, 0x00) Memory32Fixed (ReadOnly, 0xFEE01000, 0x000FF000) Memory32Fixed (ReadOnly, 0xFEFFF000, 0x00001000) Memory32Fixed (ReadWrite, 0xFFB00000, 0x004F0000) Memory32Fixed (ReadOnly, 0xFFF00000, 0x00100000) }) Method (_CRS, 0, NotSerialized) { CreateWordField (CRS, 0x7A, GP00) CreateWordField (CRS, 0x7C, GP01) CreateByteField (CRS, 0x7F, GP0L) CreateWordField (CRS, 0x82, GP10) CreateWordField (CRS, 0x84, GP11) CreateByteField (CRS, 0x87, GP1L) Store (PMBS, GP00) Store (PMBS, GP01) If (LNot (LLess (PMLN, 0x0100))) { ShiftRight (PMLN, 0x01, GP0L) Add (GP00, GP0L, GP10) Add (GP01, GP0L, GP11) Subtract (PMLN, GP0L, GP1L) } Else { Store (PMLN, GP0L) } If (SCBS) { CreateWordField (CRS, 0x8A, SC00) CreateWordField (CRS, 0x8C, SC01) CreateByteField (CRS, 0x8F, SC0L) CreateWordField (CRS, 0x92, SC10) CreateWordField (CRS, 0x94, SC11) CreateByteField (CRS, 0x97, SC1L) Store (SCBS, SC00) Store (SCBS, SC01) If (LNot (LLess (SCLN, 0x0100))) { ShiftRight (SCLN, 0x01, SC0L) Add (SC00, SC0L, SC10) Add (SC01, SC0L, SC11) Subtract (SCLN, SC0L, SC1L) } Else { Store (SCLN, SC0L) } } If (ACBS) { CreateWordField (CRS, 0x9A, AC00) CreateWordField (CRS, 0x9C, AC01) CreateByteField (CRS, 0x9F, AC0L) CreateWordField (CRS, 0xA2, AC10) CreateWordField (CRS, 0xA4, AC11) CreateByteField (CRS, 0xA7, AC1L) Store (ACBS, AC00) Store (ACBS, AC01) If (LNot (LLess (ACLN, 0x0100))) { ShiftRight (ACLN, 0x01, AC0L) Add (AC00, AC0L, AC10) Add (AC01, AC0L, AC11) Subtract (ACLN, AC0L, AC1L) } Else { Store (ACLN, AC0L) } } Return (CRS) } } Scope (\_SB.PCI0.SBRG) { Device (ASOC) { Name (_HID, "ATK0110") Name (_UID, 0x01010110) Method (_STA, 0, NotSerialized) { Return (0x0F) } } } OperationRegion (\_SB.PCI0.SBRG.LPDC, PCI_Config, 0xA0, 0x06) Field (\_SB.PCI0.SBRG.LPDC, ByteAcc, NoLock, Preserve) { S3F8, 1, S2F8, 1, , 3, S2E8, 1, , 1, S3E8, 1, , 4, M300, 1, , 2, M330, 1, , 4, FDC0, 1, Offset (0x03), P378, 1, P278, 1, P3BC, 1, Offset (0x04), G200, 8, G208, 8 } Method (RRIO, 4, NotSerialized) { If (LOr (LEqual (Arg0, 0x00), LEqual (Arg0, 0x01))) { If (LEqual (Arg2, 0x03F8)) { Store (Arg1, S3F8) } If (LEqual (Arg2, 0x02F8)) { Store (Arg1, S2F8) } If (LEqual (Arg2, 0x03E8)) { Store (Arg1, S3E8) } If (LEqual (Arg2, 0x02E8)) { Store (Arg1, S2E8) } } If (LEqual (Arg0, 0x02)) { If (LEqual (Arg2, 0x0378)) { Store (Arg1, P378) } If (LEqual (Arg2, 0x0278)) { Store (Arg1, P278) } If (LEqual (Arg2, 0x03BC)) { Store (Arg1, P3BC) } } If (LEqual (Arg0, 0x03)) { Store (Arg1, FDC0) } If (LEqual (Arg0, 0x05)) { If (LEqual (Arg2, 0x0330)) { Store (Arg1, M330) } If (LEqual (Arg2, 0x0300)) { Store (Arg1, M300) } } If (LEqual (Arg0, 0x08)) { Store (Zero, Local0) If (Arg1) { Store (0xFF, Local0) } If (LEqual (Arg2, 0x0200)) { Store (Local0, G200) } If (LEqual (Arg2, 0x0208)) { Store (Local0, G208) } } } Method (RDMA, 3, NotSerialized) { } Scope (\) { OperationRegion (\RAMW, SystemMemory, Subtract (TOPM, 0x00010000), 0x00010000) Field (\RAMW, ByteAcc, NoLock, Preserve) { PAR0, 32, PAR1, 32 } OperationRegion (IOB2, SystemIO, 0x082E, 0x02) Field (IOB2, ByteAcc, NoLock, Preserve) { SMIC, 8, SMIS, 8 } Method (ISMI, 1, Serialized) { Store (Arg0, SMIC) } Method (GNVS, 1, Serialized) { Store (Arg0, PAR0) ISMI (0x70) Return (PAR1) } Method (SNVS, 2, Serialized) { Store (Arg0, PAR0) Store (Arg1, PAR1) ISMI (0x71) } } Scope (\) { Field (\RAMW, ByteAcc, NoLock, Preserve) { Offset (0x08), ADSP, 32, FSBF, 16, FVCM, 8, AITU, 8, FIDV, 8, VIDV, 8, OCPI, 8, NOST, 8, NOS1, 8, DDRV, 8, CPUS, 1, CQFS, 3, CQFT, 4, AIDI, 8, OVID, 8, CCAQ, 8, MAXF, 8, MAXV, 8, CURF, 8, CURV, 8, PCEF, 8 } } OperationRegion (\_SB.PCI0.PCLK.MNCK, PCI_Config, 0x44, 0x04) Field (\_SB.PCI0.PCLK.MNCK, ByteAcc, NoLock, Preserve) { MMNN, 16, , 14, MNEN, 1, Offset (0x04) } OperationRegion (\_SB.PCI0.PCLK.SPRD, PCI_Config, 0x54, 0x04) Field (\_SB.PCI0.PCLK.SPRD, ByteAcc, NoLock, Preserve) { SPRE, 1, Offset (0x04) } OperationRegion (QDRV, SystemIO, IOGB, 0x03) Field (QDRV, ByteAcc, NoLock, Preserve) { Offset (0x02), , 1, QDDR, 4, Offset (0x03) } OperationRegion (DEB0, SystemIO, 0x1080, 0x02) Field (DEB0, ByteAcc, NoLock, Preserve) { DB16, 16 } Name (DDRT, Package (0x0A) { 0x0D, 0x0F, 0x0E, 0x0D, 0x0B, 0x07, 0x09, 0x08, 0x03, 0x02 }) Scope (\_SB.PCI0.SBRG.ASOC) { Name (MBIF, Package (0x08) { 0x01, "A8N32-SLI", 0x01, 0x01, 0x02, 0x00, 0x00, 0x00 }) Method (ASIF, 0, NotSerialized) { Return (MBIF) } Name (OC01, Package (0x06) { 0x01010000, "CPU FSB", 0x4E20, 0x9C40, 0xC9, 0x00010003 }) Name (OC02, Package (0x06) { 0x01060001, "CPU Multiplier", 0x04, 0x19, 0x16, 0x00010000 }) Name (OC03, Package (0x06) { 0x01060002, "FID VID Mode", 0x00, 0x01, 0x01, 0x00010000 }) Name (OC04, Package (0x06) { 0x07010003, "PCI Express", 0x2710, 0x332C, 0x65, 0x00 }) Name (OC05, Package (0x06) { 0x05050004, "OC Profile", 0x00, 0x04, 0x05, 0x00010001 }) Name (OC06, Package (0x06) { 0x08050005, "Turbo NOS", 0x00, 0x04, 0x05, 0x00010000 }) Name (OC07, Package (0x06) { 0x08060006, "NOS MODE", 0x00, 0x03, 0x04, 0x00 }) Name (OC08, Package (0x06) { 0x04060003, "CPU Q-Fan Control", 0x00, 0x01, 0x01, 0x00010003 }) Name (OC09, Package (0x06) { 0x01020008, "CPU VID", 0x1F40, 0x3D09, 0x3D, 0x00010000 }) Name (OC0A, Package (0x06) { 0x02020009, "DRAM Voltage", 0x0A28, 0x0BB8, 0x09, 0x00010003 }) Name (OC0B, Package (0x06) { 0x0906000C, "AI Overclock Tuner", 0x00, 0x04, 0x05, 0x00010003 }) Name (OC0C, Package (0x06) { 0x0106000B, "Cool&Quiet Support", 0x00, 0x01, 0x02, 0x00010003 }) Name (OBUF, Package (0x0C) { OC01, OC02, OC03, OC04, OC05, OC06, OC07, OC08, OC09, OC0A, OC0B, OC0C }) Name (OCVO, 0x00) Method (OCIF, 0, NotSerialized) { Store (ShiftLeft (MAXV, 0x01), Local1) Subtract (0x3D09, Multiply (Local1, 0x7D), Index (OC09, 0x03)) Subtract (0x3D, Local1, Index (OC09, 0x04)) Return (OBUF) } Name (TEM1, Package (0x11) { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }) Method (TEMP, 1, NotSerialized) { Store (FSBF, Index (TEM1, 0x00)) Store (FVCM, Index (TEM1, 0x01)) Store (AITU, Index (TEM1, 0x02)) Store (FIDV, Index (TEM1, 0x03)) Store (VIDV, Index (TEM1, 0x04)) Store (OCPI, Index (TEM1, 0x05)) Store (NOST, Index (TEM1, 0x06)) Store (NOS1, Index (TEM1, 0x07)) Store (DDRV, Index (TEM1, 0x08)) Store (CPUS, Index (TEM1, 0x09)) Store (CQFS, Index (TEM1, 0x0A)) Store (CQFT, Index (TEM1, 0x0B)) Store (AIDI, Index (TEM1, 0x0C)) Store (OVID, Index (TEM1, 0x0D)) Store (CCAQ, Index (TEM1, 0x0E)) Store (MAXF, Index (TEM1, 0x0F)) Store (MAXV, Index (TEM1, 0x10)) Return (TEM1) } Method (OCOP, 1, NotSerialized) { Store (DerefOf (Index (OC01, 0x00)), Local1) If (LEqual (Arg0, Local1)) { Store (FSBF, Local0) Multiply (Local0, 0x64, Local1) Store (Local1, Index (CPUO, 0x01)) Subtract (Local0, 0xC8, Local2) Store (Local2, Index (CPUO, 0x02)) Return (CPUO) } Store (DerefOf (Index (OC02, 0x00)), Local1) If (LEqual (Arg0, Local1)) { Store (Add (ShiftRight (CURF, 0x01), 0x04), Index (CPUM, 0x01)) Store (Add (ShiftRight (CURF, 0x01), 0x04), Index (CPUM, 0x02)) If (LEqual (FVCM, 0x01)) { Store (0x00010000, Index (OC02, 0x05)) Store (0x00, Index (CPUM, 0x03)) } Else { Store (0x00010000, Index (OC02, 0x05)) Store (0x00, Index (CPUM, 0x03)) } Store (Add (ShiftRight (MAXF, 0x01), 0x04), Index (OC02, 0x03)) Add (0x01, DerefOf (Index (OC02, 0x03)), Local0) Store (DerefOf (Index (OC02, 0x02)), Local1) Subtract (Local0, Local1, Index (OC02, 0x04)) Return (CPUM) } Store (DerefOf (Index (OC03, 0x00)), Local1) If (LEqual (Arg0, Local1)) { Store (FVCM, Index (CPFV, 0x02)) If (LEqual (CCAQ, 0x00)) { Store (0x00010000, Index (OC03, 0x05)) Store (0x00, Index (CPFV, 0x03)) } Else { Store (0x00010003, Index (OC03, 0x05)) Store (0x01, Index (CPFV, 0x03)) } Return (CPFV) } Store (DerefOf (Index (OC04, 0x00)), Local1) If (LEqual (Arg0, Local1)) { Return (PCIV) } Store (DerefOf (Index (OC05, 0x00)), Local1) If (LEqual (Arg0, Local1)) { Store (OCPI, Index (OCPR, 0x02)) If (LNot (LGreater (AITU, 0x03))) { Store (0x00010003, Index (OC05, 0x05)) Store (0x01, Index (OCPR, 0x03)) } Else { Store (0x00010003, Index (OC05, 0x05)) Store (0x01, Index (OCPR, 0x03)) } Return (OCPR) } Store (DerefOf (Index (OC06, 0x00)), Local1) If (LEqual (Arg0, Local1)) { If (LEqual (AITU, 0x04)) { Store (NOS1, Index (NOSP, 0x02)) } Else { Store (0x00, Index (NOSP, 0x02)) } Return (NOSP) } Store (DerefOf (Index (OC07, 0x00)), Local1) If (LEqual (Arg0, Local1)) { Store (NOST, Index (NOSM, 0x02)) Return (NOSM) } Store (DerefOf (Index (OC08, 0x00)), Local1) If (LEqual (Arg0, Local1)) { Store (CPUS, Index (FANB, 0x02)) Return (FANB) } Store (DerefOf (Index (OC09, 0x00)), Local1) If (LEqual (Arg0, Local1)) { Store (Subtract (CURV, MAXV), Local2) ShiftLeft (Local2, 0x01, Local2) And (OVID, 0x01, Local3) Or (Local2, Local3, Local2) Store (Local2, Index (CPUV, 0x02)) Store (ShiftLeft (MAXV, 0x01), Local2) Subtract (0x3D09, Multiply (Local2, 0x7D), Index (OC09, 0x03)) Subtract (0x3D, Local2, Index (OC09, 0x04)) Return (CPUV) } Store (DerefOf (Index (OC0A, 0x00)), Local1) If (LEqual (Arg0, Local1)) { Store (DDRV, Index (DDVO, 0x02)) Return (DDVO) } Store (DerefOf (Index (OC0B, 0x00)), Local1) If (LEqual (Arg0, Local1)) { Store (AITU, Index (AIOT, 0x02)) Return (AIOT) } Store (DerefOf (Index (OC0C, 0x00)), Local1) If (LEqual (Arg0, Local1)) { Store (CCAQ, Index (ACAQ, 0x02)) Return (ACAQ) } } Name (CPUO, Package (0x04) { 0x01010000, 0x4E20, 0x00, 0x01 }) Name (CPUM, Package (0x04) { 0x01060001, 0x00, 0x00, 0x00 }) Name (CPFV, Package (0x06) { 0x01060002, 0x00, 0x00, 0x00, "Auto", "Manual" }) Name (PCIV, Package (0x04) { 0x07010003, 0x2710, 0x64, 0x00 }) Name (OCPR, Package (0x09) { 0x05050004, 0x00, 0x00, 0x00, "Overclock 1%", "Overclock 3%", "Overclock 5%", "Overclock 8%", "Overclock 10%" }) Name (NOSP, Package (0x09) { 0x08050005, 0x00, 0x00, 0x01, "Overclock 1%", "Overclock 3%", "Overclock 5%", "Overclock 8%", "Overclock 10%" }) Name (NOSM, Package (0x08) { 0x08060006, 0x00, 0x00, 0x00, "Auto", "Standard%", "Sensitive", "Heavy Load" }) Name (FANB, Package (0x06) { 0x04040007, 0x00, 0x00, 0x01, "Disabled", "Enabled" }) Name (CPUV, Package (0x04) { 0x01020008, 0x00, 0x00, 0x01 }) Name (DDVO, Package (0x0E) { 0x02020009, 0x00, 0x00, 0x01, "Auto", "2.60V", "2.65V", "2.70V", "2.75V", "2.80V", "2.85V", "2.90V", "2.95V", "3.00V" }) Name (AIOT, Package (0x09) { 0x0906000C, 0x00, 0x00, 0x01, "Manual", "Auto", "Standard", "OverClock Profile", "AI NOS" }) Name (ACAQ, Package (0x06) { 0x0106000B, 0x00, 0x00, 0x00, "Enabled", "Disabled" }) Name (OCST, Package (0x0C) { Package (0x02) { 0x01010000, 0x01 }, Package (0x02) { 0x01060001, 0x01 }, Package (0x02) { 0x01060002, 0x01 }, Package (0x02) { 0x07010003, 0x01 }, Package (0x02) { 0x05050004, 0x01 }, Package (0x02) { 0x08050005, 0x01 }, Package (0x02) { 0x08060006, 0x01 }, Package (0x02) { 0x04060003, 0x01 }, Package (0x02) { 0x01020008, 0x01 }, Package (0x02) { 0x02020009, 0x01 }, Package (0x02) { 0x0906000C, 0x01 }, Package (0x02) { 0x0106000B, 0x01 } }) Method (PROC, 3, NotSerialized) { Store (DerefOf (Index (OC01, 0x00)), Local1) If (LEqual (Arg0, Local1)) { Store (Arg1, Local2) Add (Local2, 0xC8, Local2) If (LEqual (Arg2, 0x00)) { If (LNot (LGreater (AITU, 0x03))) { If (LNot (LLess (FSBF, Local2))) { Subtract (FSBF, Local2, Local0) } Else { Subtract (Local2, FSBF, Local0) } If (LGreater (Local0, 0x0A)) { Store (0x03, Index (DerefOf (Index (OCST, 0x00)), 0x01)) Return (0x03) } Store (0x01, Index (DerefOf (Index (OCST, 0x00)), 0x01)) Return (0x01) } Else { Store (0x03, Index (DerefOf (Index (OCST, 0x00)), 0x01)) Return (0x03) } } If (LNot (LLess (FSBF, Local2))) { Subtract (FSBF, Local2, Local0) } Else { Subtract (Local2, FSBF, Local0) } Store (Local2, FSBF) If (LNot (LGreater (AITU, 0x03))) { Store (0x00, SMIS) Store (0xAB, SMIC) Store (0x00, AITU) Store (0x02, SMIS) Store (0xAB, SMIC) If (LGreater (Local0, 0x0A)) { Store (0x03, Index (DerefOf (Index (OCST, 0x00)), 0x01)) Return (0x03) } Store (0xAA, SMIS) Store (0xAB, SMIC) Store (0x01, Index (DerefOf (Index (OCST, 0x00)), 0x01)) Return (0x01) } Store (0x00, SMIS) Store (0xAB, SMIC) Store (0x00, AITU) Store (0x02, SMIS) Store (0xAB, SMIC) Store (0x03, Index (DerefOf (Index (OCST, 0x00)), 0x01)) Return (0x03) } Store (DerefOf (Index (OC02, 0x00)), Local1) If (LEqual (Arg0, Local1)) { If (LEqual (Arg2, 0x00)) { Store (0x03, Index (DerefOf (Index (OCST, 0x01)), 0x01)) Return (0x03) } If (LEqual (CCQA, 0x00)) { Store (0x01, CCAQ) Store (0x0C, SMIS) Store (0xAB, SMIC) Store (0x01, FVCM) Store (0x01, SMIS) Store (0xAB, SMIC) Store (ShiftLeft (Subtract (Arg1, 0x04), 0x01), FIDV) Store (0x03, SMIS) Store (0xAB, SMIC) Store (0x03, Index (DerefOf (Index (OCST, 0x01)), 0x01)) Return (0x03) } If (LEqual (FVCM, 0x00)) { Store (0x01, FVCM) Store (0x01, SMIS) Store (0xAB, SMIC) Store (ShiftLeft (Subtract (Arg1, 0x04), 0x01), FIDV) Store (0x03, SMIS) Store (0xAB, SMIC) Store (0x03, Index (DerefOf (Index (OCST, 0x01)), 0x01)) Return (0x03) } Store (ShiftLeft (Subtract (Arg1, 0x04), 0x01), FIDV) Store (0x03, SMIS) Store (0xAB, SMIC) Store (0x03, Index (DerefOf (Index (OCST, 0x01)), 0x01)) Return (0x03) } Store (DerefOf (Index (OC03, 0x00)), Local1) If (LEqual (Arg0, Local1)) { If (LEqual (Arg2, 0x00)) { Store (0x03, Index (DerefOf (Index (OCST, 0x02)), 0x01)) Return (0x03) } If (LEqual (CCAQ, 0x00)) { Store (0x01, CCAQ) Store (0x0C, SMIS) Store (0xAB, SMIC) Store (Arg1, FVCM) Store (0x01, SMIS) Store (0xAB, SMIC) Store (0x03, Index (DerefOf (Index (OCST, 0x02)), 0x01)) Return (0x03) } Store (Arg1, FVCM) Store (0x01, SMIS) Store (0xAB, SMIC) Store (0x03, Index (DerefOf (Index (OCST, 0x02)), 0x01)) Return (0x03) } Store (DerefOf (Index (OC04, 0x00)), Local1) If (LEqual (Arg0, Local1)) { Store (0x03, Index (DerefOf (Index (OCST, 0x03)), 0x01)) Return (0x03) } Store (DerefOf (Index (OC05, 0x00)), Local1) If (LEqual (Arg0, Local1)) { If (LEqual (Arg2, 0x00)) { If (LNot (LGreater (AITU, 0x03))) { Store (0x01, Index (DerefOf (Index (OCST, 0x04)), 0x01)) Return (0x01) } Store (0x03, Index (DerefOf (Index (OCST, 0x04)), 0x01)) Return (0x03) } If (LNot (LGreater (AITU, 0x03))) { Store (0x03, AITU) Store (0x02, SMIS) Store (0xAB, SMIC) Store (Arg1, OCPI) Store (0x05, SMIS) Store (0xAB, SMIC) If (LEqual (Arg1, 0x00)) { Store (0xCA, FSBF) Store (0x00, SMIS) Store (0xAB, SMIC) } If (LEqual (Arg1, 0x01)) { Store (0xCE, FSBF) Store (0x00, SMIS) Store (0xAB, SMIC) } If (LEqual (Arg1, 0x02)) { Store (0xD2, FSBF) Store (0x00, SMIS) Store (0xAB, SMIC) } If (LEqual (Arg1, 0x03)) { Store (0xD8, FSBF) Store (0x00, SMIS) Store (0xAB, SMIC) } If (LEqual (Arg1, 0x04)) { Store (0xDC, FSBF) Store (0x00, SMIS) Store (0xAB, SMIC) } Store (0xAA, SMIS) Store (0xAB, SMIC) Store (0x01, Index (DerefOf (Index (OCST, 0x04)), 0x01)) Return (0x01) } Store (0x03, AITU) Store (0x02, SMIS) Store (0xAB, SMIC) Store (Arg1, OCPI) Store (0x05, SMIS) Store (0xAB, SMIC) Store (0x03, Index (DerefOf (Index (OCST, 0x04)), 0x01)) Return (0x03) } Store (DerefOf (Index (OC06, 0x00)), Local1) If (LEqual (Arg0, Local1)) { If (LEqual (Arg2, 0x00)) { If (LNot (LGreater (AITU, 0x03))) { Store (0x03, Index (DerefOf (Index (OCST, 0x05)), 0x01)) Return (0x03) } If (LEqual (Arg1, 0x00)) { Store (0x03, Index (DerefOf (Index (OCST, 0x05)), 0x01)) Return (0x03) } Store (0x01, Index (DerefOf (Index (OCST, 0x05)), 0x01)) Return (0x01) } If (LNot (LGreater (AITU, 0x03))) { Store (0x04, AITU) Store (0x02, SMIS) Store (0xAB, SMIC) Store (Arg1, NOS1) Store (0x07, SMIS) Store (0xAB, SMIC) Store (0x03, Index (DerefOf (Index (OCST, 0x05)), 0x01)) Return (0x03) } If (LEqual (Arg1, 0x00)) { Store (0x01, AITU) Store (0x02, SMIS) Store (0xAB, SMIC) Store (Arg1, NOS1) Store (0x07, SMIS) Store (0xAB, SMIC) Store (0x03, Index (DerefOf (Index (OCST, 0x05)), 0x01)) Return (0x03) } Store (Arg1, NOS1) Store (0x07, SMIS) Store (0xAB, SMIC) Store (0x01, Index (DerefOf (Index (OCST, 0x05)), 0x01)) Return (0x01) } Store (DerefOf (Index (OC07, 0x00)), Local1) If (LEqual (Arg0, Local1)) { Store (0x01, Index (DerefOf (Index (OCST, 0x06)), 0x01)) Return (0x01) } Store (DerefOf (Index (OC08, 0x00)), Local1) If (LEqual (Arg0, Local1)) { If (LEqual (Arg2, 0x00)) { Store (0x01, Index (DerefOf (Index (OCST, 0x07)), 0x01)) Return (0x01) } Store (Arg1, CPUS) Store (0x09, SMIS) Store (0xAB, SMIC) Store (0xBB, SMIS) Store (0xAB, SMIC) Store (0x01, Index (DerefOf (Index (OCST, 0x07)), 0x01)) Return (0x01) } Store (DerefOf (Index (OC09, 0x00)), Local1) If (LEqual (Arg0, Local1)) { If (LEqual (Arg2, 0x00)) { Store (0x03, Index (DerefOf (Index (OCST, 0x08)), 0x01)) Return (0x03) } Store (CURF, FIDV) Store (0x03, SMIS) Store (0xAB, SMIC) Store (0x01, CCAQ) Store (0x0C, SMIS) Store (0xAB, SMIC) Store (0x01, FVCM) Store (0x01, SMIS) Store (0xAB, SMIC) Store (Add (Arg1, ShiftLeft (MAXV, 0x01)), OVID) Store (0x0B, SMIS) Store (0xAB, SMIC) Store (ShiftRight (Add (Arg1, ShiftLeft (MAXV, 0x01)), 0x01), VIDV) Store (0x04, SMIS) Store (0xAB, SMIC) Store (0x03, Index (DerefOf (Index (OCST, 0x08)), 0x01)) Return (0x03) } Store (DerefOf (Index (OC0A, 0x00)), Local1) If (LEqual (Arg0, Local1)) { If (LEqual (Arg2, 0x00)) { Store (0x01, Index (DerefOf (Index (OCST, 0x09)), 0x01)) Return (0x01) } If (LEqual (Arg1, DDRV)) { Store (0x01, Index (DerefOf (Index (OCST, 0x09)), 0x01)) Return (0x01) } Store (Arg1, DDRV) Store (0x08, SMIS) Store (0xAB, SMIC) Store (DerefOf (Index (DDRT, Arg1)), QDDR) Store (0x01, Index (DerefOf (Index (OCST, 0x09)), 0x01)) Return (0x01) } Store (DerefOf (Index (OC0B, 0x00)), Local1) If (LEqual (Arg0, Local1)) { If (LEqual (Arg2, 0x00)) { If (LNot (LEqual (Arg1, AITU))) { Store (0x03, Index (DerefOf (Index (OCST, 0x0A)), 0x01)) Return (0x03) } Store (0x01, Index (DerefOf (Index (OCST, 0x0A)), 0x01)) Return (0x01) } If (LNot (LEqual (Arg1, AITU))) { Store (Arg1, AITU) Store (0x02, SMIS) Store (0xAB, SMIC) Store (0x03, Index (DerefOf (Index (OCST, 0x0A)), 0x01)) Return (0x03) } Store (Arg1, AITU) Store (0x02, SMIS) Store (0xAB, SMIC) Store (0x01, Index (DerefOf (Index (OCST, 0x0A)), 0x01)) Return (0x01) } Store (DerefOf (Index (OC0C, 0x00)), Local1) If (LEqual (Arg0, Local1)) { If (LEqual (Arg2, 0x00)) { If (LEqual (Arg1, CCAQ)) { Store (0x01, Index (DerefOf (Index (OCST, 0x0B)), 0x01)) Return (0x01) } Store (0x03, Index (DerefOf (Index (OCST, 0x0B)), 0x01)) Return (0x03) } If (LEqual (Arg1, CCAQ)) { Store (0x01, Index (DerefOf (Index (OCST, 0x0B)), 0x01)) Return (0x01) } Store (Arg1, CCAQ) Store (0x09, SMIS) Store (0xAB, SMIC) Store (0x03, Index (DerefOf (Index (OCST, 0x0B)), 0x01)) Return (0x03) } } Method (GETM, 1, NotSerialized) { Multiply (Add (Arg0, 0x01), 0x03E8, Local0) Store (0xFFFF, Local6) Store (0x10, Local1) While (LNot (LGreater (Local1, 0x80))) { Store (0x10, Local2) While (LNot (LGreater (Local2, 0x80))) { Store (Divide (Multiply (Local2, 0x0005E9AC), Multiply (Local1, 0x04), ), Local3) Multiply (Local3, 0x02, Local3) If (LGreater (Local3, Local0)) { Store (Subtract (Local3, Local0), Local3) } Else { Store (Subtract (Local0, Local3), Local3) } If (LLess (Local3, Local6)) { Store (Local1, Local4) Store (Local2, Local5) Store (Local3, Local6) } Increment (Local2) } Increment (Local1) } ShiftLeft (Local5, 0x08, Local1) Or (Local1, Local4, Local6) And (Local6, 0xFFFF, Local6) Return (Local6) } } Device (\_SB.PCI0.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 (\_PR) { Processor (CPU1, 0x01, 0x00005010, 0x06) { Name (_PCT, Package (0x02) { ResourceTemplate () { Register (FFixedHW, 0x00, 0x00, 0x0000000000000000) }, ResourceTemplate () { Register (FFixedHW, 0x00, 0x00, 0x0000000000000000) } }) Name (_PSS, Package (0x04) { Package (0x06) { 0x00000898, 0x000105B8, 0x00000064, 0x00000007, 0xE020298E, 0x0000018E }, Package (0x06) { 0x000007D0, 0x0000DAC0, 0x00000064, 0x00000007, 0xE0202A0C, 0x0000020C }, Package (0x06) { 0x00000708, 0x0000B3B0, 0x00000064, 0x00000007, 0xE0202A8A, 0x0000028A }, Package (0x06) { 0x000003E8, 0x00004E20, 0x00000064, 0x00000007, 0xE0202C82, 0x00000482 } }) Name (PSXG, Buffer (0x18) { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }) Name (PSXF, Buffer (0x18) { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }) Name (PSXE, Buffer (0x18) { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }) Name (PSXD, Buffer (0x18) { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }) Name (PSXC, Buffer (0x18) { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }) Name (PSXB, Buffer (0x18) { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }) Method (_PPC, 0, NotSerialized) { Return (0x00) } } Processor (CPU2, 0x02, 0x00000000, 0x00) { Name (APCT, Package (0x02) { ResourceTemplate () { Register (FFixedHW, 0x00, 0x00, 0x0000000000000000) }, ResourceTemplate () { Register (FFixedHW, 0x00, 0x00, 0x0000000000000000) } }) Name (APSS, Package (0x0A) { Package (0x06) { 0x09999999, 0x00099999, 0x00999999, 0x00999999, 0x99999999, 0x99999999 }, Package (0x06) { 0x09999999, 0x00099999, 0x00999999, 0x00999999, 0x99999999, 0x99999999 }, Package (0x06) { 0x09999999, 0x00099999, 0x00999999, 0x00999999, 0x99999999, 0x99999999 }, Package (0x06) { 0x09999999, 0x00099999, 0x00999999, 0x00999999, 0x99999999, 0x99999999 }, Package (0x06) { 0x09999999, 0x00099999, 0x00999999, 0x00999999, 0x99999999, 0x99999999 }, Package (0x06) { 0x09999999, 0x00099999, 0x00999999, 0x00999999, 0x99999999, 0x99999999 }, Package (0x06) { 0x09999999, 0x00099999, 0x00999999, 0x00999999, 0x99999999, 0x99999999 }, Package (0x06) { 0x09999999, 0x00099999, 0x00999999, 0x00999999, 0x99999999, 0x99999999 }, Package (0x06) { 0x09999999, 0x00099999, 0x00999999, 0x00999999, 0x99999999, 0x99999999 }, Package (0x06) { 0x09999999, 0x00099999, 0x00999999, 0x00999999, 0x99999999, 0x99999999 } }) Method (APPC, 0, NotSerialized) { Return (0x00) } } } Device (OMSC) { Name (_HID, EisaId ("PNP0C02")) Name (_UID, 0x00) 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 (\_SB.RMEM) { Name (_HID, EisaId ("PNP0C01")) Name (_UID, 0x01) 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) Add (MG2B, MG2L, BAS4) Subtract (0x00, BAS4, LEN4) Return (CRS) } } Device (PS2K) { Name (_HID, EisaId ("PNP0303")) Name (_CID, 0x0B03D041) Method (_STA, 0, NotSerialized) { ShiftLeft (0x01, 0x0A, Local0) If (And (IOST, Local0)) { Return (0x0F) } Return (0x00) } Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0060, 0x0060, 0x00, 0x01) IO (Decode16, 0x0064, 0x0064, 0x00, 0x01) IRQNoFlags () {1} }) } Method (PS2K._PRW, 0, NotSerialized) { Return (GPRW (0x10, 0x04)) } Device (PS2M) { Name (_HID, EisaId ("PNP0F03")) Name (_CID, 0x130FD041) Method (_STA, 0, NotSerialized) { ShiftLeft (0x01, 0x0C, Local0) If (And (IOST, Local0)) { Return (0x0F) } Return (0x00) } Name (CRS1, ResourceTemplate () { IRQNoFlags () {12} }) Name (CRS2, ResourceTemplate () { IO (Decode16, 0x0060, 0x0060, 0x00, 0x01) IO (Decode16, 0x0064, 0x0064, 0x00, 0x01) IRQNoFlags () {12} }) Method (_CRS, 0, NotSerialized) { ShiftLeft (0x01, 0x0A, Local0) If (And (IOST, Local0)) { Return (CRS1) } Else { Return (CRS2) } } } Method (PS2M._PRW, 0, NotSerialized) { Return (GPRW (0x10, 0x04)) } Device (UAR1) { Name (_UID, 0x01) Method (_HID, 0, NotSerialized) { Return (UHID (0x00)) } Method (_STA, 0, NotSerialized) { Return (DSTA (0x00)) } Method (_DIS, 0, NotSerialized) { DCNT (0x00, 0x00) } Method (_CRS, 0, NotSerialized) { Return (DCRS (0x00, 0x01)) } Method (_SRS, 1, NotSerialized) { DSRS (Arg0, 0x00) } Method (_PRS, 0, NotSerialized) { Return (CMPR) } Name (CMPR, ResourceTemplate () { StartDependentFn (0x00, 0x00) { IO (Decode16, 0x03F8, 0x03F8, 0x01, 0x08) IRQNoFlags () {4} DMA (Compatibility, NotBusMaster, Transfer8) {} } StartDependentFnNoPri () { IO (Decode16, 0x03F8, 0x03F8, 0x01, 0x08) IRQNoFlags () {3,4,5,6,7,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8) {} } StartDependentFnNoPri () { IO (Decode16, 0x02F8, 0x02F8, 0x01, 0x08) IRQNoFlags () {3,4,5,6,7,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8) {} } StartDependentFnNoPri () { IO (Decode16, 0x03E8, 0x03E8, 0x01, 0x08) IRQNoFlags () {3,4,5,6,7,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8) {} } StartDependentFnNoPri () { IO (Decode16, 0x02E8, 0x02E8, 0x01, 0x08) IRQNoFlags () {3,4,5,6,7,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8) {} } StartDependentFnNoPri () { IO (Decode16, 0x03F8, 0x03F8, 0x01, 0x08) IRQNoFlags () {3,4,5,6,7,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8) {0,1,2,3} } StartDependentFnNoPri () { IO (Decode16, 0x02F8, 0x02F8, 0x01, 0x08) IRQNoFlags () {3,4,5,6,7,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8) {0,1,2,3} } StartDependentFnNoPri () { IO (Decode16, 0x03E8, 0x03E8, 0x01, 0x08) IRQNoFlags () {3,4,5,6,7,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8) {0,1,2,3} } StartDependentFnNoPri () { IO (Decode16, 0x02E8, 0x02E8, 0x01, 0x08) IRQNoFlags () {3,4,5,6,7,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8) {0,1,2,3} } EndDependentFn () }) } Method (UAR1._PRW, 0, NotSerialized) { Return (GPRW (0x03, 0x04)) } Device (SIOR) { Name (_HID, EisaId ("PNP0C02")) Method (_UID, 0, NotSerialized) { Return (SPIO) } Name (CRS, ResourceTemplate () { IO (Decode16, 0x0000, 0x0000, 0x00, 0x00) IO (Decode16, 0x0000, 0x0000, 0x00, 0x00) IO (Decode16, 0x0000, 0x0000, 0x00, 0x00) IO (Decode16, 0x0000, 0x0000, 0x00, 0x00) IO (Decode16, 0x0000, 0x0000, 0x00, 0x00) }) Method (_CRS, 0, NotSerialized) { If (LAnd (LNot (LEqual (SPIO, 0x03F0)), LGreater (SPIO, 0xF0))) { CreateWordField (CRS, 0x02, GP10) CreateWordField (CRS, 0x04, GP11) CreateByteField (CRS, 0x07, GPL1) Store (SPIO, GP10) Store (SPIO, GP11) Store (0x02, GPL1) } If (IOPB) { CreateWordField (CRS, 0x0A, GP20) CreateWordField (CRS, 0x0C, GP21) CreateByteField (CRS, 0x0F, GPL2) Store (IOPB, GP20) Store (IOPB, GP21) Store (IOPL, GPL2) } If (IOEB) { CreateWordField (CRS, 0x12, GP30) CreateWordField (CRS, 0x14, GP31) CreateByteField (CRS, 0x17, GPL3) Store (IOEB, GP30) Store (IOEB, GP31) Store (IOEL, GPL3) } If (IOGB) { CreateWordField (CRS, 0x1A, GP40) CreateWordField (CRS, 0x1C, GP41) CreateByteField (CRS, 0x1F, GPL4) Store (IOGB, GP40) Store (IOGB, GP41) Store (IOGL, GPL4) } If (IODB) { CreateWordField (CRS, 0x22, GP50) CreateWordField (CRS, 0x24, GP51) CreateByteField (CRS, 0x27, GPL5) Store (IODB, GP50) Store (IODB, GP51) Store (IODL, GPL5) } Return (CRS) } } Name (DCAT, Package (0x16) { 0x01, 0x02, 0x03, 0x00, 0xFF, 0x08, 0xFF, 0xFF, 0x09, 0xFF, 0x05, 0x04, 0xFF, 0xFF, 0xFF, 0xFF, 0x0A, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF }) Name (IKEY, Package (0x02) { Package (0x04) { 0x87, 0x01, 0x55, 0x55 }, Package (0x04) { 0x87, 0x01, 0x55, 0xAA } }) Name (KBFG, 0x01) Name (MSFG, 0x01) Name (UR1F, 0x01) Method (ENFG, 1, NotSerialized) { Store (0x00, Local1) If (LEqual (SPIO, 0x2E)) { Store (0x00, Local1) } If (LEqual (SPIO, 0x4E)) { Store (0x01, Local1) } Store (0x00, Local0) While (LNot (LEqual (Local0, 0x04))) { Store (DerefOf (Index (DerefOf (Index (IKEY, Local1)), Local0)), INDX) Increment (Local0) } Store (Arg0, LDN) } Method (ENTR, 0, NotSerialized) { Store (0x87, INDX) Store (0x01, INDX) Store (0x55, INDX) If (LEqual (SPIO, 0x2E)) { Store (0x55, INDX) } Else { Store (0xAA, INDX) } } Method (EXFG, 0, NotSerialized) { Store (0x02, INDX) Store (0x02, DATA) } Method (LPTM, 1, NotSerialized) { ENFG (CGLD (Arg0)) And (OPT0, 0x02, Local0) EXFG () Return (Local0) } Method (UHID, 1, NotSerialized) { ENFG (CGLD (Arg0)) And (OPT0, 0x70, Local0) EXFG () If (Local0) { Return (0x1005D041) } Return (0x0105D041) } Method (ORF0, 1, NotSerialized) { ENTR () Or (OPT0, Arg0, OPT0) EXFG () } Method (ORF1, 1, NotSerialized) { ENTR () Or (OPT1, Arg0, OPT1) EXFG () } Method (ORF2, 1, NotSerialized) { ENTR () Or (OPT2, Arg0, OPT2) EXFG () } Method (ANF0, 1, NotSerialized) { ENTR () And (OPT0, Arg0, OPT0) EXFG () } Method (ANF2, 1, NotSerialized) { ENTR () And (OPT2, Arg0, OPT2) EXFG () } Method (ANF4, 1, NotSerialized) { ENTR () And (OPT4, Arg0, OPT4) EXFG () } Method (STF0, 1, NotSerialized) { ENTR () Store (Arg0, OPT0) EXFG () } Method (STF1, 1, NotSerialized) { ENTR () Store (Arg0, OPT1) EXFG () } Method (SIOS, 1, NotSerialized) { Store ("SIOS", Debug) Store (0x00, GP10) If (LLess (Arg0, 0x05)) { ENFG (0x04) Store (0x01, ACTR) EXFG () ANF4 (0xFC) ORF1 (0x18) If (KBFG) { ORF0 (0x08) } Else { ANF0 (0xF7) } If (MSFG) { ORF0 (0x10) } Else { ANF0 (0xEF) ENFG (0x06) Store (0x00, ACTR) EXFG () } ENFG (0x04) ANF2 (0xF0) ENFG (0x07) And (OPF9, 0xFE, OPF9) And (OPC0, 0xFE, OPC0) And (OPC3, 0xFE, OPC3) And (OP29, 0xEF, OP29) EXFG () } Else { ENFG (0x07) And (OPC0, 0x00, OPC0) Or (OPC0, 0x01, OPC0) And (OPC3, 0x00, OPC3) Or (OPC3, 0x01, OPC3) Or (OPF9, 0x01, OPF9) And (OP29, 0xEF, OP29) EXFG () } } Method (SIOW, 1, NotSerialized) { Store (0x01, GP10) Store (0x01, GP40) Store ("SIOW", Debug) ENFG (0x04) Store (0x00, ACTR) EXFG () STF0 (0x00) STF1 (0xFF) ENFG (0x07) Or (OP29, 0x10, OP29) Or (OPC0, 0x01, OPC0) Or (OPC3, 0x01, OPC3) EXFG () ENFG (0x05) Or (ACTR, 0x01, ACTR) EXFG () ENFG (0x06) Or (ACTR, 0x01, ACTR) EXFG () ENFG (0x04) Store (0x01, ACTR) EXFG () } Method (SIOH, 0, NotSerialized) { Store ("SIOH", Debug) } OperationRegion (IOID, SystemIO, SPIO, 0x02) Field (IOID, ByteAcc, NoLock, Preserve) { INDX, 8, DATA, 8 } IndexField (INDX, DATA, ByteAcc, NoLock, Preserve) { Offset (0x07), LDN, 8, Offset (0x29), OP29, 8, Offset (0x30), ACTR, 8, Offset (0x60), IOAH, 8, IOAL, 8, IOH2, 8, IOL2, 8, Offset (0x70), INTR, 8, Offset (0x74), DMCH, 8, Offset (0xC0), OPC0, 8, OPC1, 8, OPC2, 8, OPC3, 8, Offset (0xF0), OPT0, 8, OPT1, 8, OPT2, 8, OPT3, 8, OPT4, 8, Offset (0xF8), OPF8, 8, OPF9, 8, OPFA, 8, OPFB, 8 } Method (PS2K._PSW, 1, NotSerialized) { If (Arg0) { Store (0x01, KBFG) } Else { Store (0x00, KBFG) } } Method (PS2M._PSW, 1, NotSerialized) { If (Arg0) { Store (0x01, MSFG) } Else { Store (0x00, MSFG) } } Method (CGLD, 1, NotSerialized) { Return (DerefOf (Index (DCAT, Arg0))) } Method (DSTA, 1, NotSerialized) { ENFG (CGLD (Arg0)) Store (ACTR, Local0) EXFG () If (LEqual (Local0, 0xFF)) { Return (0x00) } And (Local0, 0x01, Local0) Or (IOST, ShiftLeft (Local0, Arg0), IOST) If (Local0) { Return (0x0F) } Else { If (And (ShiftLeft (0x01, Arg0), IOST)) { Return (0x0D) } Else { Return (0x00) } } } Method (DCNT, 2, NotSerialized) { ENFG (CGLD (Arg0)) ShiftLeft (IOAH, 0x08, Local1) Or (IOAL, Local1, Local1) RRIO (Arg0, Arg1, Local1, 0x08) If (LAnd (LLess (DMCH, 0x04), LNot (LEqual (And (DMCH, 0x03, Local1), 0x00)))) { RDMA (Arg0, Arg1, Increment (Local1)) } Store (Arg1, ACTR) EXFG () } Name (CRS1, ResourceTemplate () { IO (Decode16, 0x0000, 0x0000, 0x01, 0x00) IRQNoFlags () {} DMA (Compatibility, NotBusMaster, Transfer8) {} }) CreateWordField (CRS1, 0x09, IRQM) CreateByteField (CRS1, 0x0C, DMAM) CreateWordField (CRS1, 0x02, IO11) CreateWordField (CRS1, 0x04, IO12) CreateByteField (CRS1, 0x07, LEN1) Name (CRS2, ResourceTemplate () { IO (Decode16, 0x0000, 0x0000, 0x01, 0x00) IO (Decode16, 0x0000, 0x0000, 0x01, 0x00) IRQNoFlags () {6} DMA (Compatibility, NotBusMaster, Transfer8) {2} }) CreateWordField (CRS2, 0x11, IRQE) CreateByteField (CRS2, 0x14, DMAE) CreateWordField (CRS2, 0x02, IO21) CreateWordField (CRS2, 0x04, IO22) CreateByteField (CRS2, 0x07, LEN2) CreateWordField (CRS2, 0x0A, IO31) CreateWordField (CRS2, 0x0C, IO32) CreateByteField (CRS2, 0x0F, LEN3) Method (DCRS, 2, NotSerialized) { ENFG (CGLD (Arg0)) ShiftLeft (IOAH, 0x08, IO11) Or (IOAL, IO11, IO11) Store (IO11, IO12) Subtract (FindSetRightBit (IO11), 0x01, Local0) ShiftLeft (0x01, Local0, LEN1) If (INTR) { ShiftLeft (0x01, INTR, IRQM) } Else { Store (0x00, IRQM) } If (LOr (LGreater (DMCH, 0x03), LEqual (Arg1, 0x00))) { Store (0x00, DMAM) } Else { And (DMCH, 0x03, Local1) ShiftLeft (0x01, Local1, DMAM) } EXFG () Return (CRS1) } Method (DSRS, 2, NotSerialized) { CreateWordField (Arg0, 0x09, IRQM) CreateByteField (Arg0, 0x0C, DMAM) CreateWordField (Arg0, 0x02, IO11) ENFG (CGLD (Arg1)) And (IO11, 0xFF, IOAL) ShiftRight (IO11, 0x08, IOAH) If (IRQM) { FindSetRightBit (IRQM, Local0) Subtract (Local0, 0x01, INTR) } Else { Store (0x00, INTR) } If (DMAM) { FindSetRightBit (DMAM, Local0) Subtract (Local0, 0x01, DMCH) } Else { Store (0x04, DMCH) } EXFG () DCNT (Arg1, 0x01) } OperationRegion (GPIO, SystemIO, IO1B, 0x04) Field (GPIO, ByteAcc, NoLock, Preserve) { GP10, 1, GP11, 1, GP12, 1, GP13, 1, GO14, 1, GO15, 1, GO16, 1, GO17, 1, GP20, 1, GP21, 1, GP22, 1, GP23, 1, GO24, 1, GO25, 1, GO26, 1, GO27, 1, GP30, 1, GP31, 1, GP32, 1, GP33, 1, GO34, 1, GO35, 1, GO36, 1, GO37, 1, GP40, 1, GP41, 1, GP42, 1, GP43, 1, GO44, 1, GO45, 1, GO46, 1, GO47, 1 } } Device (NSMB) { Name (_ADR, 0x000A0001) Method (_PRW, 0, NotSerialized) { Return (GPRW (0x09, 0x04)) } } Device (USB0) { Name (_ADR, 0x000B0000) Name (_S1D, 0x01) Method (_S3D, 0, NotSerialized) { If (LOr (LEqual (OSFL (), 0x01), LEqual (OSFL (), 0x02))) { Return (0x02) } Else { Return (0x03) } } Method (_PRW, 0, NotSerialized) { Return (GPRW (0x0D, 0x04)) } } Device (USB2) { Name (_ADR, 0x000B0001) Name (_S1D, 0x01) Method (_S3D, 0, NotSerialized) { If (LOr (LEqual (OSFL (), 0x01), LEqual (OSFL (), 0x02))) { Return (0x02) } Else { Return (0x03) } } Method (_PRW, 0, NotSerialized) { Return (GPRW (0x05, 0x04)) } } Device (NMAC) { Name (_ADR, 0x00130000) Name (_PRW, Package (0x02) { 0x0B, 0x05 }) Scope (\_GPE) { Method (_L0B, 0, NotSerialized) { Notify (\_SB.PCI0.NMAC, 0x02) Notify (\_SB.PWRB, 0x02) } } } Device (IDE0) { Name (_ADR, 0x000F0000) Name (PTS0, 0x00) Name (SID0, 0x00) Name (SID1, 0x00) Name (SID2, 0x00) Name (SID3, 0x00) Name (SID4, 0x00) Name (SID5, 0x00) OperationRegion (IRQM, SystemIO, 0x21, 0x01) Field (IRQM, ByteAcc, NoLock, Preserve) { IR0M, 1 } Name (REGF, 0x01) Method (_REG, 2, NotSerialized) { If (LEqual (Arg0, 0x02)) { Store (Arg1, REGF) } } OperationRegion (A090, PCI_Config, 0x50, 0x18) Field (A090, DWordAcc, NoLock, Preserve) { ID20, 16, Offset (0x08), IDTS, 16, IDTP, 16, ID22, 32, UMSS, 16, UMSP, 16 } Name (TIM0, Package (0x07) { Package (0x05) { 0x3C, 0x78, 0xB4, 0xF0, 0x0384 }, Package (0x05) { 0x11, 0x20, 0x22, 0x47, 0xA8 }, Package (0x07) { 0x78, 0x5A, 0x3C, 0x2D, 0x1E, 0x14, 0x0F }, Package (0x05) { 0x05, 0x04, 0x03, 0x02, 0x00 }, Package (0x04) { 0x02, 0x01, 0x00, 0x00 }, Package (0x08) { 0x02, 0x01, 0x00, 0x00, 0x03, 0x04, 0x05, 0x06 }, Package (0x07) { 0x02, 0x01, 0x00, 0x04, 0x05, 0x06, 0x07 } }) Name (TMD0, Buffer (0x14) {}) CreateDWordField (TMD0, 0x00, PIO0) CreateDWordField (TMD0, 0x04, DMA0) CreateDWordField (TMD0, 0x08, PIO1) CreateDWordField (TMD0, 0x0C, DMA1) CreateDWordField (TMD0, 0x10, CHNF) OperationRegion (CFG2, PCI_Config, 0x58, 0x0C) Field (CFG2, DWordAcc, NoLock, Preserve) { SSPT, 8, SMPT, 8, PSPT, 8, PMPT, 8, SSAS, 2, SMAS, 2, PSAS, 2, PMAS, 2, Offset (0x06), SDDR, 4, SDDA, 4, PDDR, 4, PDDA, 4, SSUT, 3, , 3, SSUE, 2, SMUT, 3, , 3, SMUE, 2, PSUT, 3, , 3, PSUE, 2, PMUT, 3, , 3, PMUE, 2 } Name (GMPT, 0x00) Name (GMUE, 0x00) Name (GMUT, 0x00) Name (GSPT, 0x00) Name (GSUE, 0x00) Name (GSUT, 0x00) Device (CHN0) { Name (_ADR, 0x00) Method (_GTM, 0, NotSerialized) { Store ("GTM_CHN0", Debug) Return (GTM (PMPT, PMUE, PMUT, PSPT, PSUE, PSUT)) } Method (_STM, 3, NotSerialized) { Store ("STM_CHN0", Debug) Store (Arg0, Debug) Store (Arg0, TMD0) Store (PMPT, GMPT) Store (PMUE, GMUE) Store (PMUT, GMUT) Store (PSPT, GSPT) Store (PSUE, GSUE) Store (PSUT, GSUT) STM () Store (GMPT, PMPT) Store (GMUE, PMUE) Store (GMUT, PMUT) Store (GSPT, PSPT) Store (GSUE, PSUE) Store (GSUT, PSUT) Store (GTF (0x00, Arg1), ATA0) Store (GTF (0x01, Arg2), ATA1) } Device (DRV0) { Name (_ADR, 0x00) Method (_GTF, 0, NotSerialized) { Store ("_GTF_CHN0_DRV0", Debug) Return (RATA (ATA0)) } } Device (DRV1) { Name (_ADR, 0x01) Method (_GTF, 0, NotSerialized) { Store ("_GTF_CHN0_DRV1", Debug) Return (RATA (ATA1)) } } } Device (CHN1) { Name (_ADR, 0x01) Method (_GTM, 0, NotSerialized) { Store ("GTM_CHN1", Debug) Return (GTM (SMPT, SMUE, SMUT, SSPT, SSUE, SSUT)) } Method (_STM, 3, NotSerialized) { Store (Arg0, Debug) Store (Arg0, TMD0) Store (SMPT, GMPT) Store (SMUE, GMUE) Store (SMUT, GMUT) Store (SSPT, GSPT) Store (SSUE, GSUE) Store (SSUT, GSUT) STM () Store (GMPT, SMPT) Store (GMUE, SMUE) Store (GMUT, SMUT) Store (GSPT, SSPT) Store (GSUE, SSUE) Store (GSUT, SSUT) Store (GTF (0x00, Arg1), ATA2) Store (GTF (0x01, Arg2), ATA3) } Device (DRV0) { Name (_ADR, 0x00) Method (_GTF, 0, NotSerialized) { Store ("_GTF_CHN1_DRV0", Debug) Return (RATA (ATA2)) } } Device (DRV1) { Name (_ADR, 0x01) Method (_GTF, 0, NotSerialized) { Store ("_GTF_CHN1_DRV1", Debug) Return (RATA (ATA3)) } } } Method (DRMP, 0, NotSerialized) { ShiftRight (CPB0, 0x04, Local1) And (Local1, 0x0F, Local0) Return (Local0) } Method (GTM, 6, Serialized) { Store (Ones, PIO0) Store (Ones, PIO1) Store (Ones, DMA0) Store (Ones, DMA1) Store (0x10, CHNF) If (REGF) {} Else { Return (TMD0) } If (LEqual (PTS0, 0x01)) { If (OSFL ()) { Store (0x01, IR0M) } } Store (Match (DerefOf (Index (TIM0, 0x01)), MEQ, Arg0, MTR, 0x00, 0x00), Local6) Store (DerefOf (Index (DerefOf (Index (TIM0, 0x00)), Local6)), Local7) Store (Local7, DMA0) Store (Local7, PIO0) Store (Match (DerefOf (Index (TIM0, 0x01)), MEQ, Arg3, MTR, 0x00, 0x00), Local6) Store (DerefOf (Index (DerefOf (Index (TIM0, 0x00)), Local6)), Local7) Store (Local7, DMA1) Store (Local7, PIO1) If (Arg1) { Store (DerefOf (Index (DerefOf (Index (TIM0, 0x05)), Arg2)), Local5) Store (DerefOf (Index (DerefOf (Index (TIM0, 0x02)), Local5)), DMA0) Or (CHNF, 0x01, CHNF) } If (Arg4) { Store (DerefOf (Index (DerefOf (Index (TIM0, 0x05)), Arg5)), Local5) Store (DerefOf (Index (DerefOf (Index (TIM0, 0x02)), Local5)), DMA1) Or (CHNF, 0x04, CHNF) } Store (TMD0, Debug) Return (TMD0) } Method (STM, 0, Serialized) { If (REGF) {} Else { Return (0x00) } If (PTS0) { Store (SID0, ID20) Store (SID1, IDTS) Store (SID2, IDTP) Store (SID3, ID22) Store (SID4, UMSS) Store (SID5, UMSP) } Else { Store (ID20, SID0) Store (IDTS, SID1) Store (IDTP, SID2) Store (ID22, SID3) Store (UMSS, SID4) Store (UMSP, SID5) } Store (0x00, PTS0) Store (0x00, GMUE) Store (0x00, GMUT) Store (0x00, GSUE) Store (0x00, GSUT) If (And (CHNF, 0x01)) { Store (Match (DerefOf (Index (TIM0, 0x02)), MLE, DMA0, MTR, 0x00, 0x00), Local0) If (LGreater (Local0, 0x06)) { Store (0x06, Local0) } Store (DerefOf (Index (DerefOf (Index (TIM0, 0x06)), Local0)), GMUT) Or (GMUE, 0x03, GMUE) } Else { If (Or (LEqual (PIO0, Ones), LEqual (PIO0, 0x00))) { If (And (LLess (DMA0, Ones), LGreater (DMA0, 0x00))) { Store (DMA0, PIO0) } } } If (And (CHNF, 0x04)) { Store (Match (DerefOf (Index (TIM0, 0x02)), MLE, DMA1, MTR, 0x00, 0x00), Local0) If (LGreater (Local0, 0x06)) { Store (0x06, Local0) } Store (DerefOf (Index (DerefOf (Index (TIM0, 0x06)), Local0)), GSUT) Or (GSUE, 0x03, GSUE) } Else { If (Or (LEqual (PIO1, Ones), LEqual (PIO1, 0x00))) { If (And (LLess (DMA1, Ones), LGreater (DMA1, 0x00))) { Store (DMA1, PIO1) } } } And (Match (DerefOf (Index (TIM0, 0x00)), MGE, PIO0, MTR, 0x00, 0x00), 0x07, Local0) Store (DerefOf (Index (DerefOf (Index (TIM0, 0x01)), Local0)), Local1) Store (Local1, GMPT) And (Match (DerefOf (Index (TIM0, 0x00)), MGE, PIO1, MTR, 0x00, 0x00), 0x07, Local0) Store (DerefOf (Index (DerefOf (Index (TIM0, 0x01)), Local0)), Local1) Store (Local1, GSPT) Return (0x00) } 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, 0x00, 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 ("GTF_Entry", Debug) Store (Arg1, Debug) Store (0x00, CMDC) Name (ID49, 0x0C00) Name (ID59, 0x00) Name (ID53, 0x04) Name (ID63, 0x0F00) Name (ID88, 0x0F00) Name (IRDY, 0x01) Name (PIOT, 0x00) Name (DMAT, 0x00) 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, 0x01)) { Store (DMA0, DMAT) } } If (LAnd (LAnd (And (ID53, 0x04), And (ID88, 0xFF00)), DMAT)) { Store (Match (DerefOf (Index (TIM0, 0x02)), MLE, DMAT, MTR, 0x00, 0x00), Local1) If (LGreater (Local1, 0x06)) { Store (0x06, Local1) } GTFB (AT01, Or (0x40, Local1), Local7) } Else { If (LAnd (And (ID63, 0xFF00), PIOT)) { And (Match (DerefOf (Index (TIM0, 0x00)), MGE, PIOT, MTR, 0x00, 0x00), 0x03, Local0) Or (0x20, DerefOf (Index (DerefOf (Index (TIM0, 0x04)), Local0)), Local1) GTFB (AT01, Local1, Local7) } } If (IRDY) { And (Match (DerefOf (Index (TIM0, 0x00)), MGE, PIOT, MTR, 0x00, 0x00), 0x07, Local0) Or (0x08, DerefOf (Index (DerefOf (Index (TIM0, 0x03)), Local0)), Local1) GTFB (AT01, Local1, Local7) } Else { If (And (ID49, 0x0400)) { GTFB (AT01, 0x01, Local7) } } If (LAnd (And (ID59, 0x0100), And (ID59, 0xFF))) { GTFB (AT03, And (ID59, 0xFF), Local7) } Store ("ATAB_GTF", Debug) Store (ATAB, Debug) Return (ATAB) } Method (RATA, 1, NotSerialized) { CreateByteField (Arg0, 0x00, CMDN) Multiply (CMDN, 0x38, Local0) CreateField (Arg0, 0x08, Local0, RETB) Store (RETB, Debug) Return (RETB) } } Device (ATA0) { Name (_ADR, 0x00100000) Device (PRI0) { Name (_ADR, 0x00) Name (SPTM, Buffer (0x14) { 0x78, 0x00, 0x00, 0x00, 0x0F, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x13, 0x00, 0x00, 0x00 }) Method (_GTM, 0, NotSerialized) { Return (SPTM) } Method (_STM, 3, NotSerialized) { Store (Arg0, SPTM) } Device (MAST) { Name (_ADR, 0x00) Method (_GTF, 0, NotSerialized) { Store (Buffer (0x07) { 0x03, 0x46, 0x00, 0x00, 0x00, 0xA0, 0xEF }, Local0) Return (Local0) } } } Device (SEC0) { Name (_ADR, 0x01) Name (SSTM, Buffer (0x14) { 0x78, 0x00, 0x00, 0x00, 0x0F, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x13, 0x00, 0x00, 0x00 }) Method (_GTM, 0, NotSerialized) { Return (SSTM) } Method (_STM, 3, NotSerialized) { Store (Arg0, SSTM) } Device (MAST) { Name (_ADR, 0x00) Method (_GTF, 0, NotSerialized) { Store (Buffer (0x07) { 0x03, 0x46, 0x00, 0x00, 0x00, 0xA0, 0xEF }, Local0) Return (Local0) } } } Method (DRMP, 0, NotSerialized) { Store (0x0C, Local0) If (LEqual (_ADR, 0x00100000)) { Store (0x08, Local0) } ShiftRight (CPB0, Local0, Local1) And (Local1, 0x0F, Local0) Return (Local0) } } Device (ATA1) { Name (_ADR, 0x00110000) Device (PRI0) { Name (_ADR, 0x00) Name (SPTM, Buffer (0x14) { 0x78, 0x00, 0x00, 0x00, 0x0F, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x13, 0x00, 0x00, 0x00 }) Method (_GTM, 0, NotSerialized) { Return (SPTM) } Method (_STM, 3, NotSerialized) { Store (Arg0, SPTM) } Device (MAST) { Name (_ADR, 0x00) Method (_GTF, 0, NotSerialized) { Store (Buffer (0x07) { 0x03, 0x46, 0x00, 0x00, 0x00, 0xA0, 0xEF }, Local0) Return (Local0) } } } Device (SEC0) { Name (_ADR, 0x01) Name (SSTM, Buffer (0x14) { 0x78, 0x00, 0x00, 0x00, 0x0F, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x13, 0x00, 0x00, 0x00 }) Method (_GTM, 0, NotSerialized) { Return (SSTM) } Method (_STM, 3, NotSerialized) { Store (Arg0, SSTM) } Device (MAST) { Name (_ADR, 0x00) Method (_GTF, 0, NotSerialized) { Store (Buffer (0x07) { 0x03, 0x46, 0x00, 0x00, 0x00, 0xA0, 0xEF }, Local0) Return (Local0) } } } Method (DRMP, 0, NotSerialized) { Store (0x0C, Local0) If (LEqual (_ADR, 0x00100000)) { Store (0x08, Local0) } ShiftRight (CPB0, Local0, Local1) And (Local1, 0x0F, Local0) Return (Local0) } } Device (PB2P) { Name (_ADR, 0x00120000) Method (_PRW, 0, NotSerialized) { Return (GPRW (0x00, 0x04)) } Method (_PRT, 0, NotSerialized) { If (PICM) { Return (AR01) } Return (PR01) } } Device (MC97) { Name (_ADR, 0x000D0001) Method (_PRW, 0, NotSerialized) { Return (GPRW (0x07, 0x04)) } } Device (PCE0) { Name (_ADR, 0x00020000) Method (_PRW, 0, NotSerialized) { Return (GPRW (0x11, 0x04)) } Method (_PRT, 0, NotSerialized) { If (PICM) { Return (AR02) } Return (PR02) } } Device (PCE1) { Name (_ADR, 0x00030000) Method (_PRW, 0, NotSerialized) { Return (GPRW (0x11, 0x04)) } Method (_PRT, 0, NotSerialized) { If (PICM) { Return (AR03) } Return (PR03) } } Device (PCE2) { Name (_ADR, 0x00040000) Method (_PRW, 0, NotSerialized) { Return (GPRW (0x11, 0x04)) } Method (_PRT, 0, NotSerialized) { If (PICM) { Return (AR04) } Return (PR04) } } Device (PCE3) { Name (_ADR, 0x00170000) Method (_PRW, 0, NotSerialized) { Return (GPRW (0x11, 0x04)) } Method (_PRT, 0, NotSerialized) { If (PICM) { Return (AR05) } Return (PR05) } } Device (PCE4) { Name (_ADR, 0x00160000) Method (_PRW, 0, NotSerialized) { Return (GPRW (0x11, 0x04)) } Method (_PRT, 0, NotSerialized) { If (PICM) { Return (AR06) } Return (PR06) } } Device (PCE5) { Name (_ADR, 0x00150000) Method (_PRW, 0, NotSerialized) { Return (GPRW (0x11, 0x04)) } Method (_PRT, 0, NotSerialized) { If (PICM) { Return (AR07) } Return (PR07) } } } Scope (\_GPE) { Method (_L10, 0, NotSerialized) { \_SB.PCI0.SBRG.SIOH () Notify (\_SB.PWRB, 0x02) } Method (_L03, 0, NotSerialized) { \_SB.PCI0.SBRG.SIOH () Notify (\_SB.PWRB, 0x02) } Method (_L09, 0, NotSerialized) { Notify (\_SB.PCI0.NSMB, 0x02) Notify (\_SB.PWRB, 0x02) } Method (_L0D, 0, NotSerialized) { Notify (\_SB.PCI0.USB0, 0x02) Notify (\_SB.PWRB, 0x02) } Method (_L05, 0, NotSerialized) { Notify (\_SB.PCI0.USB2, 0x02) Notify (\_SB.PWRB, 0x02) } Method (_L00, 0, NotSerialized) { Notify (\_SB.PCI0.PB2P, 0x02) Notify (\_SB.PWRB, 0x02) } Method (_L07, 0, NotSerialized) { Notify (\_SB.PCI0.MC97, 0x02) Notify (\_SB.PWRB, 0x02) } Method (_L11, 0, NotSerialized) { Notify (\_SB.PCI0.PCE0, 0x02) Notify (\_SB.PCI0.PCE1, 0x02) Notify (\_SB.PCI0.PCE2, 0x02) Notify (\_SB.PCI0.PCE3, 0x02) Notify (\_SB.PCI0.PCE4, 0x02) Notify (\_SB.PCI0.PCE5, 0x02) Notify (\_SB.PWRB, 0x02) } } Device (PWRB) { Name (_HID, EisaId ("PNP0C0C")) Name (_UID, 0xAA) Name (_STA, 0x0B) Method (_PRW, 0, NotSerialized) { Return (GPRW (0x03, 0x04)) } } } OperationRegion (\_SB.PCI0.SBRG.PIMC, PCI_Config, 0x7C, 0x0C) Field (\_SB.PCI0.SBRG.PIMC, ByteAcc, NoLock, Preserve) { PIRA, 4, PIRB, 4, PIRC, 4, PIRD, 4, , 4, PIRF, 4, PIRG, 4, Offset (0x05), PIRM, 4, PIU2, 4, Offset (0x07), SIID, 4, PIID, 4, PIU0, 4, Offset (0x09), PILN, 4, Offset (0x0A), PAUI, 4, PIMO, 4, PR0E, 4, PR0F, 4 } Scope (\_SB) { Name (BUFA, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {15} }) CreateWordField (BUFA, 0x01, ICRS) Method (LSTA, 1, NotSerialized) { If (Arg0) { Return (0x0B) } Else { Return (0x09) } } Method (LPRS, 2, NotSerialized) { If (PICM) { Return (Arg1) } Else { Return (Arg0) } } Method (LCRS, 1, NotSerialized) { If (PICM) { Name (BUFB, ResourceTemplate () { Interrupt (ResourceConsumer, Level, ActiveLow, Shared) { 0x00000011, } }) CreateByteField (BUFB, 0x05, AIRQ) Store (Arg0, AIRQ) If (LEqual (Arg0, 0x01)) { Store (0x11, AIRQ) } If (LEqual (Arg0, 0x02)) { Store (0x12, AIRQ) } If (LEqual (Arg0, 0x08)) { Store (0x10, AIRQ) } If (LEqual (Arg0, 0x0D)) { Store (0x13, AIRQ) } Return (BUFB) } Else { ShiftLeft (0x01, Arg0, ICRS) Return (BUFA) } } Method (LCRO, 1, NotSerialized) { If (PICM) { Name (BUFB, ResourceTemplate () { Interrupt (ResourceConsumer, Level, ActiveLow, Shared) { 0x00000014, } }) CreateByteField (BUFB, 0x05, AIRQ) Store (Arg0, AIRQ) If (LEqual (Arg0, 0x01)) { Store (0x17, AIRQ) } If (LEqual (Arg0, 0x02)) { Store (0x16, AIRQ) } If (LEqual (Arg0, 0x08)) { Store (0x14, AIRQ) } If (LEqual (Arg0, 0x0D)) { Store (0x15, AIRQ) } Return (BUFB) } Else { ShiftLeft (0x01, Arg0, ICRS) Return (BUFA) } } Method (LSRS, 1, NotSerialized) { If (PICM) { CreateByteField (Arg0, 0x05, SAIR) Store (SAIR, Local0) If (LEqual (Local0, 0x10)) { Store (0x08, Local0) } If (LEqual (Local0, 0x11)) { Store (0x01, Local0) } If (LEqual (Local0, 0x12)) { Store (0x02, Local0) } If (LEqual (Local0, 0x13)) { Store (0x0D, Local0) } Return (Local0) } Else { CreateWordField (Arg0, 0x01, ISRS) FindSetRightBit (ISRS, Local0) Return (Decrement (Local0)) } } Method (LSRO, 1, NotSerialized) { If (PICM) { CreateByteField (Arg0, 0x05, SAIR) Store (SAIR, Local0) If (LEqual (Local0, 0x14)) { Store (0x08, Local0) } If (LEqual (Local0, 0x15)) { Store (0x0D, Local0) } If (LEqual (Local0, 0x16)) { Store (0x02, Local0) } If (LEqual (Local0, 0x17)) { Store (0x01, Local0) } Return (Local0) } Else { CreateWordField (Arg0, 0x01, ISRS) FindSetRightBit (ISRS, Local0) Return (Decrement (Local0)) } } Device (LNKA) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x01) Method (_STA, 0, NotSerialized) { Return (LSTA (PIRA)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (PRSA, RSIR)) } Method (_DIS, 0, NotSerialized) { Store (0x00, PIRA) } Method (_CRS, 0, NotSerialized) { Return (LCRS (PIRA)) } Method (_SRS, 1, NotSerialized) { Store (LSRS (Arg0), PIRA) } } Device (LNKB) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x02) Method (_STA, 0, NotSerialized) { Return (LSTA (PIRB)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (PRSB, RSIR)) } Method (_DIS, 0, NotSerialized) { Store (0x00, PIRB) } Method (_CRS, 0, NotSerialized) { Return (LCRS (PIRB)) } Method (_SRS, 1, NotSerialized) { Store (LSRS (Arg0), PIRB) } } Device (LNKC) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x03) Method (_STA, 0, NotSerialized) { Return (LSTA (PIRC)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (PRSC, RSIR)) } Method (_DIS, 0, NotSerialized) { Store (0x00, PIRC) } Method (_CRS, 0, NotSerialized) { Return (LCRS (PIRC)) } Method (_SRS, 1, NotSerialized) { Store (LSRS (Arg0), PIRC) } } Device (LNKD) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x04) Method (_STA, 0, NotSerialized) { Return (LSTA (PIRD)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (PRSD, RSIR)) } Method (_DIS, 0, NotSerialized) { Store (0x00, PIRD) } Method (_CRS, 0, NotSerialized) { Return (LCRS (PIRD)) } Method (_SRS, 1, NotSerialized) { Store (LSRS (Arg0), PIRD) } } Device (LUB0) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x05) Method (_STA, 0, NotSerialized) { Return (LSTA (PIU0)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (RSB0, RSII)) } Method (_DIS, 0, NotSerialized) { Store (0x00, PIU0) } Method (_CRS, 0, NotSerialized) { Return (LCRO (PIU0)) } Method (_SRS, 1, NotSerialized) { Store (LSRO (Arg0), PIU0) } } Device (LUB2) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x07) Method (_STA, 0, NotSerialized) { Return (LSTA (PIU2)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (RSB2, RSII)) } Method (_DIS, 0, NotSerialized) { Store (0x00, PIU2) } Method (_CRS, 0, NotSerialized) { Return (LCRO (PIU2)) } Method (_SRS, 1, NotSerialized) { Store (LSRO (Arg0), PIU2) } } Device (LMAC) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x08) Method (_STA, 0, NotSerialized) { Return (LSTA (PILN)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (RSAC, RSII)) } Method (_DIS, 0, NotSerialized) { Store (0x00, PILN) } Method (_CRS, 0, NotSerialized) { Return (LCRO (PILN)) } Method (_SRS, 1, NotSerialized) { Store (LSRO (Arg0), PILN) } } Device (LACI) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x09) Method (_STA, 0, NotSerialized) { Return (LSTA (PAUI)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (RSCI, RSII)) } Method (_DIS, 0, NotSerialized) { Store (0x00, PAUI) } Method (_CRS, 0, NotSerialized) { Return (LCRO (PAUI)) } Method (_SRS, 1, NotSerialized) { Store (LSRO (Arg0), PAUI) } } Device (LMC9) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x0A) Method (_STA, 0, NotSerialized) { Return (LSTA (PIMO)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (RSC9, RSII)) } Method (_DIS, 0, NotSerialized) { Store (0x00, PIMO) } Method (_CRS, 0, NotSerialized) { Return (LCRO (PIMO)) } Method (_SRS, 1, NotSerialized) { Store (LSRO (Arg0), PIMO) } } Device (LSMB) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x0B) Method (_STA, 0, NotSerialized) { Return (LSTA (PIRM)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (RSMB, RSII)) } Method (_DIS, 0, NotSerialized) { Store (0x00, PIRM) } Method (_CRS, 0, NotSerialized) { Return (LCRO (PIRM)) } Method (_SRS, 1, NotSerialized) { Store (LSRO (Arg0), PIRM) } } Device (LSA0) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x0C) Method (_STA, 0, NotSerialized) { Return (LSTA (PIID)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (RSA0, RSII)) } Method (_DIS, 0, NotSerialized) { Store (0x00, PIID) Store (0x00, PIRG) } Method (_CRS, 0, NotSerialized) { Return (LCRO (PIID)) } Method (_SRS, 1, NotSerialized) { Store (LSRO (Arg0), Local0) Store (Local0, PIID) Store (Local0, PIRG) } } Device (LSA1) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x0D) Method (_STA, 0, NotSerialized) { Return (LSTA (SIID)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (RSA1, RSII)) } Method (_DIS, 0, NotSerialized) { Store (0x00, SIID) Store (0x00, PIRF) } Method (_CRS, 0, NotSerialized) { Return (LCRO (SIID)) } Method (_SRS, 1, NotSerialized) { Store (LSRO (Arg0), Local0) Store (Local0, SIID) Store (Local0, PIRF) } } Device (LATA) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x0E) Method (_STA, 0, NotSerialized) { Return (LSTA (PR0E)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (RSTA, RSII)) } Method (_DIS, 0, NotSerialized) { Store (0x00, PR0E) Store (0x00, PR0F) } Method (_CRS, 0, NotSerialized) { If (OSFL ()) { Return (0x00) } Else { Return (LCRO (PR0E)) } } Method (_SRS, 1, NotSerialized) { Store (LSRO (Arg0), PR0E) Store (LSRO (Arg0), PR0F) } } } Scope (\_SB) { Name (XCPD, 0x00) Name (XNPT, 0x01) 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, 0x01) 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, 0x01) 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 (\_SB.RDPE (Local0), Local1) If (LEqual (Local1, 0xFFFFFFFF)) { Return (0x00) } Else { If (LAnd (Local1, 0x00010000)) { \_SB.WDPE (Local0, And (Local1, 0x00010000)) Return (0x01) } Return (0x00) } } } Scope (\_SB.PCI0.SBRG.SIOR) { Device (IT87) { Name (_HID, EisaId ("PNP0C02")) Name (_UID, 0x00) Method (HWV0, 0, NotSerialized) { Return (Multiply (VIV0, 0x10)) } Method (HWV1, 0, NotSerialized) { Return (Multiply (VIV1, 0x10)) } Method (HWV2, 0, NotSerialized) { Return (Multiply (VIV2, 0x10)) } Method (HWV3, 0, NotSerialized) { Return (Multiply (VIV3, 0x10)) } Method (HWV4, 0, NotSerialized) { Return (Multiply (VIV4, 0x10)) } Method (HWV5, 0, NotSerialized) { Return (Multiply (VIV5, 0x10)) } Method (HWV6, 0, NotSerialized) { Return (Multiply (VIV6, 0x10)) } Method (HWV7, 0, NotSerialized) { Return (Multiply (VIV7, 0x10)) } Method (HWT1, 0, NotSerialized) { Store (TPI1, Local0) If (LGreater (Local0, 0x80)) { Subtract (0x0100, Local0, Local0) } Return (Multiply (Local0, 0x0A)) } Method (HWT2, 0, NotSerialized) { Store (TPI2, Local0) If (LGreater (Local0, 0x80)) { Subtract (0x0100, Local0, Local0) } Return (Multiply (Local0, 0x0A)) } Method (HWT3, 0, NotSerialized) { Store (TPI3, Local0) If (LGreater (Local0, 0x80)) { Subtract (0x0100, Local0, Local0) } Return (Multiply (Local0, 0x0A)) } Method (HWF1, 0, NotSerialized) { And (ETDE, 0x01, Local0) While (0x01) { ShiftLeft (0x01, FTD1, Local1) If (LEqual (Local0, 0x01)) { Add (Multiply (EFN1, 0x0100), FTC1, Local2) } Else { Store (FTC1, Local2) } If (LEqual (Local0, 0x01)) { If (LNot (LLess (Local2, 0xF000))) { If (LNot (LEqual (Local1, 0x80))) { Add (FTD1, 0x01, FTD1) Sleep (0x64) } Else { Return (0x00) } } Else { If (LNot (LGreater (Local2, 0x1000))) { If (LNot (LEqual (Local1, 0x01))) { Subtract (FTD1, 0x01, FTD1) Sleep (0x64) } Else { Return (0xFFFF) } } Else { Divide (0x00149970, Multiply (Local1, Local2), , Local1) Return (Local1) } } } Else { If (LNot (LLess (Local2, 0xF0))) { If (LNot (LEqual (Local1, 0x80))) { Add (FTD1, 0x01, FTD1) Sleep (0x64) } Else { Return (0x00) } } Else { If (LNot (LGreater (Local2, 0x32))) { If (LNot (LEqual (Local1, 0x01))) { Subtract (FTD1, 0x01, FTD1) Sleep (0x64) } Else { Return (0xFFFF) } } Else { Divide (0x00149970, Multiply (Local1, Local2), , Local1) Return (Local1) } } } } } Method (HWF2, 0, NotSerialized) { And (ETDE, 0x02, Local0) While (0x01) { ShiftLeft (0x01, FTD2, Local1) If (LEqual (Local0, 0x02)) { Add (Multiply (EFN2, 0x0100), FTC2, Local2) } Else { Store (FTC2, Local2) } If (LEqual (Local0, 0x02)) { If (LNot (LLess (Local2, 0xF000))) { If (LNot (LEqual (Local1, 0x80))) { Add (FTD2, 0x01, FTD2) Sleep (0x64) } Else { Return (0x00) } } Else { If (LNot (LGreater (Local2, 0x1000))) { If (LNot (LEqual (Local1, 0x01))) { Subtract (FTD2, 0x01, FTD2) Sleep (0x64) } Else { Return (0xFFFF) } } Else { Divide (0x00149970, Multiply (Local1, Local2), , Local1) Return (Local1) } } } Else { If (LNot (LLess (Local2, 0xF0))) { If (LNot (LEqual (Local1, 0x80))) { Add (FTD2, 0x01, FTD2) Sleep (0x64) } Else { Return (0x00) } } Else { If (LNot (LGreater (Local2, 0x32))) { If (LNot (LEqual (Local1, 0x01))) { Subtract (FTD2, 0x01, FTD2) Sleep (0x64) } Else { Return (0xFFFF) } } Else { Divide (0x00149970, Multiply (Local1, Local2), , Local1) Return (Local1) } } } } } Method (HWF3, 0, NotSerialized) { And (ETDE, 0x04, Local0) While (0x01) { If (LEqual (FTD3, 0x01)) { Store (0x08, Local1) } Else { Store (0x02, Local1) } If (LEqual (Local0, 0x04)) { Add (Multiply (EFN3, 0x0100), FTC3, Local2) } Else { Store (FTC3, Local2) } If (LEqual (Local0, 0x04)) { If (LNot (LLess (Local2, 0xF000))) { If (LNot (LEqual (Local1, 0x08))) { Add (FTD3, 0x01, FTD3) Sleep (0x64) } Else { Return (0x00) } } Else { If (LNot (LGreater (Local2, 0x1000))) { If (LNot (LEqual (Local1, 0x00))) { Subtract (FTD3, 0x01, FTD3) Sleep (0x64) } Else { Return (0xFFFF) } } Else { Divide (0x00149970, Multiply (Local1, Local2), , Local1) Return (Local1) } } } Else { If (LNot (LLess (Local2, 0xF0))) { If (LNot (LEqual (Local1, 0x08))) { Add (FTD3, 0x01, FTD3) Sleep (0x64) } Else { Return (0x00) } } Else { If (LNot (LGreater (Local2, 0x10))) { If (LNot (LEqual (Local1, 0x00))) { Subtract (FTD3, 0x01, FTD3) Sleep (0x64) } Else { Return (0xFFFF) } } Else { Divide (0x00149970, Multiply (Local1, Local2), , Local1) Return (Local1) } } } } } OperationRegion (ECRE, SystemIO, IOEB, 0x20) Field (ECRE, ByteAcc, NoLock, Preserve) { Offset (0x05), HIDX, 8, HDAT, 8 } IndexField (HIDX, HDAT, ByteAcc, NoLock, Preserve) { Offset (0x0B), FTD1, 3, FTD2, 3, FTD3, 1, Offset (0x0C), ETDE, 8, FTC1, 8, FTC2, 8, FTC3, 8, Offset (0x18), EFN1, 8, EFN2, 8, EFN3, 8, Offset (0x20), VIV0, 8, VIV1, 8, VIV2, 8, VIV3, 8, VIV4, 8, VIV5, 8, VIV6, 8, VIV7, 8, Offset (0x29), TPI1, 8, TPI2, 8, TPI3, 8 } } } Scope (\) { Field (\RAMW, ByteAcc, NoLock, Preserve) { Offset (0x20), CPUQ, 8, CPVL, 16, CPVH, 16, CPVC, 1 } } Scope (\_SB.PCI0.SBRG.ASOC) { Name (CORV, Package (0x05) { 0x06020000, "Vcore Voltage", 0x0320, 0x0708, 0x01 }) Name (V3VV, Package (0x05) { 0x06020001, " +3.3 Voltage", 0x0B9A, 0x0E2E, 0x01 }) Name (V5VV, Package (0x05) { 0x06020002, " +5 Voltage", 0x1194, 0x157C, 0x01 }) Name (VV12, Package (0x05) { 0x06020003, " +12 Voltage", 0x27D8, 0x35E8, 0x01 }) Name (VPAR, Package (0x04) { Package (0x03) { 0x00, 0x01, 0x00 }, Package (0x03) { 0x00, 0x01, 0x00 }, Package (0x03) { 0x22, 0x32, 0x00 }, Package (0x03) { 0x0F, 0x05, 0x00 } }) Name (VBUF, Package (0x05) { 0x04, CORV, V3VV, V5VV, VV12 }) Method (VGET, 1, NotSerialized) { If (LEqual (Arg0, 0x00)) { Return (^^SIOR.IT87.HWV0 ()) } If (LEqual (Arg0, 0x01)) { Return (^^SIOR.IT87.HWV2 ()) } If (LEqual (Arg0, 0x02)) { Return (^^SIOR.IT87.HWV3 ()) } If (LEqual (Arg0, 0x03)) { Return (^^SIOR.IT87.HWV4 ()) } } Name (CPUT, Package (0x05) { 0x06030000, "CPU Temperature", 0x0258, 0x03B6, 0x00010001 }) Name (MBTP, Package (0x05) { 0x06030001, "MB Temperature", 0x01C2, 0x03B6, 0x00010001 }) Name (TBUF, Package (0x03) { 0x02, CPUT, MBTP }) Method (TGET, 1, NotSerialized) { If (LEqual (Arg0, 0x00)) { Return (^^SIOR.IT87.HWT1 ()) } If (LEqual (Arg0, 0x01)) { Return (^^SIOR.IT87.HWT2 ()) } } Name (CPUF, Package (0x05) { 0x06040000, "CPU FAN Speed", 0x0320, 0x1C20, 0x00010001 }) Name (CHA1, Package (0x05) { 0x06040001, "CHASSIS FAN Speed", 0x0320, 0x1C20, 0x00010001 }) Name (PWRF, Package (0x05) { 0x06040002, "POWER FAN Speed", 0x0320, 0x1C20, 0x00010001 }) Name (FBUF, Package (0x04) { 0x03, CPUF, CHA1, PWRF }) Method (FGET, 1, NotSerialized) { If (LEqual (Arg0, 0x00)) { Return (^^SIOR.IT87.HWF1 ()) } If (LEqual (Arg0, 0x01)) { Return (^^SIOR.IT87.HWF2 ()) } If (LEqual (Arg0, 0x02)) { Return (^^SIOR.IT87.HWF3 ()) } } Name (QBUF, Package (0x01) { 0x00 }) Method (VSIF, 0, NotSerialized) { Return (VBUF) } Method (RVLT, 1, NotSerialized) { And (Arg0, 0xFFFF, Local0) Store (VGET (Local0), Local1) Store (DerefOf (Index (DerefOf (Index (VPAR, Local0)), 0x00)), Local2) Store (DerefOf (Index (DerefOf (Index (VPAR, Local0)), 0x01)), Local3) Store (DerefOf (Index (DerefOf (Index (VPAR, Local0)), 0x02)), Local4) Multiply (Local1, Add (Local2, Local3), Local5) Divide (Local5, Local3, , Local5) Add (Local5, Local4, Local5) Return (Local5) } Method (SVLT, 1, NotSerialized) { And (DerefOf (Index (Arg0, 0x00)), 0xFFFF, Local0) Store (DerefOf (Index (VBUF, 0x00)), Local1) If (LNot (LLess (Local0, Local1))) { Return (0x00) } Increment (Local0) Store (DerefOf (Index (Arg0, 0x01)), Index (DerefOf (Index (VBUF, Local0)), 0x01)) Store (DerefOf (Index (Arg0, 0x02)), Index (DerefOf (Index (VBUF, Local0)), 0x02)) Store (DerefOf (Index (Arg0, 0x03)), Index (DerefOf (Index (VBUF, Local0)), 0x03)) Store (DerefOf (Index (Arg0, 0x04)), Index (DerefOf (Index (VBUF, Local0)), 0x04)) Return (0x01) } Method (TSIF, 0, NotSerialized) { Return (TBUF) } Method (RTMP, 1, NotSerialized) { And (Arg0, 0xFFFF, Local0) Store (TGET (Local0), Local1) Return (Local1) } Method (STMP, 1, NotSerialized) { Store (And (DerefOf (Index (Arg0, 0x00)), 0xFFFF), Local0) Store (DerefOf (Index (TBUF, 0x00)), Local1) If (LNot (LLess (Local0, Local1))) { Return (0x00) } Increment (Local0) Store (DerefOf (Index (Arg0, 0x01)), Index (DerefOf (Index (TBUF, Local0)), 0x01)) Store (DerefOf (Index (Arg0, 0x02)), Index (DerefOf (Index (TBUF, Local0)), 0x02)) Store (DerefOf (Index (Arg0, 0x03)), Index (DerefOf (Index (TBUF, Local0)), 0x03)) Store (DerefOf (Index (Arg0, 0x04)), Index (DerefOf (Index (TBUF, Local0)), 0x04)) Return (0x01) } Method (FSIF, 0, NotSerialized) { Return (FBUF) } Method (RFAN, 1, NotSerialized) { And (Arg0, 0xFFFF, Local0) Store (FGET (Local0), Local1) Return (Local1) } Method (SFAN, 1, NotSerialized) { And (DerefOf (Index (Arg0, 0x00)), 0xFFFF, Local0) Store (DerefOf (Index (FBUF, 0x00)), Local1) If (LNot (LLess (Local0, Local1))) { Return (0x00) } Increment (Local0) Store (DerefOf (Index (Arg0, 0x01)), Index (DerefOf (Index (FBUF, Local0)), 0x01)) Store (DerefOf (Index (Arg0, 0x02)), Index (DerefOf (Index (FBUF, Local0)), 0x02)) Store (DerefOf (Index (Arg0, 0x03)), Index (DerefOf (Index (FBUF, Local0)), 0x03)) Store (DerefOf (Index (Arg0, 0x04)), Index (DerefOf (Index (FBUF, Local0)), 0x04)) Return (0x01) } Method (QFIF, 0, NotSerialized) { If (LEqual (CPUQ, 0x00)) { And (DerefOf (Index (QCFN, 0x05)), 0xFFFDFFFF, Local0) Store (Local0, Index (QCFN, 0x05)) } Else { Or (DerefOf (Index (QCFN, 0x05)), 0x00020000, Local0) Store (Local0, Index (QCFN, 0x05)) } Return (QBUF) } Method (GCQV, 1, NotSerialized) { If (LEqual (Arg0, 0x00)) { Return (CPVL) } If (LEqual (Arg0, 0x01)) { Return (CPVH) } If (LEqual (Arg0, 0x02)) { Return (CPVC) } Return (0x00) } Method (QFST, 1, NotSerialized) { If (LEqual (Arg0, DerefOf (Index (QCFN, 0x00)))) { Return (CQST) } Return (0x00) } } 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) }) CreateDWordField (CRS, 0x5C, MIN5) CreateDWordField (CRS, 0x60, MAX5) CreateDWordField (CRS, 0x68, LEN5) CreateDWordField (CRS, 0x76, MIN6) CreateDWordField (CRS, 0x7A, MAX6) CreateDWordField (CRS, 0x82, LEN6) 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) Return (CRS) } } } Name (WOTB, 0x00) Name (WSSB, 0x00) Name (WAXB, 0x00) Method (_PTS, 1, NotSerialized) { Store (Arg0, DBG8) PTS (Arg0) Store (0x00, Index (WAKP, 0x00)) Store (0x00, Index (WAKP, 0x01)) 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) } Method (_WAK, 1, NotSerialized) { ShiftLeft (Arg0, 0x04, DBG8) WAK (Arg0) If (ASSB) { Store (WSSB, ASSB) Store (WOTB, AOTB) Store (WAXB, AAXB) } If (DerefOf (Index (WAKP, 0x00))) { Store (0x00, Index (WAKP, 0x01)) } Else { Store (Arg0, Index (WAKP, 0x01)) } Return (WAKP) } Name (\_S0, Package (0x04) { 0x00, 0x00, 0x00, 0x00 }) If (SS1) { Name (\_S1, Package (0x04) { 0x01, 0x00, 0x00, 0x00 }) } If (SS3) { Name (\_S3, Package (0x04) { 0x05, 0x00, 0x00, 0x00 }) } If (SS4) { Name (\_S4, Package (0x04) { 0x06, 0x00, 0x00, 0x00 }) } Name (\_S5, Package (0x04) { 0x07, 0x00, 0x00, 0x00 }) Method (PTS, 1, NotSerialized) { If (Arg0) { \_SB.PCI0.SBRG.SIOS (Arg0) \_SB.PCI0.NB2N.NPTS (Arg0) \_SB.PCI0.SBRG.SPTS (Arg0) } } Method (WAK, 1, NotSerialized) { \_SB.PCI0.SBRG.SIOW (Arg0) \_SB.PCI0.NB2N.NWAK (Arg0) \_SB.PCI0.SBRG.SWAK (Arg0) } } --------------060902000402000309040604-- From owner-freebsd-stable@FreeBSD.ORG Sat Jul 29 01:38:22 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63BE616A584 for ; Sat, 29 Jul 2006 01:38:22 +0000 (UTC) (envelope-from nikolas.britton@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 80C2943D45 for ; Sat, 29 Jul 2006 01:38:21 +0000 (GMT) (envelope-from nikolas.britton@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so3502uge for ; Fri, 28 Jul 2006 18:38:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qZnaqQJJ7Oga562LKKgeiVyYLGPTfaY91tq4cHDZQktegp8oEOEr7cnZjUVrMaS1FzvNBYAGUTZ074u1bfq6pbCCs3CJA/iGi7wlW/QIQx7HzPXPQaidqA74LmyVVnf/6+VL7l8FFkzMkxTOjk5tbIX7EaPieb9m21ziEdPWzX4= Received: by 10.78.193.5 with SMTP id q5mr2160huf; Fri, 28 Jul 2006 18:38:20 -0700 (PDT) Received: by 10.78.143.11 with HTTP; Fri, 28 Jul 2006 18:38:20 -0700 (PDT) Message-ID: Date: Fri, 28 Jul 2006 20:38:20 -0500 From: "Nikolas Britton" To: "David Duchscher" In-Reply-To: <016E6A0B-E3E4-4444-BD27-24E75C784788@tamu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44C63DFD.5040401@rogers.com> <20060726160952.GW17014@poupinou.org> <016E6A0B-E3E4-4444-BD27-24E75C784788@tamu.edu> Cc: Mike Jakubik , stable@freebsd.org, Bruno Ducrot Subject: Re: Monitoring temperature with acpi (sysctls) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2006 01:38:22 -0000 On 7/26/06, David Duchscher wrote: > > On Jul 26, 2006, at 11:09 AM, Bruno Ducrot wrote: > > > On Tue, Jul 25, 2006 at 11:51:25AM -0400, Mike Jakubik wrote: > >> I need to be able to get the cpu and fan information from my > >> motherboard, however none of the monitoring utilities in the ports > >> seems > >> to support my motherboard (Supermicro PDSMi, Intel E7230 (Mukilteo) > >> Chipset). On my older VIA based motherboards and some Nvidia, i > >> can get > >> this information using ACPI and the hw.acpi.thermal sysctl. This > >> however > >> is not available on this motherboard. Would this be a shortcoming > >> of the > >> motherboards ACPI implementation, or a lack of support by freebsd? > > > > Does this one support IPMI? > > Yes, the Supermicro PDSMi supports the IPMI 2.0 module and I can > confirm that it works with the IPMI ported driver from current on > 6.1. The module is optional so you will have to purchase one for > the system, around 0. You will also need the latest BIOS loaded on > the motherboard for it to work. > > http://www.supermicro.com/products/accessories/addon/AOC-IPMI20-E.cfm > What about their other IPMI 2.0 cards: http://www.supermicro.com/products/accessories/addon/SIM.cfm Specifically the AOC-SIMLP? and what ported IPMI driver are we talking about? Also does anyone have an IPMI primer, I've never used it before? -- BSD Podcasts @: http://bsdtalk.blogspot.com/ http://freebsdforall.blogspot.com/ From owner-freebsd-stable@FreeBSD.ORG Sat Jul 29 07:04:08 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 01DE916A4DD for ; Sat, 29 Jul 2006 07:04:08 +0000 (UTC) (envelope-from igorr@speechpro.com) Received: from speechpro.ru (speech-tech-2.ip.PeterStar.net [81.3.190.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8334343D45 for ; Sat, 29 Jul 2006 07:04:07 +0000 (GMT) (envelope-from igorr@speechpro.com) Received: from [192.168.2.26] (helo=sysadm.stc) by s1.stc with esmtp (Exim 4.53 (FreeBSD)) id 1G6irl-000M2R-5M for freebsd-stable@freebsd.org; Sat, 29 Jul 2006 11:04:05 +0400 Received: from localhost.stc ([127.0.0.1] helo=sysadm.stc) by sysadm.stc with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1G6irq-00029E-GS for freebsd-stable@freebsd.org; Sat, 29 Jul 2006 11:04:10 +0400 Received: (from igorr@localhost) by sysadm.stc (8.13.6/8.13.6/Submit) id k6T74A2o008259 for freebsd-stable@freebsd.org; Sat, 29 Jul 2006 11:04:10 +0400 (MSD) (envelope-from igorr) Date: Sat, 29 Jul 2006 11:04:10 +0400 From: Igor Robul To: freebsd-stable@freebsd.org Message-ID: <20060729070410.GD8063@sysadm.stc> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 X-Archived: Yes Subject: Re: Gateway X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2006 07:04:08 -0000 On Fri, Jul 28, 2006 at 07:00:18PM -0400, SigmaX asdf wrote: > gateway_enable="YES" > firewall_enable="YES" > firewall_type="OPEN" > natd_enabl="YES" ^^^^^^^^^^^^^^^^^^^ Should be natd_enable="YES" From owner-freebsd-stable@FreeBSD.ORG Sat Jul 29 10:03:53 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8910D16A4DD for ; Sat, 29 Jul 2006 10:03:53 +0000 (UTC) (envelope-from thn@saeab.se) Received: from saeab.se (ture.saeab.se [213.80.3.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id B1FF943D49 for ; Sat, 29 Jul 2006 10:03:51 +0000 (GMT) (envelope-from thn@saeab.se) Received: from scatcat.thn.saeab.se (vpn-thn.int.saeab.se [10.0.4.43]) by saeab.se (8.13.6/8.13.6) with ESMTP id k6TA3laY071467; Sat, 29 Jul 2006 12:03:47 +0200 (CEST) (envelope-from thn@saeab.se) Received: from [10.1.0.1] (home [10.1.0.1]) by scatcat.thn.saeab.se (8.13.6/8.13.6) with ESMTP id k6TA3k7l063819; Sat, 29 Jul 2006 12:03:47 +0200 (CEST) (envelope-from thn@saeab.se) Message-ID: <44CB32B6.7050307@saeab.se> Date: Sat, 29 Jul 2006 12:04:38 +0200 From: =?ISO-8859-1?Q?Thomas_Nystr=F6m?= Organization: Svensk Aktuell Elektronik AB User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00, UNPARSEABLE_RELAY autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on ture.saeab.se X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (saeab.se [10.0.1.133]); Sat, 29 Jul 2006 12:03:50 +0200 (CEST) Subject: Problem with builtin dhclient in 6.1R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2006 10:03:53 -0000 FreeBSD 6.x has changed the dhclient that is bundled with the system. I have some problems with the new client. When a lease is renewed my connection to the network is locked up. I believe that the lockup occurs because of the way the new client does lease renewal. My ISP only allows ONE computer to connect to each modem (via the cable-TV-network). The dhclient seems to trigger this when it sends the DHCPREQUEST to renew the lease with a broadcast. The only way to get it up and running is to reset the modem (which the ISP states should be done if you change the computer or network card on the connection). I have tried (and compared the behaviour) of the isc-dhclient (from ports) and it sends the DHCPREQUEST directly to the DHCP-server without a broadcast. The DHCP-server is not on the same network. With the isc-dclient everthing works. I have also compared the code of the two dhclients and found that the isc-variant have a fallback mechanism and that mechanism is ALWAYS used when a DHCPREQUEST should be sent directly to a known server. I also find the following comment in isc's osdep.h: /* Porting:: If you add support for sending packets directly out an interface, and your support does not do ARP or routing, you must use a fallback mechanism to deal with packets that need to be sent to routers. Currently, all low-level packet interfaces use BSD sockets as a fallback. */ It seems that this has been missed somewhere on the way.... Does anyone else have had the same kind of problem? Any comments? /thn -- --------------------------------------------------------------- Svensk Aktuell Elektronik AB Thomas Nyström Box 10 Phone: +46 8 35 92 85 S-191 21 Sollentuna Fax: +46 8 35 92 86 Sweden Email: thn@saeab.se --------------------------------------------------------------- From owner-freebsd-stable@FreeBSD.ORG Sat Jul 29 13:48:52 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8707A16A4DA for ; Sat, 29 Jul 2006 13:48:52 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0127D43D46 for ; Sat, 29 Jul 2006 13:48:51 +0000 (GMT) (envelope-from uspoerlein@gmail.com) Received: by nz-out-0102.google.com with SMTP id 13so26154nzn for ; Sat, 29 Jul 2006 06:48:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to; b=gIjljkcQ886ROlI+V0wAVXVu2xh/IOaFM5N4mOH41t6634gBRXvgozf4e8NK/uuRs5WuHBoFtRaNApKHId4mFf/ZY/q+3GyNART2cqYjFmDtoLGDEw0sK44UWq+g1pMHVwnPNiRviuyXK1qBnF+DKEZFq1y54jCekXkx5f3YFX8= Received: by 10.65.148.11 with SMTP id a11mr669866qbo; Sat, 29 Jul 2006 06:48:51 -0700 (PDT) Received: from roadrunner.q.local ( [217.185.119.144]) by mx.gmail.com with ESMTP id e16sm1754027qbe.2006.07.29.06.48.49; Sat, 29 Jul 2006 06:48:51 -0700 (PDT) Received: from roadrunner.q.local (localhost [127.0.0.1]) by roadrunner.q.local (8.13.6/8.13.6) with ESMTP id k6TDmOqg012983; Sat, 29 Jul 2006 15:48:24 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Received: (from q@localhost) by roadrunner.q.local (8.13.6/8.13.6/Submit) id k6TD4RFO011667; Sat, 29 Jul 2006 15:04:27 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Date: Sat, 29 Jul 2006 15:04:26 +0200 From: Ulrich Spoerlein To: "Andresen, Jason" Message-ID: <20060729130426.GA1066@roadrunner.informatik.uni-wuerzburg.de> Mail-Followup-To: "Andresen, Jason" , freebsd-stable@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-stable@freebsd.org Subject: Re: wine: ld-elf.so.1 not found X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2006 13:48:52 -0000 Andresen, Jason wrote: > I'm having a very strange problem with Wine. It apparently refuses to > see ld when starting: > > (72 ~): wine > ELF interpreter /libexec/ld-elf.so.1 not found > [...] > > I'm really stumped as to what the problem is. Search the archives, I had that problem too. I traced it back to kern.maxdsiz > 1GB. Please check your local data size limit. Ulrich Spoerlein PS: This is not a bug in Wine itself, but in our ELF handling. Running ldd(1) on the wine binary will result in an ELF interpreter error too. -- A: Yes. >Q: Are you sure? > >A: Because it reverses the logical flow of conversation. > >>Q: Why is top posting frowned upon? From owner-freebsd-stable@FreeBSD.ORG Sat Jul 29 15:49:35 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5FBF516A4DD for ; Sat, 29 Jul 2006 15:49:35 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id C257343D46 for ; Sat, 29 Jul 2006 15:49:34 +0000 (GMT) (envelope-from nikolas.britton@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so161605uge for ; Sat, 29 Jul 2006 08:49:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=bO9qrYukKefziv8JXWnsMD//u3FtDTjXXNM0iF+tsqYEyKt3GJVnAzy4UJpVMVCy854KRxwOV3X10zFXa0rDhaT3J0HEAs+XF5yycbPITC3nezwpAmVMNiZq8C0+MgO0CkiSetMRsJKvtLxfuhk7BUft8G+0zOPI+X/pB9LVjOQ= Received: by 10.78.138.14 with SMTP id l14mr135500hud; Sat, 29 Jul 2006 08:49:33 -0700 (PDT) Received: by 10.78.143.11 with HTTP; Sat, 29 Jul 2006 08:49:33 -0700 (PDT) Message-ID: Date: Sat, 29 Jul 2006 10:49:33 -0500 From: "Nikolas Britton" To: "FreeBSD Stable List" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: GIANT in arcmsr(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2006 15:49:35 -0000 Anyone know why the giant is in arcmsr(4) or how to kill him? -- BSD Podcasts @: http://bsdtalk.blogspot.com/ http://freebsdforall.blogspot.com/ From owner-freebsd-stable@FreeBSD.ORG Sat Jul 29 16:38:45 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA85416A4E0 for ; Sat, 29 Jul 2006 16:38:45 +0000 (UTC) (envelope-from V.Haisman@sh.cvut.cz) Received: from service.sh.cvut.cz (service.sh.cvut.cz [147.32.127.214]) by mx1.FreeBSD.org (Postfix) with ESMTP id 29AA443D45 for ; Sat, 29 Jul 2006 16:38:42 +0000 (GMT) (envelope-from V.Haisman@sh.cvut.cz) Received: from localhost (localhost [127.0.0.1]) by service.sh.cvut.cz (Postfix) with ESMTP id AAA1F1A33CC; Sat, 29 Jul 2006 18:38:41 +0200 (CEST) Received: from service.sh.cvut.cz ([127.0.0.1]) by localhost (service [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08310-05; Sat, 29 Jul 2006 18:38:38 +0200 (CEST) Received: from logout.sh.cvut.cz (logout.sh.cvut.cz [147.32.127.203]) by service.sh.cvut.cz (Postfix) with ESMTP id 944741A33C9; Sat, 29 Jul 2006 18:38:38 +0200 (CEST) Received: from [192.168.1.2] (localhost [127.0.0.1]) by logout.sh.cvut.cz (Postfix) with ESMTP id 6D40761C24; Sat, 29 Jul 2006 18:38:19 +0200 (CEST) Message-ID: <44CB8F04.30800@sh.cvut.cz> Date: Sat, 29 Jul 2006 18:38:28 +0200 From: =?UTF-8?B?VsOhY2xhdiBIYWlzbWFu?= User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 0.94.0.0 OpenPGP: id=733031B4 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAMFBMVEUnMzWJm5S+0864pn5r blp/hnW2up7X7uqftbNRVUrW1LGBdGfHwJqPi3ScoYtBQzhDxGEwAAAAB3RJTUUH1QoQDDgyQtx8 HQAAAkNJREFUeJzFU0toU0EUPYu66CpGdCUUmoUJkpUDQUoNBVEUrBJsq1Ki2EIKIUZ8mydBhYi0 wVUXJVCLCrFN4DIEQdxIqdBIFsMkWD9YJClCRGKjJaviynjfe8RPogtXPcObuXPOPXd+PHj+Aeyo QNmobGLXVeANGM+GsP0B2yqHHNVoCD2LwLglVGZx7yXSlADR0uZu9C4Bpy3hUxPvH/cuUw6UoPCL h64I8KAJuMpwRU8uUMJy0OIpHVeXmulZoCc/t0LlTbJLEY1EudPRcnVjgAP5Osdl4K5HVP4+2bAI okaUA0Iq6Q59+Zy2eMWN6EpFTsa3+uD1+JKj4TPHuYTSMaLScLAaqk94YJqG4ds30hojOVgYoNJc NTztNU2TBYbhu9Aafnq08ORja37da1NwBrN/b7NVEc+b8yecuYkp08vNvLYneVZRaSH1vS0UnfHm OUPzWaZufHPmCWSdWrfeGVQQKmcsO4If8pAdXJ/xF4QQAeOVY1AQQcfirwkLUWeWVTgi6vaGt2xe BGzBEIMQorru8RxgPqY1V6uxYnwVBRZEI1ytCm3dE8mC2DgcbzCJGHdBEVDKuWDSwsrSGoqzJmNt 2jJpNueIH0qS8/0JrDKnVBdvOzIsdVr4zaX9dn9xcLLKdCtQGfutVacLE9Ja+yfbDvO4aMWrklfK /JYv15C8Kw9S10kup5Bys0N1bLdcn4HvTl/Xlh6Fpllwj5/XpH9BUXn/ym0Dvv7Rt2MywojpYiSi i7Hsscaa19zZ//y/hR+BT/ns80nmJAAAAABJRU5ErkJggg== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig80144CFA608FCFD1F6BAC6CD" X-Virus-Scanned: by amavisd-new at sh.cvut.cz X-Spam-Status: No, hits=-5.9 tagged_above=-255.0 required=5.0 tests=ALL_TRUSTED, BAYES_00 X-Spam-Level: Subject: en_GB.UTF-8 locale X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2006 16:38:45 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig80144CFA608FCFD1F6BAC6CD Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I have problems using this locale. As far as I know, it should be valid, but programmes like Perl of Firefox complain that it doesn't exist. I have FreeBSD 6.1 and I set it through .login_conf together with charset parameter. The Perl problem looks like this: perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LC_ALL =3D (unset), LANG =3D "en_GB.UTF-8" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). What am I supposed to do to make it work? -- Vaclav Haisman --------------enig80144CFA608FCFD1F6BAC6CD 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.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBRMuPDUNOZDESBK8FAQIffAf+LVNNpl3j6SDU7rWqP9J7/AZtnrDQQ99D FWH2wvZABVPrHLH7LktUYYpot4HHnd0BAkzmiiSXDKjXaeRsYsuc/JMk+8dNLTl8 PsFHE/SeJ2P71EpFfEDyo/3GxZsQUCoygneOO+A4V5NOEv/CljzfYWS8kRDy0y1P Z5A0VwcS+4bFiMon2REw6FrGI0fspo6cUoQJOvCPlZXZWcURWTO+DG5q1C9AkLDd L/CJCSbX74wTBkR+jcnAOGxPweylj2CUDOB+oC6a3gU2YzCIZLcwlqFlbKUU263U ozY2hPSulgTdgKw0fC1bfv4Jm2axFs1NomOXDtzlIUqEpLw+BU+1BA== =wmad -----END PGP SIGNATURE----- --------------enig80144CFA608FCFD1F6BAC6CD-- From owner-freebsd-stable@FreeBSD.ORG Sat Jul 29 17:42:43 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A06F516A4E0 for ; Sat, 29 Jul 2006 17:42:43 +0000 (UTC) (envelope-from fydernix@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E12043D4C for ; Sat, 29 Jul 2006 17:42:42 +0000 (GMT) (envelope-from fydernix@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so188367uge for ; Sat, 29 Jul 2006 10:42:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=hYlJPa0e15n7UG9vYBcGnXeuPNZSJ7FtDhR44wGaFW7wlnIPbpzE2d5qqRc4p38KEHpvU/6pGdjt/WLP4oWf41piYCuK9ToYEcJP+58PI2tkmiAZTMiRVp5oAh1m/bo93LllRYk6nRbt1FmGe8PAiUDtX5w6uRgAcwfgSx6mk4E= Received: by 10.78.200.3 with SMTP id x3mr141475huf; Sat, 29 Jul 2006 10:42:41 -0700 (PDT) Received: by 10.78.117.1 with HTTP; Sat, 29 Jul 2006 10:42:41 -0700 (PDT) Message-ID: Date: Sat, 29 Jul 2006 13:42:41 -0400 From: "SigmaX asdf" To: freebsd-stable@freebsd.org In-Reply-To: <20060729070410.GD8063@sysadm.stc> MIME-Version: 1.0 References: <20060729070410.GD8063@sysadm.stc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Gateway X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2006 17:42:43 -0000 On 7/29/06, Igor Robul wrote: > > On Fri, Jul 28, 2006 at 07:00:18PM -0400, SigmaX asdf wrote: > > gateway_enable="YES" > > firewall_enable="YES" > > firewall_type="OPEN" > > natd_enabl="YES" > ^^^^^^^^^^^^^^^^^^^ > Should be natd_enable="YES" Heh; yeah, typo in my post. The file has it ok. Is there something I have to do to specify the interfaces which have nat enabled? Does natd_enable automatically forward any/every packet to any/every interface? SigmaX From owner-freebsd-stable@FreeBSD.ORG Sat Jul 29 19:03:24 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E35A16A575 for ; Sat, 29 Jul 2006 19:03:24 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id E770B43E8C for ; Sat, 29 Jul 2006 19:02:51 +0000 (GMT) (envelope-from arno@heho.snv.jussieu.fr) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.13.7/jtpda-5.4) with ESMTP id k6TJ2otN013445 ; Sat, 29 Jul 2006 21:02:50 +0200 (CEST) X-Ids: 166 Received: from heho.labo (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.13.3/jtpda-5.2) with ESMTP id k6TJ2nrW039653 ; Sat, 29 Jul 2006 21:02:49 +0200 (MEST) Received: (from arno@localhost) by heho.labo (8.13.3/8.13.1/Submit) id k6TJ2mbX039650; Sat, 29 Jul 2006 21:02:48 +0200 (MEST) (envelope-from arno) Sender: arno@heho.snv.jussieu.fr To: freebsd-stable@freebsd.org References: From: "Arno J. Klaassen" Date: 29 Jul 2006 21:02:48 +0200 In-Reply-To: Message-ID: Lines: 20 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (shiva.jussieu.fr [134.157.0.166]); Sat, 29 Jul 2006 21:02:50 +0200 (CEST) X-Virus-Scanned: ClamAV 0.88.2/1625/Sat Jul 29 14:53:06 2006 on shiva.jussieu.fr X-Virus-Status: Clean X-Miltered: at shiva.jussieu.fr with ID 44CBB0DA.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! Cc: wpaul@windriver.com Subject: Re: nfs-client reveals MFC-if_re-probs (or vice-versa) ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2006 19:03:24 -0000 /me wrote: > I have a curious problem which at first sight seems related to the > end-June MFC of if_re : > > - I 'mount -o nfsv3,intr,noconn,-r=32768,-w=32768 > <-stable-server>:/files/bsd /files/bsd ' > > - (/usr/ports and /usr/src are symlinks to /files/bsd/*) quickly > after a portinstall/portversion etc. I get : > nfs server <-stable-server>: not responding > (and the corresponding process stuck in 'bo_wwa' according to > top(1) ) for info: #define RE_CSUM_FEATURES 0 in otherwise up to date if_re.c solves the problem. Best regards, Arno From owner-freebsd-stable@FreeBSD.ORG Sat Jul 29 19:19:10 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3668616A4E1 for ; Sat, 29 Jul 2006 19:19:10 +0000 (UTC) (envelope-from igorr@speechpro.com) Received: from speechpro.ru (speech-tech-2.ip.PeterStar.net [81.3.190.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9418E43D4C for ; Sat, 29 Jul 2006 19:19:09 +0000 (GMT) (envelope-from igorr@speechpro.com) Received: from [192.168.2.26] (helo=sysadm.stc) by s1.stc with esmtp (Exim 4.53 (FreeBSD)) id 1G6uL6-0000an-24 for freebsd-stable@freebsd.org; Sat, 29 Jul 2006 23:19:08 +0400 Received: from localhost.stc ([127.0.0.1] helo=sysadm.stc) by sysadm.stc with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1G6uLD-00031C-Rt for freebsd-stable@freebsd.org; Sat, 29 Jul 2006 23:19:16 +0400 Received: (from igorr@localhost) by sysadm.stc (8.13.6/8.13.6/Submit) id k6TJJFKp011605 for freebsd-stable@freebsd.org; Sat, 29 Jul 2006 23:19:15 +0400 (MSD) (envelope-from igorr) Date: Sat, 29 Jul 2006 23:19:15 +0400 From: Igor Robul To: freebsd-stable@freebsd.org Message-ID: <20060729191915.GA11595@sysadm.stc> References: <20060729070410.GD8063@sysadm.stc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 X-Archived: Yes Subject: Re: Gateway X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2006 19:19:10 -0000 On Sat, Jul 29, 2006 at 01:42:41PM -0400, SigmaX asdf wrote: > >^^^^^^^^^^^^^^^^^^^ > >Should be natd_enable="YES" > > > Heh; yeah, typo in my post. The file has it ok. Is there something I have > to do to specify the interfaces which have nat enabled? Does natd_enable > automatically forward any/every packet to any/every interface? Personally I use ipfilter, but for ipfw/natd you need to specify "divert" rule. You can find many examples, including ones in FreeBSD handbook.