From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 26 00:10:15 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8110116A4CE for ; Sun, 26 Dec 2004 00:10:15 +0000 (GMT) Received: from smtpout-2.priv.cc.uic.edu (smtpout-2.cc.uic.edu [128.248.155.233]) by mx1.FreeBSD.org (Postfix) with SMTP id F0B4243D1F for ; Sun, 26 Dec 2004 00:10:14 +0000 (GMT) (envelope-from zholla1@uic.edu) Received: (qmail 7832 invoked from network); 25 Dec 2004 18:10:14 -0600 Received: from icarus.cc.uic.edu (128.248.155.80) by smtpout-2.cc.uic.edu with SMTP; 25 Dec 2004 18:10:14 -0600 Date: Sat, 25 Dec 2004 18:10:14 -0600 (CST) From: Zera William Holladay X-X-Sender: zholla1@icarus.cc.uic.edu To: freebsd-hackers@freebsd.org In-Reply-To: <20041225111722.83770.qmail@ns1.interbgc.com> Message-ID: References: <20041225111722.83770.qmail@ns1.interbgc.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: max data segment size problem (process can not allocate more then 1gb memory) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2004 00:10:15 -0000 On Sat, 25 Dec 2004, freebsd wrote: > hello all, > i have problem, when process tryes to allocate more then 1gb memory it > coredumps > i have tryed options MAXDSIZ to 1.5gb but kernel panics > when i put it in loader.conf with kern.maxdsiz kernel panics again > this is my server memory configuration: > vm.kvm_size: 1069543424 > vm.kmem_size: 209715200 > hw.machine: i386 > hw.model: Intel(R) Xeon(TM) CPU 2.40GHz > hw.ncpu: 2 > hw.byteorder: 1234 > hw.physmem: 2142654464 > hw.usermem: 1622208512 > hw.pagesize: 4096 > > can you tell me how can process allocate more then 1gb memory > thanks in advance > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > If your writing code: Can I see that part of the code? Also, can MAXDSIZ be a non-integer type or do you mean 2^20 + 2^19? -Zera Holladay From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 26 00:13:08 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9AA1516A4CF for ; Sun, 26 Dec 2004 00:13:08 +0000 (GMT) Received: from smtpout-2.priv.cc.uic.edu (smtpout-2.cc.uic.edu [128.248.155.233]) by mx1.FreeBSD.org (Postfix) with SMTP id 2BB8343D45 for ; Sun, 26 Dec 2004 00:13:08 +0000 (GMT) (envelope-from zholla1@uic.edu) Received: (qmail 8213 invoked from network); 25 Dec 2004 18:13:07 -0600 Received: from icarus.cc.uic.edu (128.248.155.80) by smtpout-2.cc.uic.edu with SMTP; 25 Dec 2004 18:13:07 -0600 Date: Sat, 25 Dec 2004 18:13:07 -0600 (CST) From: Zera William Holladay X-X-Sender: zholla1@icarus.cc.uic.edu To: freebsd-hackers@freebsd.org In-Reply-To: Message-ID: References: <20041225111722.83770.qmail@ns1.interbgc.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: max data segment size problem (process can not allocate more then 1gb memory) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2004 00:13:08 -0000 On Sat, 25 Dec 2004, Zera William Holladay wrote: > > > On Sat, 25 Dec 2004, freebsd wrote: > > > hello all, > > i have problem, when process tryes to allocate more then 1gb memory it > > coredumps > > i have tryed options MAXDSIZ to 1.5gb but kernel panics > > when i put it in loader.conf with kern.maxdsiz kernel panics again > > this is my server memory configuration: > > vm.kvm_size: 1069543424 > > vm.kmem_size: 209715200 > > hw.machine: i386 > > hw.model: Intel(R) Xeon(TM) CPU 2.40GHz > > hw.ncpu: 2 > > hw.byteorder: 1234 > > hw.physmem: 2142654464 > > hw.usermem: 1622208512 > > hw.pagesize: 4096 > > > > can you tell me how can process allocate more then 1gb memory > > thanks in advance > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > > > If your writing code: > > Can I see that part of the code? Also, can MAXDSIZ be a non-integer type > or do you mean 2^20 + 2^19? > > -Zera Holladay > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > Sorry, I mean 2^30 + 2^29. From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 26 00:13:47 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A018916A4D0 for ; Sun, 26 Dec 2004 00:13:47 +0000 (GMT) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F16143D53 for ; Sun, 26 Dec 2004 00:13:46 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.12.11/8.12.10) with ESMTP id iBQ0DcZm012756; Sun, 26 Dec 2004 10:43:38 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-hackers@freebsd.org Date: Sun, 26 Dec 2004 10:43:16 +1030 User-Agent: KMail/1.7.1 References: <62903.81.84.175.77.1104000639.squirrel@81.84.175.77> In-Reply-To: <62903.81.84.175.77.1104000639.squirrel@81.84.175.77> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1891449.G1CkRUYbxq"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200412261043.30020.doconnor@gsoft.com.au> X-Spam-Score: -5.4 () IN_REP_TO,PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_KMAIL X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) cc: security@revolutionsp.com Subject: Re: Unable to get APM working -- help! X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2004 00:13:47 -0000 --nextPart1891449.G1CkRUYbxq Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sun, 26 Dec 2004 05:20, security@revolutionsp.com wrote: > Still, /dev/apm*'s never show up. Except if I actually disable APM and > enable ACPI instead, /dev/apm will show.. but no /dev/apmctl. > > I'm new to the laptop world and I really would like to enable power saving > features on this laptop.. I managed to get est/estctrl running, and it was > changing my CPU from 600 to 1600 ghz according to the load, but when I > disabled APM and enabled ACPI this ceases to work and the CPU will always > run at 1600ghz. Also, acpiconf -i0 says device not configured.. Use ACPI. It will provide an APM like interface (/dev/apm) for userland apps to use t= o=20 get info. It's possible your laptop doesn't even _do_ APM :) > As far as I was able to see, most battery monitoring stuff (integrated on > KDE and all) will depend on APM.. So I'd really like to enable it! ACPI will allow you to do this plus a lot more. If you want to do things based on power related state changes (eg lid close= ,=20 power button press, AC unplugged etc..) you can use devd which can respond = to=20 ACPI events. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1891449.G1CkRUYbxq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBzgIp5ZPcIHs/zowRAk3vAJ48FMJoT8UqEIvVUvBwe3fsCjs1YACgk0PI Ge2dRde0Dd0e2mLLyr7gkqU= =F+Y7 -----END PGP SIGNATURE----- --nextPart1891449.G1CkRUYbxq-- From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 26 01:00:32 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D05116A4CE for ; Sun, 26 Dec 2004 01:00:32 +0000 (GMT) Received: from mail.revolutionsp.com (ganymede.revolutionsp.com [64.246.0.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B4C943D1F for ; Sun, 26 Dec 2004 01:00:32 +0000 (GMT) (envelope-from security@revolutionsp.com) Received: from mail.revolutionsp.com (localhost [127.0.0.1]) by mail.revolutionsp.com (Postfix) with ESMTP id 8FAE115CA7 for ; Sat, 25 Dec 2004 15:55:52 -0600 (CST) Received: from 81.84.175.77 (SquirrelMail authenticated user security@revolutionsp.com); by mail.revolutionsp.com with HTTP; Sat, 25 Dec 2004 15:55:52 -0600 (CST) Message-ID: <62945.81.84.175.77.1104011752.squirrel@81.84.175.77> In-Reply-To: <200412261043.30020.doconnor@gsoft.com.au> References: <62903.81.84.175.77.1104000639.squirrel@81.84.175.77> <200412261043.30020.doconnor@gsoft.com.au> Date: Sat, 25 Dec 2004 15:55:52 -0600 (CST) From: security@revolutionsp.com To: freebsd-hackers@freebsd.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: Unable to get APM working -- help! X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2004 01:00:32 -0000 Hey, Thanks for the reply! Indeed, I do have a /dev/apm with APM off and ACPI on, but.. APM version: 1.2 APM Management: Enabled AC Line status: unknown Battery Status: charging Remaining battery life: invalid value (0xffffffff) Remaining battery time: unknown Number of batteries: 0 # acpiconf -i0 acpiconf: get battery info (0) failed: Device not configured o CPU Frequency: 1600ghz o Battery left : -1% o Battery time : -1 hrs o Wireless stat: Radio is ON Neither APM or acpiconf or estctrl (it's a port) are doing their jobs. estctrl was correctly lowering the CPU clock to 600ghz, when there was no load, and maxing it (1.6GHz) under load, but with ACPI off. With ACPI on it's always at 1.6GHz. Plus, I've noticed the 'top' CPU values are plain wrong. I was compiling thunderbird, xmms, and firefox and it showed all processes with 0.00% CPU. Are there any battery status/etc KDE applications? I've searched, and found none. Here is a dmesg: Copyright (c) 1992-2004 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 5.3-RELEASE #1: Sat Dec 25 03:41:40 WET 2004 hugo@porntatil.bsdlan.org:/usr/src/sys/i386/compile/laptop-kernel WARNING: debug.mpsafenet forced to 0 as ipsec requires Giant WARNING: MPSAFE network stack disabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) M processor 1.60GHz (1598.65-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6d6 Stepping = 6 Features=0xafe9f9bf real memory = 535691264 (510 MB) avail memory = 514539520 (490 MB) acpi0: on motherboard acpi0: Power Button (fixed) acpi_ec0: port 0x66,0x62 on acpi0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 acpi_tz0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xe0000000-0xefffffff at device 0.0 on pci0 pci0: at device 0.1 (no driver attached) pci0: at device 0.3 (no driver attached) pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) uhci0: port 0x1800-0x181f irq 6 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 0x1820-0x183f irq 6 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 uhci2: port 0x1840-0x185f irq 6 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered pci0: at device 29.7 (no driver attached) pcib2: at device 30.0 on pci0 pci2: on pcib2 bfe0: mem 0xd0204000-0xd0205fff irq 6 at device 2.0 on pci2 miibus0: on bfe0 bmtphy0: on miibus0 bmtphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto bfe0: Ethernet address: 00:c0:9f:6a:8e:1c bfe0: [GIANT-LOCKED] pci2: at device 4.0 (no driver attached) cbb0: mem 0xd0209000-0xd0209fff irq 10 at device 6.0 on pci2 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 fwohci0: <1394 Open Host Controller Interface> mem 0xd0200000-0xd0203fff,0xd020a000-0xd020a7ff irq 10 at device 6.2 on pci2 fwohci0: [GIANT-LOCKED] fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:c0:9f:00:00:32:14:de fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:c0:9f:32:14:de fwe0: Ethernet address: 02:c0:9f:32:14:de sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=0xc000ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) pci2: at device 6.3 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1860-0x186f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 pci0: at device 31.3 (no driver attached) pci0: at device 31.5 (no driver attached) pci0: at device 31.6 (no driver attached) acpi_lid0: on acpi0 acpi_button0: on acpi0 atkbdc0: port 0x64,0x60 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 Generic PS/2 mouse, device ID 0 npx0: [FAST] npx0: on motherboard npx0: INT 16 interface orm0: at iomem 0xe0000-0xe3fff,0xdf800-0xdffff,0xd0000-0xd17ff,0xc0000-0xcffff on isa0 pmtimer0 on isa0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 1598649123 Hz quality 800 Timecounters tick every 10.000 msec WARNING: apm_saver module requires apm enabled IPsec: Initialized Security Association Processing. acpi_cpu: throttling enabled, 8 steps (100% to 12.5%), currently 100.0% ad0: 57231MB [116280/16/63] at ata0-master UDMA100 acd0: DVDR at ata1-master UDMA33 Mounting root from ufs:/dev/ad0s3a Enhanced Speedstep running at 1600 MHz iwi0: mem 0xd0208000-0xd0208fff irq 10 at device 4.0 on pci2 iwi0: Ethernet address: 00:0e:35:8d:db:e3 iwi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps iwi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps iwi0: [GIANT-LOCKED] pcm0: port 0x18c0-0x18ff,0x1c00-0x1cff mem 0xd0000800-0xd00008ff,0xd0000c00-0xd0000dff irq 10 at device 31.5 on pci0 pcm0: [GIANT-LOCKED] pcm0: > On Sun, 26 Dec 2004 05:20, security@revolutionsp.com wrote: >> Still, /dev/apm*'s never show up. Except if I actually disable APM and >> enable ACPI instead, /dev/apm will show.. but no /dev/apmctl. >> >> I'm new to the laptop world and I really would like to enable power >> saving >> features on this laptop.. I managed to get est/estctrl running, and it >> was >> changing my CPU from 600 to 1600 ghz according to the load, but when I >> disabled APM and enabled ACPI this ceases to work and the CPU will >> always >> run at 1600ghz. Also, acpiconf -i0 says device not configured.. > > Use ACPI. > It will provide an APM like interface (/dev/apm) for userland apps to use > to > get info. > > It's possible your laptop doesn't even _do_ APM :) > >> As far as I was able to see, most battery monitoring stuff (integrated >> on >> KDE and all) will depend on APM.. So I'd really like to enable it! > > ACPI will allow you to do this plus a lot more. > > If you want to do things based on power related state changes (eg lid > close, > power button press, AC unplugged etc..) you can use devd which can respond > to > ACPI events. > > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 26 01:43:57 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 076B416A4CE for ; Sun, 26 Dec 2004 01:43:57 +0000 (GMT) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5360043D2D for ; Sun, 26 Dec 2004 01:43:53 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.12.11/8.12.10) with ESMTP id iBQ1hlsX015258; Sun, 26 Dec 2004 12:13:48 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-hackers@freebsd.org Date: Sun, 26 Dec 2004 12:13:10 +1030 User-Agent: KMail/1.7.1 References: <62903.81.84.175.77.1104000639.squirrel@81.84.175.77> <200412261043.30020.doconnor@gsoft.com.au> <62945.81.84.175.77.1104011752.squirrel@81.84.175.77> In-Reply-To: <62945.81.84.175.77.1104011752.squirrel@81.84.175.77> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1515442.EHiTLc3FYt"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200412261213.46361.doconnor@gsoft.com.au> X-Spam-Score: -4.7 () IN_REP_TO,MIME_LONG_LINE_QP,PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,TO_BE_REMOVED_REPLY,USER_AGENT,USER_AGENT_KMAIL X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) cc: security@revolutionsp.com Subject: Re: Unable to get APM working -- help! X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2004 01:43:57 -0000 --nextPart1515442.EHiTLc3FYt Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sun, 26 Dec 2004 08:25, security@revolutionsp.com wrote: > Indeed, I do have a /dev/apm with APM off and ACPI on, but.. > > APM version: 1.2 > APM Management: Enabled > AC Line status: unknown > Battery Status: charging > Remaining battery life: invalid value (0xffffffff) > Remaining battery time: unknown > Number of batteries: 0 > > # acpiconf -i0 > acpiconf: get battery info (0) failed: Device not configured > > o CPU Frequency: 1600ghz > o Battery left : -1% > o Battery time : -1 hrs > o Wireless stat: Radio is ON Try acpiconf -i 1 > Neither APM or acpiconf or estctrl (it's a port) are doing their jobs. > estctrl was correctly lowering the CPU clock to 600ghz, when there was no I prefer acpi_pcc http://www.spa.is.uec.ac.jp/~nfukuda/software/ which I=20 believe does the same thing but only needs a kernel module to work. > load, and maxing it (1.6GHz) under load, but with ACPI off. With ACPI on > it's always at 1.6GHz. Plus, I've noticed the 'top' CPU values are plain > wrong. I was compiling thunderbird, xmms, and firefox and it showed all > processes with 0.00% CPU. Do your kernel and userland match? > Are there any battery status/etc KDE applications? I've searched, and > found none. There is a klaptop system tray doodad which works for me, although.. [inchoate 12:10] /usr/src >acpiconf -i 0 Battery 0 information Design capacity: 71590 mWh Last full capacity: 71590 mWh Technology: secondary (rechargeable) Design voltage: 11100 mV Capacity (warn): 3000 mWh Capacity (low): 1000 mWh Low/warn granularity: 200 mWh Warn/full granularity: 200 mWh Model number: DELL 0004P2 Serial number: 1975 Type: LION OEM info: Sony State: Present Rate: Unknown Remaining Capacity: 71590 mWh Volt: 12537 mV [inchoate 12:10] /usr/src >apm APM version: 1.2 APM Management: Enabled AC Line status: on-line Battery Status: high Remaining battery life: 100% Remaining battery time: unknown Number of batteries: 2 Battery 0: Battery Status: high Remaining battery life: 100% Remaining battery time: 0:00:00 Battery 1: not present Resume timer: unknown Resume on ring indicator: disabled > Here is a dmesg: > > Copyright (c) 1992-2004 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 5.3-RELEASE #1: Sat Dec 25 03:41:40 WET 2004 > hugo@porntatil.bsdlan.org:/usr/src/sys/i386/compile/laptop-kernel > WARNING: debug.mpsafenet forced to 0 as ipsec requires Giant > WARNING: MPSAFE network stack disabled, expect reduced performance. > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Pentium(R) M processor 1.60GHz (1598.65-MHz 686-class CPU) > Origin =3D "GenuineIntel" Id =3D 0x6d6 Stepping =3D 6 > =20 > Features=3D0xafe9f9bfT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE> real memory =3D 535691264 > (510 MB) > avail memory =3D 514539520 (490 MB) > acpi0: on motherboard > acpi0: Power Button (fixed) > acpi_ec0: port 0x66,0x62 on acpi0 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > cpu0: on acpi0 > acpi_tz0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > agp0: mem 0xe0000000-0xefffffff at > device 0.0 on pci0 > pci0: at device 0.1 (no driver attached) > pci0: at device 0.3 (no driver attached) > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > pci1: at device 0.0 (no driver attached) > uhci0: port 0x1800-0x181f irq > 6 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 0x1820-0x183f irq > 6 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 > uhci2: port 0x1840-0x185f irq > 6 at device 29.2 on pci0 > uhci2: [GIANT-LOCKED] > usb2: on uhci2 > usb2: USB revision 1.0 > uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub2: 2 ports with 2 removable, self powered > pci0: at device 29.7 (no driver attached) > pcib2: at device 30.0 on pci0 > pci2: on pcib2 > bfe0: mem 0xd0204000-0xd0205fff irq 6 at > device 2.0 on pci2 > miibus0: on bfe0 > bmtphy0: on miibus0 > bmtphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > bfe0: Ethernet address: 00:c0:9f:6a:8e:1c > bfe0: [GIANT-LOCKED] > pci2: at device 4.0 (no driver attached) > cbb0: mem 0xd0209000-0xd0209fff irq 10 at device 6.0 > on pci2 > cardbus0: on cbb0 > pccard0: <16-bit PCCard bus> on cbb0 > fwohci0: <1394 Open Host Controller Interface> mem > 0xd0200000-0xd0203fff,0xd020a000-0xd020a7ff irq 10 at device 6.2 on pci2 > fwohci0: [GIANT-LOCKED] > fwohci0: OHCI version 1.10 (ROM=3D1) > fwohci0: No. of Isochronous channels is 4. > fwohci0: EUI64 00:c0:9f:00:00:32:14:de > fwohci0: Phy 1394a available S400, 2 ports. > fwohci0: Link S400, max_rec 2048 bytes. > firewire0: on fwohci0 > fwe0: on firewire0 > if_fwe0: Fake Ethernet address: 02:c0:9f:32:14:de > fwe0: Ethernet address: 02:c0:9f:32:14:de > sbp0: on firewire0 > fwohci0: Initiate bus reset > fwohci0: node_id=3D0xc000ffc0, gen=3D1, CYCLEMASTER mode > firewire0: 1 nodes, maxhop <=3D 0, cable IRM =3D 0 (me) > firewire0: bus manager 0 (me) > pci2: at device 6.3 (no driver attached) > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port > 0x1860-0x186f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 > ata0: channel #0 on atapci0 > ata1: channel #1 on atapci0 > pci0: at device 31.3 (no driver attached) > pci0: at device 31.5 (no driver attached) > pci0: at device 31.6 (no driver attached) > acpi_lid0: on acpi0 > acpi_button0: on acpi0 > atkbdc0: port 0x64,0x60 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 Generic PS/2 mouse, device ID 0 > npx0: [FAST] > npx0: on motherboard > npx0: INT 16 interface > orm0: at iomem > 0xe0000-0xe3fff,0xdf800-0xdffff,0xd0000-0xd17ff,0xc0000-0xcffff on isa0 > pmtimer0 on isa0 > ppc0: parallel port not found. > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=3D0x300> > sio0: configured irq 4 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > sio0: type 8250 or not responding > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > Timecounter "TSC" frequency 1598649123 Hz quality 800 > Timecounters tick every 10.000 msec > WARNING: apm_saver module requires apm enabled > IPsec: Initialized Security Association Processing. > acpi_cpu: throttling enabled, 8 steps (100% to 12.5%), currently 100.0% > ad0: 57231MB [116280/16/63] at ata0-master > UDMA100 acd0: DVDR at ata1-master UDMA33 > Mounting root from ufs:/dev/ad0s3a > Enhanced Speedstep running at 1600 MHz > iwi0: mem 0xd0208000-0xd0208fff irq > 10 at device 4.0 on pci2 > iwi0: Ethernet address: 00:0e:35:8d:db:e3 > iwi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps > iwi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps > 24Mbps 36Mbps 48Mbps 54Mbps > iwi0: [GIANT-LOCKED] > pcm0: port 0x18c0-0x18ff,0x1c00-0x1cff mem > 0xd0000800-0xd00008ff,0xd0000c00-0xd0000dff irq 10 at device 31.5 on pci0 > pcm0: [GIANT-LOCKED] > pcm0: > > > On Sun, 26 Dec 2004 05:20, security@revolutionsp.com wrote: > >> Still, /dev/apm*'s never show up. Except if I actually disable APM and > >> enable ACPI instead, /dev/apm will show.. but no /dev/apmctl. > >> > >> I'm new to the laptop world and I really would like to enable power > >> saving > >> features on this laptop.. I managed to get est/estctrl running, and it > >> was > >> changing my CPU from 600 to 1600 ghz according to the load, but when I > >> disabled APM and enabled ACPI this ceases to work and the CPU will > >> always > >> run at 1600ghz. Also, acpiconf -i0 says device not configured.. > > > > Use ACPI. > > It will provide an APM like interface (/dev/apm) for userland apps to u= se > > to > > get info. > > > > It's possible your laptop doesn't even _do_ APM :) > > > >> As far as I was able to see, most battery monitoring stuff (integrated > >> on > >> KDE and all) will depend on APM.. So I'd really like to enable it! > > > > ACPI will allow you to do this plus a lot more. > > > > If you want to do things based on power related state changes (eg lid > > close, > > power button press, AC unplugged etc..) you can use devd which can > > respond to > > ACPI events. > > > > -- > > Daniel O'Connor software and network engineer > > for Genesis Software - http://www.gsoft.com.au > > "The nice thing about standards is that there > > are so many of them to choose from." > > -- Andrew Tanenbaum > > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1515442.EHiTLc3FYt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBzhdS5ZPcIHs/zowRAsoqAJ46CrUKwoGjw3jTWxSrK+wyjFOzZQCgm0oD 5hgyYO+ZVGQvmy1NAIFsTpg= =jaiB -----END PGP SIGNATURE----- --nextPart1515442.EHiTLc3FYt-- From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 26 06:03:24 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D865616A4CE for ; Sun, 26 Dec 2004 06:03:24 +0000 (GMT) Received: from mail.revolutionsp.com (ganymede.revolutionsp.com [64.246.0.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5791843D48 for ; Sun, 26 Dec 2004 06:03:24 +0000 (GMT) (envelope-from security@revolutionsp.com) Received: from mail.revolutionsp.com (localhost [127.0.0.1]) by mail.revolutionsp.com (Postfix) with ESMTP id 617D215CA7 for ; Sat, 25 Dec 2004 20:58:44 -0600 (CST) Received: from 81.84.175.77 (SquirrelMail authenticated user security@revolutionsp.com); by mail.revolutionsp.com with HTTP; Sat, 25 Dec 2004 20:58:44 -0600 (CST) Message-ID: <63000.81.84.175.77.1104029924.squirrel@81.84.175.77> In-Reply-To: <200412261213.46361.doconnor@gsoft.com.au> References: <62903.81.84.175.77.1104000639.squirrel@81.84.175.77> <200412261043.30020.doconnor@gsoft.com.au> <62945.81.84.175.77.1104011752.squirrel@81.84.175.77> <200412261213.46361.doconnor@gsoft.com.au> Date: Sat, 25 Dec 2004 20:58:44 -0600 (CST) From: security@revolutionsp.com To: freebsd-hackers@freebsd.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: Unable to get APM working -- help! X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2004 06:03:25 -0000 > On Sun, 26 Dec 2004 08:25, security@revolutionsp.com wrote: >> Indeed, I do have a /dev/apm with APM off and ACPI on, but.. >> >> APM version: 1.2 >> APM Management: Enabled >> AC Line status: unknown >> Battery Status: charging >> Remaining battery life: invalid value (0xffffffff) >> Remaining battery time: unknown >> Number of batteries: 0 >> >> # acpiconf -i0 >> acpiconf: get battery info (0) failed: Device not configured >> >> o CPU Frequency: 1600ghz >> o Battery left : -1% >> o Battery time : -1 hrs >> o Wireless stat: Radio is ON > > Try acpiconf -i 1 > Same result :/ >> Neither APM or acpiconf or estctrl (it's a port) are doing their jobs. >> estctrl was correctly lowering the CPU clock to 600ghz, when there was >> no > > I prefer acpi_pcc http://www.spa.is.uec.ac.jp/~nfukuda/software/ which I > believe does the same thing but only needs a kernel module to work. Does it work on Pentium-M ? > >> load, and maxing it (1.6GHz) under load, but with ACPI off. With ACPI on >> it's always at 1.6GHz. Plus, I've noticed the 'top' CPU values are plain >> wrong. I was compiling thunderbird, xmms, and firefox and it showed all >> processes with 0.00% CPU. > > Do your kernel and userland match? 5.3-RELEASE from cd and a custom kernel I built. I've just tested, and the results are widly innacurate ONLY with ACPI turned on.. weird. > >> Are there any battery status/etc KDE applications? I've searched, and >> found none. > > There is a klaptop system tray doodad which works for me, although.. > [inchoate 12:10] /usr/src >acpiconf -i 0 > Battery 0 information > Design capacity: 71590 mWh > Last full capacity: 71590 mWh > Technology: secondary (rechargeable) > Design voltage: 11100 mV > Capacity (warn): 3000 mWh > Capacity (low): 1000 mWh > Low/warn granularity: 200 mWh > Warn/full granularity: 200 mWh > Model number: DELL 0004P2 > Serial number: 1975 > Type: LION > OEM info: Sony > State: > Present Rate: Unknown > Remaining Capacity: 71590 mWh > Volt: 12537 mV > [inchoate 12:10] /usr/src >apm > APM version: 1.2 > APM Management: Enabled > AC Line status: on-line > Battery Status: high > Remaining battery life: 100% > Remaining battery time: unknown > Number of batteries: 2 > Battery 0: > Battery Status: high > Remaining battery life: 100% > Remaining battery time: 0:00:00 > Battery 1: > not present > Resume timer: unknown > Resume on ring indicator: disabled > Did you have to do anything in special to make -i 0 work? (it says device not configured to me.. perhaps I missed something) >> Here is a dmesg: >> >> Copyright (c) 1992-2004 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 5.3-RELEASE #1: Sat Dec 25 03:41:40 WET 2004 >> hugo@porntatil.bsdlan.org:/usr/src/sys/i386/compile/laptop-kernel >> WARNING: debug.mpsafenet forced to 0 as ipsec requires Giant >> WARNING: MPSAFE network stack disabled, expect reduced performance. >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> CPU: Intel(R) Pentium(R) M processor 1.60GHz (1598.65-MHz 686-class CPU) >> Origin = "GenuineIntel" Id = 0x6d6 Stepping = 6 >> >> Features=0xafe9f9bf>T,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE> real memory = 535691264 >> (510 MB) >> avail memory = 514539520 (490 MB) >> acpi0: on motherboard >> acpi0: Power Button (fixed) >> acpi_ec0: port 0x66,0x62 on acpi0 >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 >> cpu0: on acpi0 >> acpi_tz0: on acpi0 >> pcib0: port 0xcf8-0xcff on acpi0 >> pci0: on pcib0 >> agp0: mem 0xe0000000-0xefffffff at >> device 0.0 on pci0 >> pci0: at device 0.1 (no driver attached) >> pci0: at device 0.3 (no driver attached) >> pcib1: at device 1.0 on pci0 >> pci1: on pcib1 >> pci1: at device 0.0 (no driver attached) >> uhci0: port 0x1800-0x181f >> irq >> 6 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 0x1820-0x183f >> irq >> 6 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 >> uhci2: port 0x1840-0x185f >> irq >> 6 at device 29.2 on pci0 >> uhci2: [GIANT-LOCKED] >> usb2: on uhci2 >> usb2: USB revision 1.0 >> uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 >> uhub2: 2 ports with 2 removable, self powered >> pci0: at device 29.7 (no driver attached) >> pcib2: at device 30.0 on pci0 >> pci2: on pcib2 >> bfe0: mem 0xd0204000-0xd0205fff irq 6 >> at >> device 2.0 on pci2 >> miibus0: on bfe0 >> bmtphy0: on miibus0 >> bmtphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >> bfe0: Ethernet address: 00:c0:9f:6a:8e:1c >> bfe0: [GIANT-LOCKED] >> pci2: at device 4.0 (no driver attached) >> cbb0: mem 0xd0209000-0xd0209fff irq 10 at device >> 6.0 >> on pci2 >> cardbus0: on cbb0 >> pccard0: <16-bit PCCard bus> on cbb0 >> fwohci0: <1394 Open Host Controller Interface> mem >> 0xd0200000-0xd0203fff,0xd020a000-0xd020a7ff irq 10 at device 6.2 on pci2 >> fwohci0: [GIANT-LOCKED] >> fwohci0: OHCI version 1.10 (ROM=1) >> fwohci0: No. of Isochronous channels is 4. >> fwohci0: EUI64 00:c0:9f:00:00:32:14:de >> fwohci0: Phy 1394a available S400, 2 ports. >> fwohci0: Link S400, max_rec 2048 bytes. >> firewire0: on fwohci0 >> fwe0: on firewire0 >> if_fwe0: Fake Ethernet address: 02:c0:9f:32:14:de >> fwe0: Ethernet address: 02:c0:9f:32:14:de >> sbp0: on firewire0 >> fwohci0: Initiate bus reset >> fwohci0: node_id=0xc000ffc0, gen=1, CYCLEMASTER mode >> firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) >> firewire0: bus manager 0 (me) >> pci2: at device 6.3 (no driver attached) >> isab0: at device 31.0 on pci0 >> isa0: on isab0 >> atapci0: port >> 0x1860-0x186f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 >> ata0: channel #0 on atapci0 >> ata1: channel #1 on atapci0 >> pci0: at device 31.3 (no driver attached) >> pci0: at device 31.5 (no driver attached) >> pci0: at device 31.6 (no driver attached) >> acpi_lid0: on acpi0 >> acpi_button0: on acpi0 >> atkbdc0: port 0x64,0x60 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 Generic PS/2 mouse, device ID 0 >> npx0: [FAST] >> npx0: on motherboard >> npx0: INT 16 interface >> orm0: at iomem >> 0xe0000-0xe3fff,0xdf800-0xdffff,0xd0000-0xd17ff,0xc0000-0xcffff on isa0 >> pmtimer0 on isa0 >> ppc0: parallel port not found. >> sc0: at flags 0x100 on isa0 >> sc0: VGA <16 virtual consoles, flags=0x300> >> sio0: configured irq 4 not in bitmap of probed irqs 0 >> sio0: port may not be enabled >> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 >> sio0: type 8250 or not responding >> sio1: configured irq 3 not in bitmap of probed irqs 0 >> sio1: port may not be enabled >> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on >> isa0 >> Timecounter "TSC" frequency 1598649123 Hz quality 800 >> Timecounters tick every 10.000 msec >> WARNING: apm_saver module requires apm enabled >> IPsec: Initialized Security Association Processing. >> acpi_cpu: throttling enabled, 8 steps (100% to 12.5%), currently 100.0% >> ad0: 57231MB [116280/16/63] at ata0-master >> UDMA100 acd0: DVDR at ata1-master UDMA33 >> Mounting root from ufs:/dev/ad0s3a >> Enhanced Speedstep running at 1600 MHz >> iwi0: mem 0xd0208000-0xd0208fff >> irq >> 10 at device 4.0 on pci2 >> iwi0: Ethernet address: 00:0e:35:8d:db:e3 >> iwi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps >> iwi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps >> 24Mbps 36Mbps 48Mbps 54Mbps >> iwi0: [GIANT-LOCKED] >> pcm0: port 0x18c0-0x18ff,0x1c00-0x1cff mem >> 0xd0000800-0xd00008ff,0xd0000c00-0xd0000dff irq 10 at device 31.5 on >> pci0 >> pcm0: [GIANT-LOCKED] >> pcm0: >> >> > On Sun, 26 Dec 2004 05:20, security@revolutionsp.com wrote: >> >> Still, /dev/apm*'s never show up. Except if I actually disable APM >> and >> >> enable ACPI instead, /dev/apm will show.. but no /dev/apmctl. >> >> >> >> I'm new to the laptop world and I really would like to enable power >> >> saving >> >> features on this laptop.. I managed to get est/estctrl running, and >> it >> >> was >> >> changing my CPU from 600 to 1600 ghz according to the load, but when >> I >> >> disabled APM and enabled ACPI this ceases to work and the CPU will >> >> always >> >> run at 1600ghz. Also, acpiconf -i0 says device not configured.. >> > >> > Use ACPI. >> > It will provide an APM like interface (/dev/apm) for userland apps to >> use >> > to >> > get info. >> > >> > It's possible your laptop doesn't even _do_ APM :) >> > >> >> As far as I was able to see, most battery monitoring stuff >> (integrated >> >> on >> >> KDE and all) will depend on APM.. So I'd really like to enable it! >> > >> > ACPI will allow you to do this plus a lot more. >> > >> > If you want to do things based on power related state changes (eg lid >> > close, >> > power button press, AC unplugged etc..) you can use devd which can >> > respond to >> > ACPI events. >> > >> > -- >> > Daniel O'Connor software and network engineer >> > for Genesis Software - http://www.gsoft.com.au >> > "The nice thing about standards is that there >> > are so many of them to choose from." >> > -- Andrew Tanenbaum >> > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C >> >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to >> "freebsd-hackers-unsubscribe@freebsd.org" > > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 26 07:01:34 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 60C9F16A4CE for ; Sun, 26 Dec 2004 07:01:34 +0000 (GMT) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 10D5343D39 for ; Sun, 26 Dec 2004 07:01:33 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.12.11/8.12.10) with ESMTP id iBQ71TgD018628; Sun, 26 Dec 2004 17:31:29 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-hackers@freebsd.org Date: Sun, 26 Dec 2004 17:31:03 +1030 User-Agent: KMail/1.7.1 References: <62903.81.84.175.77.1104000639.squirrel@81.84.175.77> <200412261213.46361.doconnor@gsoft.com.au> <63000.81.84.175.77.1104029924.squirrel@81.84.175.77> In-Reply-To: <63000.81.84.175.77.1104029924.squirrel@81.84.175.77> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4907868.9EMzr6fWsj"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200412261731.25493.doconnor@gsoft.com.au> X-Spam-Score: -5.1 () IN_REP_TO,MIME_LONG_LINE_QP,PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_KMAIL X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) cc: security@revolutionsp.com Subject: Re: Unable to get APM working -- help! X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2004 07:01:34 -0000 --nextPart4907868.9EMzr6fWsj Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sun, 26 Dec 2004 13:28, security@revolutionsp.com wrote: > > Try acpiconf -i 1 > > Same result :/ Hmm.. what's your dmesg output when you boot verbose with ACPI enabled? > > I prefer acpi_pcc http://www.spa.is.uec.ac.jp/~nfukuda/software/ which I > > believe does the same thing but only needs a kernel module to work. > > Does it work on Pentium-M ? Yep. > >> load, and maxing it (1.6GHz) under load, but with ACPI off. With ACPI = on > >> it's always at 1.6GHz. Plus, I've noticed the 'top' CPU values are pla= in > >> wrong. I was compiling thunderbird, xmms, and firefox and it showed all > >> processes with 0.00% CPU. > > > > Do your kernel and userland match? > > 5.3-RELEASE from cd and a custom kernel I built. I've just tested, and the > results are widly innacurate ONLY with ACPI turned on.. weird. Any chance there is a new BIOS available for that system? > Did you have to do anything in special to make -i 0 work? (it says device > not configured to me.. perhaps I missed something) No.. If I try and look at a non existent battery slot it says 'device not=20 configured' so maybe it thinks you have no batteries for some strange reaso= n. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart4907868.9EMzr6fWsj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBzmHF5ZPcIHs/zowRAjC0AKCsRrqXhtXIP95S2G2PrjThtdozOwCfSS54 Csajf1zqCQfJxQ/i0ykX2XY= =i68n -----END PGP SIGNATURE----- --nextPart4907868.9EMzr6fWsj-- From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 26 07:58:07 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C5D4316A4CE for ; Sun, 26 Dec 2004 07:58:07 +0000 (GMT) Received: from mail.revolutionsp.com (ganymede.revolutionsp.com [64.246.0.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5115B43D2F for ; Sun, 26 Dec 2004 07:58:07 +0000 (GMT) (envelope-from security@revolutionsp.com) Received: from mail.revolutionsp.com (localhost [127.0.0.1]) by mail.revolutionsp.com (Postfix) with ESMTP id 6CA6A15CA7 for ; Sat, 25 Dec 2004 22:53:27 -0600 (CST) Received: from 81.84.175.77 (SquirrelMail authenticated user security@revolutionsp.com); by mail.revolutionsp.com with HTTP; Sat, 25 Dec 2004 22:53:27 -0600 (CST) Message-ID: <62920.81.84.175.77.1104036807.squirrel@81.84.175.77> In-Reply-To: <200412261731.25493.doconnor@gsoft.com.au> References: <62903.81.84.175.77.1104000639.squirrel@81.84.175.77> <200412261213.46361.doconnor@gsoft.com.au> <63000.81.84.175.77.1104029924.squirrel@81.84.175.77> <200412261731.25493.doconnor@gsoft.com.au> Date: Sat, 25 Dec 2004 22:53:27 -0600 (CST) From: security@revolutionsp.com To: freebsd-hackers@freebsd.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="----=_20041225225327_53204" X-Priority: 3 (Normal) Importance: Normal Subject: Re: Unable to get APM working -- help! X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2004 07:58:07 -0000 ------=_20041225225327_53204 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit > On Sun, 26 Dec 2004 13:28, security@revolutionsp.com wrote: >> > Try acpiconf -i 1 >> >> Same result :/ > > Hmm.. what's your dmesg output when you boot verbose with ACPI enabled? > Attached it. >> > I prefer acpi_pcc http://www.spa.is.uec.ac.jp/~nfukuda/software/ which >> I >> > believe does the same thing but only needs a kernel module to work. >> >> Does it work on Pentium-M ? > > Yep. > I'll try it out; meanwhile, I've discovered the sysctl to change this manually. I've checked it works by trying to compile something at the lowest CPU clock speed. It was slow to hell :-) >> >> load, and maxing it (1.6GHz) under load, but with ACPI off. With ACPI >> on >> >> it's always at 1.6GHz. Plus, I've noticed the 'top' CPU values are >> plain >> >> wrong. I was compiling thunderbird, xmms, and firefox and it showed >> all >> >> processes with 0.00% CPU. >> > >> > Do your kernel and userland match? >> >> 5.3-RELEASE from cd and a custom kernel I built. I've just tested, and >> the >> results are widly innacurate ONLY with ACPI turned on.. weird. > > Any chance there is a new BIOS available for that system? > A quick googling session brought up nothing. >> Did you have to do anything in special to make -i 0 work? (it says >> device >> not configured to me.. perhaps I missed something) > > No.. If I try and look at a non existent battery slot it says 'device not > configured' so maybe it thinks you have no batteries for some strange > reason. > I've installed klaptop and it shows battery as -1 and 'not charging' acpiconf -i[0-9] didn't do any good either :/ > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > dmesg (ACPI on, boot verbose) ** check attached file ** ------=_20041225225327_53204 Content-Type: application/octet-stream; name="dmesg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dmesg" CXBlbmFsdHk6CSAgNTA1MApcXF9TQl8uUENJMC5MUEMwLkxOS0MgKHJlZmVyZW5jZXMgMiwgcHJp b3JpdHkgMTAxMDApOgoJaW50ZXJydXB0czoJICAgICA2CglwZW5hbHR5OgkgIDUwNTAKXFxfU0Jf LlBDSTAuTFBDMC5MTktEIChyZWZlcmVuY2VzIDEsIHByaW9yaXR5IDUwNTApOgoJaW50ZXJydXB0 czoJICAgICA2CglwZW5hbHR5OgkgIDUwNTAKXFxfU0JfLlBDSTAuTFBDMC5MTktIIChyZWZlcmVu Y2VzIDEsIHByaW9yaXR5IDIwKToKCWludGVycnVwdHM6CSAgICAxMAoJcGVuYWx0eToJICAgIDIw ClxcX1NCXy5QQ0kwLkxQQzAuTE5LQiAocmVmZXJlbmNlcyAxLCBwcmlvcml0eSAyMCk6CglpbnRl cnJ1cHRzOgkgICAgMTAKCXBlbmFsdHk6CSAgICAyMApwY2liMDogc2xvdCAyOSBJTlRBIHJvdXRl ZCB0byBpcnEgNiB2aWEgXFxfU0JfLlBDSTAuTFBDMC5MTktBCmZvdW5kLT4JdmVuZG9yPTB4ODA4 NiwgZGV2PTB4MjRjMiwgcmV2aWQ9MHgwMwoJYnVzPTAsIHNsb3Q9MjksIGZ1bmM9MAoJY2xhc3M9 MGMtMDMtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwNSwgc3RhdHJlZz0w eDAyODAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250 PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9NgoJbWFwWzIw XTogdHlwZSA0LCByYW5nZSAzMiwgYmFzZSAwMDAwMTgyMCwgc2l6ZSAgNSwgZW5hYmxlZApwY2li MDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4yOS5JTlRCIChzcmMgXFxfU0JfLlBDSTAuTFBDMC5MTktE KQpwY2liMDogcG9zc2libGUgaW50ZXJydXB0czogIDYKQUNQSSBQQ0kgbGluayBhcmJpdHJhdGVk IHNldHRpbmdzOgpcXF9TQl8uUENJMC5MUEMwLkxOS0MgKHJlZmVyZW5jZXMgMiwgcHJpb3JpdHkg MTAyNDApOgoJaW50ZXJydXB0czoJICAgICA2CglwZW5hbHR5OgkgIDUxMjAKXFxfU0JfLlBDSTAu TFBDMC5MTktEIChyZWZlcmVuY2VzIDEsIHByaW9yaXR5IDUxMjApOgoJaW50ZXJydXB0czoJICAg ICA2CglwZW5hbHR5OgkgIDUxMjAKXFxfU0JfLlBDSTAuTFBDMC5MTktIIChyZWZlcmVuY2VzIDEs IHByaW9yaXR5IDQwKToKCWludGVycnVwdHM6CSAgICAxMAoJcGVuYWx0eToJICAgIDQwClxcX1NC Xy5QQ0kwLkxQQzAuTE5LQiAocmVmZXJlbmNlcyAxLCBwcmlvcml0eSA0MCk6CglpbnRlcnJ1cHRz OgkgICAgMTAKCXBlbmFsdHk6CSAgICA0MApwY2liMDogc2xvdCAyOSBJTlRCIHJvdXRlZCB0byBp cnEgNiB2aWEgXFxfU0JfLlBDSTAuTFBDMC5MTktECmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2 PTB4MjRjNCwgcmV2aWQ9MHgwMwoJYnVzPTAsIHNsb3Q9MjksIGZ1bmM9MQoJY2xhc3M9MGMtMDMt MDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNSwgc3RhdHJlZz0weDAyODAs IGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAg KDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1iLCBpcnE9NgoJbWFwWzIwXTogdHlw ZSA0LCByYW5nZSAzMiwgYmFzZSAwMDAwMTg0MCwgc2l6ZSAgNSwgZW5hYmxlZApwY2liMDogbWF0 Y2hlZCBlbnRyeSBmb3IgMC4yOS5JTlRDIChzcmMgXFxfU0JfLlBDSTAuTFBDMC5MTktDKQpwY2li MDogcG9zc2libGUgaW50ZXJydXB0czogIDYKQUNQSSBQQ0kgbGluayBhcmJpdHJhdGVkIHNldHRp bmdzOgpcXF9TQl8uUENJMC5MUEMwLkxOS0MgKHJlZmVyZW5jZXMgMiwgcHJpb3JpdHkgMTAzNjAp OgoJaW50ZXJydXB0czoJICAgICA2CglwZW5hbHR5OgkgIDUxODAKXFxfU0JfLlBDSTAuTFBDMC5M TktIIChyZWZlcmVuY2VzIDEsIHByaW9yaXR5IDYwKToKCWludGVycnVwdHM6CSAgICAxMAoJcGVu YWx0eToJICAgIDYwClxcX1NCXy5QQ0kwLkxQQzAuTE5LQiAocmVmZXJlbmNlcyAxLCBwcmlvcml0 eSA2MCk6CglpbnRlcnJ1cHRzOgkgICAgMTAKCXBlbmFsdHk6CSAgICA2MApwY2liMDogc2xvdCAy OSBJTlRDIHJvdXRlZCB0byBpcnEgNiB2aWEgXFxfU0JfLlBDSTAuTFBDMC5MTktDCmZvdW5kLT4J dmVuZG9yPTB4ODA4NiwgZGV2PTB4MjRjNywgcmV2aWQ9MHgwMwoJYnVzPTAsIHNsb3Q9MjksIGZ1 bmM9MgoJY2xhc3M9MGMtMDMtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAw NSwgc3RhdHJlZz0weDAyODAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgw IG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1jLCBp cnE9NgoJbWFwWzEwXTogdHlwZSAxLCByYW5nZSAzMiwgYmFzZSBkMDAwMDAwMCwgc2l6ZSAxMCwg ZW5hYmxlZApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4yOS5JTlREIChzcmMgXFxfU0JfLlBD STAuTFBDMC5MTktIKQpwY2liMDogcG9zc2libGUgaW50ZXJydXB0czogMTAKQUNQSSBQQ0kgbGlu ayBhcmJpdHJhdGVkIHNldHRpbmdzOgpcXF9TQl8uUENJMC5MUEMwLkxOS0ggKHJlZmVyZW5jZXMg MSwgcHJpb3JpdHkgODApOgoJaW50ZXJydXB0czoJICAgIDEwCglwZW5hbHR5OgkgICAgODAKXFxf U0JfLlBDSTAuTFBDMC5MTktCIChyZWZlcmVuY2VzIDEsIHByaW9yaXR5IDgwKToKCWludGVycnVw dHM6CSAgICAxMAoJcGVuYWx0eToJICAgIDgwCnBjaWIwOiBzbG90IDI5IElOVEQgcm91dGVkIHRv IGlycSAxMCB2aWEgXFxfU0JfLlBDSTAuTFBDMC5MTktICmZvdW5kLT4JdmVuZG9yPTB4ODA4Niwg ZGV2PTB4MjRjZCwgcmV2aWQ9MHgwMwoJYnVzPTAsIHNsb3Q9MjksIGZ1bmM9NwoJY2xhc3M9MGMt MDMtMjAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDEwNiwgc3RhdHJlZz0weDAy OTAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4 MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1kLCBpcnE9MTAKCXBvd2Vyc3Bl YyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMApmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRl dj0weDI0NDgsIHJldmlkPTB4ODMKCWJ1cz0wLCBzbG90PTMwLCBmdW5jPTAKCWNsYXNzPTA2LTA0 LTAwLCBoZHJ0eXBlPTB4MDEsIG1mZGV2PTAKCWNtZHJlZz0weDAxMDcsIHN0YXRyZWc9MHg4ODgw LCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDA0 ICgxMDAwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2 PTB4MjRjYywgcmV2aWQ9MHgwMwoJYnVzPTAsIHNsb3Q9MzEsIGZ1bmM9MAoJY2xhc3M9MDYtMDEt MDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwZiwgc3RhdHJlZz0weDAyODAs IGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAg KDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCW1hcFsyMF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJh c2UgMDAwMDE4NjAsIHNpemUgIDQsIGVuYWJsZWQKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9 MHgyNGNhLCByZXZpZD0weDAzCglidXM9MCwgc2xvdD0zMSwgZnVuYz0xCgljbGFzcz0wMS0wMS04 YSwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDA1LCBzdGF0cmVnPTB4MDI4MCwg Y2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAo MCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0yNTUKCW1hcFsyMF06IHR5 cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMDE4ODAsIHNpemUgIDUsIGVuYWJsZWQKcGNpYjA6IG1h dGNoZWQgZW50cnkgZm9yIDAuMzEuSU5UQiAoc3JjIFxcX1NCXy5QQ0kwLkxQQzAuTE5LQikKcGNp YjA6IHBvc3NpYmxlIGludGVycnVwdHM6IDEwCkFDUEkgUENJIGxpbmsgYXJiaXRyYXRlZCBzZXR0 aW5nczoKXFxfU0JfLlBDSTAuTFBDMC5MTktCIChyZWZlcmVuY2VzIDEsIHByaW9yaXR5IDExMCk6 CglpbnRlcnJ1cHRzOgkgICAgMTAKCXBlbmFsdHk6CSAgIDExMApwY2liMDogc2xvdCAzMSBJTlRC IHJvdXRlZCB0byBpcnEgMTAgdmlhIFxcX1NCXy5QQ0kwLkxQQzAuTE5LQgpmb3VuZC0+CXZlbmRv cj0weDgwODYsIGRldj0weDI0YzMsIHJldmlkPTB4MDMKCWJ1cz0wLCBzbG90PTMxLCBmdW5jPTMK CWNsYXNzPTBjLTA1LTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDEsIHN0 YXRyZWc9MHgwMjgwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyks IG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YiwgaXJxPTEw CgltYXBbMTBdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDAxYzAwLCBzaXplICA4LCBlbmFi bGVkCgltYXBbMTRdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDAxOGMwLCBzaXplICA2LCBl bmFibGVkCgltYXBbMThdOiB0eXBlIDEsIHJhbmdlIDMyLCBiYXNlIGQwMDAwYzAwLCBzaXplICA5 LCBlbmFibGVkCgltYXBbMWNdOiB0eXBlIDEsIHJhbmdlIDMyLCBiYXNlIGQwMDAwODAwLCBzaXpl ICA4LCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjMxLklOVEIgKHNyYyBcXF9T Ql8uUENJMC5MUEMwLkxOS0IpCnBjaWIwOiBzbG90IDMxIElOVEIgaXMgYWxyZWFkeSByb3V0ZWQg dG8gaXJxIDEwCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjRjNSwgcmV2aWQ9MHgwMwoJ YnVzPTAsIHNsb3Q9MzEsIGZ1bmM9NQoJY2xhc3M9MDQtMDEtMDAsIGhkcnR5cGU9MHgwMCwgbWZk ZXY9MAoJY21kcmVnPTB4MDAwNywgc3RhdHJlZz0weDAyOTAsIGNhY2hlbG5zej0wIChkd29yZHMp CglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAo MCBucykKCWludHBpbj1iLCBpcnE9MTAKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3Vy cmVudCBEMAoJbWFwWzEwXTogdHlwZSA0LCByYW5nZSAzMiwgYmFzZSAwMDAwMjQwMCwgc2l6ZSAg OCwgZW5hYmxlZAoJbWFwWzE0XTogdHlwZSA0LCByYW5nZSAzMiwgYmFzZSAwMDAwMjAwMCwgc2l6 ZSAgNywgZW5hYmxlZApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4zMS5JTlRCIChzcmMgXFxf U0JfLlBDSTAuTFBDMC5MTktCKQpwY2liMDogc2xvdCAzMSBJTlRCIGlzIGFscmVhZHkgcm91dGVk IHRvIGlycSAxMApmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI0YzYsIHJldmlkPTB4MDMK CWJ1cz0wLCBzbG90PTMxLCBmdW5jPTYKCWNsYXNzPTA3LTAzLTAwLCBoZHJ0eXBlPTB4MDAsIG1m ZGV2PTAKCWNtZHJlZz0weDAwMDUsIHN0YXRyZWc9MHgwMjkwLCBjYWNoZWxuc3o9MCAoZHdvcmRz KQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAg KDAgbnMpCglpbnRwaW49YiwgaXJxPTEwCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1 cnJlbnQgRDAKYWdwMDogPEludGVsIEdlbmVyaWMgaG9zdCB0byBQQ0kgYnJpZGdlPiBtZW0gMHhl MDAwMDAwMC0weGVmZmZmZmZmIGF0IGRldmljZSAwLjAgb24gcGNpMAphZ3AwOiBSZXNlcnZlZCAw eDEwMDAwMDAwIGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDMgYXQgMHhlMDAwMDAwMAphZ3AwOiBh bGxvY2F0aW5nIEdBVFQgZm9yIGFwZXJ0dXJlIG9mIHNpemUgMTk2TQpwY2kwOiA8YmFzZSBwZXJp cGhlcmFsPiBhdCBkZXZpY2UgMC4xIChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaTA6IDxiYXNlIHBl cmlwaGVyYWw+IGF0IGRldmljZSAwLjMgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpYjE6IDxBQ1BJ IFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMS4wIG9uIHBjaTAKcGNpYjE6ICAgc2Vjb25kYXJ5 IGJ1cyAgICAgMQpwY2liMTogICBzdWJvcmRpbmF0ZSBidXMgICAxCnBjaWIxOiAgIEkvTyBkZWNv ZGUgICAgICAgIDB4MzAwMC0weDNmZmYKcGNpYjE6ICAgbWVtb3J5IGRlY29kZSAgICAgMHhkMDEw MDAwMC0weGQwMWZmZmZmCnBjaWIxOiAgIHByZWZldGNoZWQgZGVjb2RlIDB4ZDgwMDAwMDAtMHhk ZmZmZmZmZgpBQ1BJIFBDSSBsaW5rIGluaXRpYWwgY29uZmlndXJhdGlvbjoKXFxfU0JfLlBDSTAu TFBDMC5MTktBIGlycSogNjogWyA2XSAgNisgbG93LGxldmVsLHNoYXJhYmxlIDEuMC4wCnBjaTE6 IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIxCnBjaTE6IHBoeXNpY2FsIGJ1cz0xCgltYXBbMTBdOiB0 eXBlIDMsIHJhbmdlIDMyLCBiYXNlIGQ4MDAwMDAwLCBzaXplIDI3LCBlbmFibGVkCnBjaWIxOiBk ZXZpY2UgKG51bGwpIHJlcXVlc3RlZCBkZWNvZGVkIG1lbW9yeSByYW5nZSAweGQ4MDAwMDAwLTB4 ZGZmZmZmZmYKCW1hcFsxNF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMDMwMDAsIHNpemUg IDgsIGVuYWJsZWQKcGNpYjE6IGRldmljZSAobnVsbCkgcmVxdWVzdGVkIGRlY29kZWQgSS9PIHJh bmdlIDB4MzAwMC0weDMwZmYKCW1hcFsxOF06IHR5cGUgMSwgcmFuZ2UgMzIsIGJhc2UgZDAxMDAw MDAsIHNpemUgMTYsIGVuYWJsZWQKcGNpYjE6IGRldmljZSAobnVsbCkgcmVxdWVzdGVkIGRlY29k ZWQgbWVtb3J5IHJhbmdlIDB4ZDAxMDAwMDAtMHhkMDEwZmZmZgpwY2liMTogbWF0Y2hlZCBlbnRy eSBmb3IgMS4wLklOVEEgKHNyYyBcXF9TQl8uUENJMC5MUEMwLkxOS0EpCnBjaWIxOiBzbG90IDAg SU5UQSBpcyBhbHJlYWR5IHJvdXRlZCB0byBpcnEgNgpmb3VuZC0+CXZlbmRvcj0weDEwMDIsIGRl dj0weDRlNTAsIHJldmlkPTB4MDAKCWJ1cz0xLCBzbG90PTAsIGZ1bmM9MAoJY2xhc3M9MDMtMDAt MDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDMwNywgc3RhdHJlZz0weDAyYjAs IGNhY2hlbG5zej04IChkd29yZHMpCglsYXR0aW1lcj0weDQyICgxOTgwIG5zKSwgbWluZ250PTB4 MDggKDIwMDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9NgoJcG93ZXJz cGVjIDIgIHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50IEQwCnBjaTE6IDxkaXNwbGF5LCBW R0E+IGF0IGRldmljZSAwLjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKdWhjaTA6IDxJbnRlbCA4Mjgw MURCIChJQ0g0KSBVU0IgY29udHJvbGxlciBVU0ItQT4gcG9ydCAweDE4MDAtMHgxODFmIGlycSA2 IGF0IGRldmljZSAyOS4wIG9uIHBjaTAKdWhjaTA6IFJlc2VydmVkIDB4MjAgYnl0ZXMgZm9yIHJp ZCAweDIwIHR5cGUgNCBhdCAweDE4MDAKdWhjaTA6IFtHSUFOVC1MT0NLRURdCnVzYjA6IDxJbnRl bCA4MjgwMURCIChJQ0g0KSBVU0IgY29udHJvbGxlciBVU0ItQT4gb24gdWhjaTAKdXNiMDogVVNC IHJldmlzaW9uIDEuMAp1aHViMDogSW50ZWwgVUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYg MS4wMC8xLjAwLCBhZGRyIDEKdWh1YjA6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBw b3dlcmVkCnVoY2kxOiA8SW50ZWwgODI4MDFEQiAoSUNINCkgVVNCIGNvbnRyb2xsZXIgVVNCLUI+ IHBvcnQgMHgxODIwLTB4MTgzZiBpcnEgNiBhdCBkZXZpY2UgMjkuMSBvbiBwY2kwCnVoY2kxOiBS ZXNlcnZlZCAweDIwIGJ5dGVzIGZvciByaWQgMHgyMCB0eXBlIDQgYXQgMHgxODIwCnVoY2kxOiBb R0lBTlQtTE9DS0VEXQp1c2IxOiA8SW50ZWwgODI4MDFEQiAoSUNINCkgVVNCIGNvbnRyb2xsZXIg VVNCLUI+IG9uIHVoY2kxCnVzYjE6IFVTQiByZXZpc2lvbiAxLjAKdWh1YjE6IEludGVsIFVIQ0kg cm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxCnVodWIxOiAyIHBvcnRz IHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aGNpMjogPEludGVsIDgyODAxREIgKElD SDQpIFVTQiBjb250cm9sbGVyIFVTQi1DPiBwb3J0IDB4MTg0MC0weDE4NWYgaXJxIDYgYXQgZGV2 aWNlIDI5LjIgb24gcGNpMAp1aGNpMjogUmVzZXJ2ZWQgMHgyMCBieXRlcyBmb3IgcmlkIDB4MjAg dHlwZSA0IGF0IDB4MTg0MAp1aGNpMjogW0dJQU5ULUxPQ0tFRF0KdXNiMjogPEludGVsIDgyODAx REIgKElDSDQpIFVTQiBjb250cm9sbGVyIFVTQi1DPiBvbiB1aGNpMgp1c2IyOiBVU0IgcmV2aXNp b24gMS4wCnVodWIyOiBJbnRlbCBVSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEu MDAsIGFkZHIgMQp1aHViMjogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQK cGNpMDogPHNlcmlhbCBidXMsIFVTQj4gYXQgZGV2aWNlIDI5LjcgKG5vIGRyaXZlciBhdHRhY2hl ZCkKcGNpYjI6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMzAuMCBvbiBwY2kwCnBj aWIyOiAgIHNlY29uZGFyeSBidXMgICAgIDIKcGNpYjI6ICAgc3Vib3JkaW5hdGUgYnVzICAgMgpw Y2liMjogICBJL08gZGVjb2RlICAgICAgICAweDQwMDAtMHg0ZmZmCnBjaWIyOiAgIG1lbW9yeSBk ZWNvZGUgICAgIDB4ZDAyMDAwMDAtMHhkMDVmZmZmZgpwY2liMjogICBwcmVmZXRjaGVkIGRlY29k ZSAweGZmZjAwMDAwLTB4ZmZmZmYKcGNpYjI6ICAgU3VidHJhY3RpdmVseSBkZWNvZGVkIGJyaWRn ZS4KQUNQSSBQQ0kgbGluayBpbml0aWFsIGNvbmZpZ3VyYXRpb246ClxcX1NCXy5QQ0kwLkxQQzAu TE5LRCBpcnEqIDY6IFsgNl0gIDYrIGxvdyxsZXZlbCxzaGFyYWJsZSAyLjIuMApcXF9TQl8uUENJ MC5MUEMwLkxOS0IgaXJxKjEwOiBbMTBdIDEwKyBsb3csbGV2ZWwsc2hhcmFibGUgMi40LjAKXFxf U0JfLlBDSTAuTFBDMC5MTktDIGlycSogNjogWyA2XSAgNisgbG93LGxldmVsLHNoYXJhYmxlIDIu NC4xClxcX1NCXy5QQ0kwLkxQQzAuTE5LRSBpcnEgIDA6IFsxMF0gMTArIGxvdyxsZXZlbCxzaGFy YWJsZSAyLjYuMApcXF9TQl8uUENJMC5MUEMwLkxOS0YgaXJxICAwOiBbMTBdICAwKyBsb3csbGV2 ZWwsc2hhcmFibGUgMi42LjEKXFxfU0JfLlBDSTAuTFBDMC5MTktHIGlycSAgMDogWyA2XSAgMCsg bG93LGxldmVsLHNoYXJhYmxlIDIuNi4yCnBjaTI6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIyCnBj aTI6IHBoeXNpY2FsIGJ1cz0yCgltYXBbMTBdOiB0eXBlIDEsIHJhbmdlIDMyLCBiYXNlIGQwMjA0 MDAwLCBzaXplIDEzLCBlbmFibGVkCnBjaWIyOiBkZXZpY2UgKG51bGwpIHJlcXVlc3RlZCBkZWNv ZGVkIG1lbW9yeSByYW5nZSAweGQwMjA0MDAwLTB4ZDAyMDVmZmYKcGNpYjI6IG1hdGNoZWQgZW50 cnkgZm9yIDIuMi5JTlRBIChzcmMgXFxfU0JfLlBDSTAuTFBDMC5MTktEKQpwY2liMjogc2xvdCAy IElOVEEgaXMgYWxyZWFkeSByb3V0ZWQgdG8gaXJxIDYKZm91bmQtPgl2ZW5kb3I9MHgxNGU0LCBk ZXY9MHg0NDAxLCByZXZpZD0weDAxCglidXM9Miwgc2xvdD0yLCBmdW5jPTAKCWNsYXNzPTAyLTAw LTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAxMDYsIHN0YXRyZWc9MHgwODEw LCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHg0MCAoMTkyMCBucyksIG1pbmdudD0w eDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTYKCXBvd2Vyc3Bl YyAyICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMAoJbWFwWzEwXTogdHlwZSAxLCBy YW5nZSAzMiwgYmFzZSBkMDIwODAwMCwgc2l6ZSAxMiwgZW5hYmxlZApwY2liMjogZGV2aWNlIChu dWxsKSByZXF1ZXN0ZWQgZGVjb2RlZCBtZW1vcnkgcmFuZ2UgMHhkMDIwODAwMC0weGQwMjA4ZmZm CnBjaWIyOiBtYXRjaGVkIGVudHJ5IGZvciAyLjQuSU5UQSAoc3JjIFxcX1NCXy5QQ0kwLkxQQzAu TE5LQikKcGNpYjI6IHNsb3QgNCBJTlRBIGlzIGFscmVhZHkgcm91dGVkIHRvIGlycSAxMApmb3Vu ZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDQyMjAsIHJldmlkPTB4MDUKCWJ1cz0yLCBzbG90PTQs IGZ1bmM9MAoJY2xhc3M9MDItODAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4 MDExNiwgc3RhdHJlZz0weDAyOTAsIGNhY2hlbG5zej04IChkd29yZHMpCglsYXR0aW1lcj0weDQw ICgxOTIwIG5zKSwgbWluZ250PTB4MDMgKDc1MCBucyksIG1heGxhdD0weDE4ICg2MDAwIG5zKQoJ aW50cGluPWEsIGlycT0xMAoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQw CgltYXBbMTBdOiB0eXBlIDEsIHJhbmdlIDMyLCBiYXNlIGQwMjA5MDAwLCBzaXplIDEyLCBtZW1v cnkgZGlzYWJsZWQKcGNpYjI6IGRldmljZSAobnVsbCkgcmVxdWVzdGVkIGRlY29kZWQgbWVtb3J5 IHJhbmdlIDB4ZDAyMDkwMDAtMHhkMDIwOWZmZgpwY2liMjogbWF0Y2hlZCBlbnRyeSBmb3IgMi42 LklOVEEgKHNyYyBcXF9TQl8uUENJMC5MUEMwLkxOS0UpCnBjaWIyOiBwb3NzaWJsZSBpbnRlcnJ1 cHRzOiAxMApBQ1BJIFBDSSBsaW5rIGFyYml0cmF0ZWQgc2V0dGluZ3M6ClxcX1NCXy5QQ0kwLkxQ QzAuTE5LRyAocmVmZXJlbmNlcyAxLCBwcmlvcml0eSA1MzYwKToKCWludGVycnVwdHM6CSAgICAg NgoJcGVuYWx0eToJICA1MzYwClxcX1NCXy5QQ0kwLkxQQzAuTE5LRSAocmVmZXJlbmNlcyAxLCBw cmlvcml0eSAxODApOgoJaW50ZXJydXB0czoJICAgIDEwCglwZW5hbHR5OgkgICAxODAKXFxfU0Jf LlBDSTAuTFBDMC5MTktGIChyZWZlcmVuY2VzIDEsIHByaW9yaXR5IDE4MCk6CglpbnRlcnJ1cHRz OgkgICAgMTAKCXBlbmFsdHk6CSAgIDE4MApwY2liMjogc2xvdCA2IElOVEEgcm91dGVkIHRvIGly cSAxMCB2aWEgXFxfU0JfLlBDSTAuTFBDMC5MTktFCmZvdW5kLT4JdmVuZG9yPTB4MTA0YywgZGV2 PTB4ODAzMSwgcmV2aWQ9MHgwMAoJYnVzPTIsIHNsb3Q9NiwgZnVuYz0wCgljbGFzcz0wNi0wNy0w MCwgaGRydHlwZT0weDAyLCBtZmRldj0xCgljbWRyZWc9MHgwMTA0LCBzdGF0cmVnPTB4MDIxMCwg Y2FjaGVsbnN6PTggKGR3b3JkcykKCWxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5nbnQ9MHg0 MCAoMTYwMDAgbnMpLCBtYXhsYXQ9MHgwMyAoNzUwIG5zKQoJaW50cGluPWEsIGlycT0xMAoJcG93 ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50IEQwCgltYXBbMTBdOiB0eXBl IDEsIHJhbmdlIDMyLCBiYXNlIGQwMjBhMDAwLCBzaXplIDExLCBlbmFibGVkCnBjaWIyOiBkZXZp Y2UgKG51bGwpIHJlcXVlc3RlZCBkZWNvZGVkIG1lbW9yeSByYW5nZSAweGQwMjBhMDAwLTB4ZDAy MGE3ZmYKCW1hcFsxNF06IHR5cGUgMSwgcmFuZ2UgMzIsIGJhc2UgZDAyMDAwMDAsIHNpemUgMTQs IGVuYWJsZWQKcGNpYjI6IGRldmljZSAobnVsbCkgcmVxdWVzdGVkIGRlY29kZWQgbWVtb3J5IHJh bmdlIDB4ZDAyMDAwMDAtMHhkMDIwM2ZmZgpwY2liMjogbWF0Y2hlZCBlbnRyeSBmb3IgMi42LklO VEEgKHNyYyBcXF9TQl8uUENJMC5MUEMwLkxOS0UpCnBjaWIyOiBzbG90IDYgSU5UQSBpcyBhbHJl YWR5IHJvdXRlZCB0byBpcnEgMTAKZm91bmQtPgl2ZW5kb3I9MHgxMDRjLCBkZXY9MHg4MDMyLCBy ZXZpZD0weDAwCglidXM9Miwgc2xvdD02LCBmdW5jPTIKCWNsYXNzPTBjLTAwLTEwLCBoZHJ0eXBl PTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAxMTYsIHN0YXRyZWc9MHgwMjEwLCBjYWNoZWxuc3o9 OCAoZHdvcmRzKQoJbGF0dGltZXI9MHg0MCAoMTkyMCBucyksIG1pbmdudD0weDAzICg3NTAgbnMp LCBtYXhsYXQ9MHgwNCAoMTAwMCBucykKCWludHBpbj1hLCBpcnE9MTAKCXBvd2Vyc3BlYyAyICBz dXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMAoJbWFwWzEwXTogdHlwZSAxLCByYW5nZSAz MiwgYmFzZSBkMDIwNjAwMCwgc2l6ZSAxMywgZW5hYmxlZApwY2liMjogZGV2aWNlIChudWxsKSBy ZXF1ZXN0ZWQgZGVjb2RlZCBtZW1vcnkgcmFuZ2UgMHhkMDIwNjAwMC0weGQwMjA3ZmZmCnBjaWIy OiBtYXRjaGVkIGVudHJ5IGZvciAyLjYuSU5UQSAoc3JjIFxcX1NCXy5QQ0kwLkxQQzAuTE5LRSkK cGNpYjI6IHNsb3QgNiBJTlRBIGlzIGFscmVhZHkgcm91dGVkIHRvIGlycSAxMApmb3VuZC0+CXZl bmRvcj0weDEwNGMsIGRldj0weDgwMzMsIHJldmlkPTB4MDAKCWJ1cz0yLCBzbG90PTYsIGZ1bmM9 MwoJY2xhc3M9MDEtODAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDEwNiwg c3RhdHJlZz0weDAyMTAsIGNhY2hlbG5zej04IChkd29yZHMpCglsYXR0aW1lcj0weDQwICgxOTIw IG5zKSwgbWluZ250PTB4MDcgKDE3NTAgbnMpLCBtYXhsYXQ9MHgwNCAoMTAwMCBucykKCWludHBp bj1hLCBpcnE9MTAKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBE MApiZmUwOiA8QnJvYWRjb20gQkNNNDQwMSBGYXN0IEV0aGVybmV0PiBtZW0gMHhkMDIwNDAwMC0w eGQwMjA1ZmZmIGlycSA2IGF0IGRldmljZSAyLjAgb24gcGNpMgpiZmUwOiBSZXNlcnZlZCAweDIw MDAgYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgMyBhdCAweGQwMjA0MDAwCm1paWJ1czA6IDxNSUkg YnVzPiBvbiBiZmUwCmJtdHBoeTA6IDxCQ000NDAxIDEwLzEwMGJhc2VUWCBQSFk+IG9uIG1paWJ1 czAKYm10cGh5MDogIDEwYmFzZVQsIDEwYmFzZVQtRkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1G RFgsIGF1dG8KYmZlMDogYnBmIGF0dGFjaGVkCmJmZTA6IEV0aGVybmV0IGFkZHJlc3M6IDAwOmMw OjlmOjZhOjhlOjFjCmJmZTA6IFtHSUFOVC1MT0NLRURdCnBjaTI6IDxuZXR3b3JrPiBhdCBkZXZp Y2UgNC4wIChubyBkcml2ZXIgYXR0YWNoZWQpCmNiYjA6IDxQQ0ktQ2FyZEJ1cyBCcmlkZ2U+IG1l bSAweGQwMjA5MDAwLTB4ZDAyMDlmZmYgaXJxIDEwIGF0IGRldmljZSA2LjAgb24gcGNpMgpjYmIw OiBSZXNlcnZlZCAweDEwMDAgYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgMyBhdCAweGQwMjA5MDAw CmNhcmRidXMwOiA8Q2FyZEJ1cyBidXM+IG9uIGNiYjAKcGNjYXJkMDogPDE2LWJpdCBQQ0NhcmQg YnVzPiBvbiBjYmIwCmNiYjA6IFtNUFNBRkVdCmNiYjA6IFBDSSBDb25maWd1cmF0aW9uIHNwYWNl OgogIDB4MDA6IDB4ODAzMTEwNGMgMHgwMjEwMDEwNyAweDA2MDcwMDAwIDB4MDA4MjQwMDggCiAg MHgxMDogMHhkMDIwOTAwMCAweDAyMDAwMGEwIDB4MjAwMzAzMDIgMHhmZmZmZjAwMCAKICAweDIw OiAweDAwMDAwMDAwIDB4ZmZmZmYwMDAgMHgwMDAwMDAwMCAweGZmZmZmZmZjIAogIDB4MzA6IDB4 MDAwMDAwMDAgMHhmZmZmZmZmYyAweDAwMDAwMDAwIDB4MDc0MDAxMGEgCiAgMHg0MDogMHgwMDY0 MTAyNSAweDAwMDAwMDAxIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAKICAweDUwOiAweDAwMDAwMDAw IDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIAogIDB4NjA6IDB4MDAwMDAwMDAgMHgw MDAwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgCiAgMHg3MDogMHgwMDAwMDAwMCAweDAwMDAw MDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAKICAweDgwOiAweDE4NDQxMDYwIDB4MDJjMDAwMTkg MHgwMDBmMDAwMCAweDAxYTIxYjIyIAogIDB4OTA6IDB4NjA2NDgwYzAgMHgwMDAwMDAwMCAweDAw MDAwMDAwIDB4MDAwMDAwMDAgCiAgMHhhMDogMHhmZTEyMDAwMSAweDAwYzAwMDAwIDB4MDAwMDAw MDAgMHgwMDAwMDAwMCAKICAweGIwOiAweDA4MDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAw eDAwMDAwMDAwIAogIDB4YzA6IDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAw MDAwMDAgCiAgMHhkMDogMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAw MCAKICAweGUwOiAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIAog IDB4ZjA6IDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgCmZ3b2hj aTA6IHZlbmRvcj0xMDRjLCBkZXY9ODAzMgpmd29oY2kwOiA8MTM5NCBPcGVuIEhvc3QgQ29udHJv bGxlciBJbnRlcmZhY2U+IG1lbSAweGQwMjAwMDAwLTB4ZDAyMDNmZmYsMHhkMDIwYTAwMC0weGQw MjBhN2ZmIGlycSAxMCBhdCBkZXZpY2UgNi4yIG9uIHBjaTIKZndvaGNpMDogUmVzZXJ2ZWQgMHg4 MDAgYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgMyBhdCAweGQwMjBhMDAwCmZ3b2hjaTA6IFtHSUFO VC1MT0NLRURdCmZ3b2hjaTA6IE9IQ0kgdmVyc2lvbiAxLjEwIChST009MSkKZndvaGNpMDogTm8u IG9mIElzb2Nocm9ub3VzIGNoYW5uZWxzIGlzIDQuCmZ3b2hjaTA6IEVVSTY0IDAwOmMwOjlmOjAw OjAwOjMyOjE0OmRlCmZ3b2hjaTA6IFBoeSAxMzk0YSBhdmFpbGFibGUgUzQwMCwgMiBwb3J0cy4K ZndvaGNpMDogTGluayBTNDAwLCBtYXhfcmVjIDIwNDggYnl0ZXMuCmZpcmV3aXJlMDogPElFRUUx Mzk0KEZpcmVXaXJlKSBidXM+IG9uIGZ3b2hjaTAKZndlMDogPEV0aGVybmV0IG92ZXIgRmlyZVdp cmU+IG9uIGZpcmV3aXJlMAppZl9md2UwOiBGYWtlIEV0aGVybmV0IGFkZHJlc3M6IDAyOmMwOjlm OjMyOjE0OmRlCmZ3ZTA6IGJwZiBhdHRhY2hlZApmd2UwOiBFdGhlcm5ldCBhZGRyZXNzOiAwMjpj MDo5ZjozMjoxNDpkZQpzYnAwOiA8U0JQLTIvU0NTSSBvdmVyIEZpcmVXaXJlPiBvbiBmaXJld2ly ZTAKZndvaGNpMDogSW5pdGlhdGUgYnVzIHJlc2V0CmZ3b2hjaTA6IG5vZGVfaWQ9MHhjMDAwZmZj MCwgZ2VuPTEsIENZQ0xFTUFTVEVSIG1vZGUKZmlyZXdpcmUwOiAxIG5vZGVzLCBtYXhob3AgPD0g MCwgY2FibGUgSVJNID0gMCAobWUpCmZpcmV3aXJlMDogYnVzIG1hbmFnZXIgMCAobWUpCnBjaTI6 IDxtYXNzIHN0b3JhZ2U+IGF0IGRldmljZSA2LjMgKG5vIGRyaXZlciBhdHRhY2hlZCkKaXNhYjA6 IDxQQ0ktSVNBIGJyaWRnZT4gYXQgZGV2aWNlIDMxLjAgb24gcGNpMAppc2EwOiA8SVNBIGJ1cz4g b24gaXNhYjAKYXRhcGNpMDogPEludGVsIElDSDQgVURNQTEwMCBjb250cm9sbGVyPiBwb3J0IDB4 MTg2MC0weDE4NmYsMHgzNzYsMHgxNzAtMHgxNzcsMHgzZjYsMHgxZjAtMHgxZjcgYXQgZGV2aWNl IDMxLjEgb24gcGNpMAphdGFwY2kwOiBSZXNlcnZlZCAweDEwIGJ5dGVzIGZvciByaWQgMHgyMCB0 eXBlIDQgYXQgMHgxODYwCmF0YTA6IGNoYW5uZWwgIzAgb24gYXRhcGNpMAphdGFwY2kwOiBSZXNl cnZlZCAweDggYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgNCBhdCAweDFmMAphdGFwY2kwOiBSZXNl cnZlZCAweDEgYnl0ZXMgZm9yIHJpZCAweDE0IHR5cGUgNCBhdCAweDNmNgphdGEwOiByZXNldCB0 cDEgbWFzaz0wMyBvc3RhdDA9NTAgb3N0YXQxPTAwCmF0YTAtbWFzdGVyOiBzdGF0PTB4NTAgZXJy PTB4MDEgbHNiPTB4MDAgbXNiPTB4MDAKYXRhMC1zbGF2ZTogIHN0YXQ9MHgwMCBlcnI9MHgwMSBs c2I9MHgwMCBtc2I9MHgwMAphdGEwOiByZXNldCB0cDIgc3RhdDA9NTAgc3RhdDE9MDAgZGV2aWNl cz0weDE8QVRBX01BU1RFUj4KYXRhMDogW01QU0FGRV0KYXRhMTogY2hhbm5lbCAjMSBvbiBhdGFw Y2kwCmF0YXBjaTA6IFJlc2VydmVkIDB4OCBieXRlcyBmb3IgcmlkIDB4MTggdHlwZSA0IGF0IDB4 MTcwCmF0YXBjaTA6IFJlc2VydmVkIDB4MSBieXRlcyBmb3IgcmlkIDB4MWMgdHlwZSA0IGF0IDB4 Mzc2CmF0YTE6IHJlc2V0IHRwMSBtYXNrPTAzIG9zdGF0MD01MCBvc3RhdDE9MDAKYXRhMS1tYXN0 ZXI6IHN0YXQ9MHgwMCBlcnI9MHgwMSBsc2I9MHgxNCBtc2I9MHhlYgphdGExLXNsYXZlOiAgc3Rh dD0weDAwIGVycj0weDAwIGxzYj0weDAwIG1zYj0weDAwCmF0YTE6IHJlc2V0IHRwMiBzdGF0MD0w MCBzdGF0MT0wMCBkZXZpY2VzPTB4NDxBVEFQSV9NQVNURVI+CmF0YTE6IFtNUFNBRkVdCnBjaTA6 IDxzZXJpYWwgYnVzLCBTTUJ1cz4gYXQgZGV2aWNlIDMxLjMgKG5vIGRyaXZlciBhdHRhY2hlZCkK cGNpMDogPG11bHRpbWVkaWEsIGF1ZGlvPiBhdCBkZXZpY2UgMzEuNSAobm8gZHJpdmVyIGF0dGFj aGVkKQpwY2kwOiA8c2ltcGxlIGNvbW1zPiBhdCBkZXZpY2UgMzEuNiAobm8gZHJpdmVyIGF0dGFj aGVkKQphY3BpX2xpZDA6IDxDb250cm9sIE1ldGhvZCBMaWQgU3dpdGNoPiBvbiBhY3BpMAphY3Bp X2J1dHRvbjA6IDxTbGVlcCBCdXR0b24+IG9uIGFjcGkwCnVua25vd246IG5vdCBwcm9iZWQgKGRp c2FibGVkKQphdGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgwNDIpPiBwb3J0IDB4NjQs MHg2MCBpcnEgMSBvbiBhY3BpMAphdGtiZDA6IDxBVCBLZXlib2FyZD4gaXJxIDEgb24gYXRrYmRj MAphdGtiZDogdGhlIGN1cnJlbnQga2JkIGNvbnRyb2xsZXIgY29tbWFuZCBieXRlIDAwNDcKYXRr YmQ6IGtleWJvYXJkIElEIDB4NDFhYiAoMikKa2JkMCBhdCBhdGtiZDAKa2JkMDogYXRrYmQwLCBB VCAxMDEvMTAyICgyKSwgY29uZmlnOjB4MCwgZmxhZ3M6MHgzZDAwMDAKYXRrYmQwOiBbR0lBTlQt TE9DS0VEXQpwc20wOiB1bmFibGUgdG8gYWxsb2NhdGUgSVJRCnVua25vd246IG5vdCBwcm9iZWQg KGRpc2FibGVkKQpwc21jcG5wMDogPFBTLzIgbW91c2UgcG9ydD4gaXJxIDEyIG9uIGFjcGkwCnBz bTA6IGN1cnJlbnQgY29tbWFuZCBieXRlOjAwNDcKcHNtMDogPFBTLzIgTW91c2U+IGlycSAxMiBv biBhdGtiZGMwCnBzbTA6IFtHSUFOVC1MT0NLRURdCnBzbTA6IG1vZGVsIEdlbmVyaWMgUFMvMiBt b3VzZSwgZGV2aWNlIElEIDAtMDAsIDIgYnV0dG9ucwpwc20wOiBjb25maWc6MDAwMDAwMDAsIGZs YWdzOjAwMDAwMDA4LCBwYWNrZXQgc2l6ZTozCnBzbTA6IHN5bmNtYXNrOmMwLCBzeW5jYml0czow MAp1bmtub3duOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKdW5rbm93bjogbm90IHByb2JlZCAoZGlz YWJsZWQpCnVua25vd246IG5vdCBwcm9iZWQgKGRpc2FibGVkKQp1bmtub3duOiBub3QgcHJvYmVk IChkaXNhYmxlZCkKdW5rbm93bjogbm90IHByb2JlZCAoZGlzYWJsZWQpCnNpbzA6IGlycSBtYXBz OiAweDYwMSAweDYwOSAweDYwMSAweDYwMQpzaW8wIHBvcnQgMHgyZjgtMHgyZmYgaXJxIDMgZHJx IDEgZmxhZ3MgMHgxMCBvbiBhY3BpMApzaW8wOiB0eXBlIDE2NTUwQQp1bmtub3duOiBub3QgcHJv YmVkIChkaXNhYmxlZCkKdW5rbm93bjogbm90IHByb2JlZCAoZGlzYWJsZWQpCnVua25vd246IG5v dCBwcm9iZWQgKGRpc2FibGVkKQp1bmtub3duOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKdW5rbm93 bjogbm90IHByb2JlZCAoZGlzYWJsZWQpCnVua25vd246IG5vdCBwcm9iZWQgKGRpc2FibGVkKQp1 bmtub3duOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKbnB4MDogW0ZBU1RdCm5weDA6IDxtYXRoIHBy b2Nlc3Nvcj4gb24gbW90aGVyYm9hcmQKbnB4MDogSU5UIDE2IGludGVyZmFjZQphdGE6IGF0YTAg YWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0CmF0YTogYXRhMSBhbHJlYWR5IGV4aXN0czsgc2tp cHBpbmcgaXQKYXRrYmRjOiBhdGtiZGMwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdApzaW86 IHNpbzAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0ClRyeWluZyBSZWFkX1BvcnQgYXQgMjAz ClRyeWluZyBSZWFkX1BvcnQgYXQgMjQzClRyeWluZyBSZWFkX1BvcnQgYXQgMjgzClRyeWluZyBS ZWFkX1BvcnQgYXQgMmMzClRyeWluZyBSZWFkX1BvcnQgYXQgMzAzClRyeWluZyBSZWFkX1BvcnQg YXQgMzQzClRyeWluZyBSZWFkX1BvcnQgYXQgMzgzClRyeWluZyBSZWFkX1BvcnQgYXQgM2MzCmV4 X2lzYV9pZGVudGlmeSgpCnVua25vd246IHN0YXR1cyByZWcgdGVzdCBmYWlsZWQgZmYKdW5rbm93 bjogc3RhdHVzIHJlZyB0ZXN0IGZhaWxlZCBmZgp1bmtub3duOiBzdGF0dXMgcmVnIHRlc3QgZmFp bGVkIGZmCnVua25vd246IHN0YXR1cyByZWcgdGVzdCBmYWlsZWQgZmYKdW5rbm93bjogc3RhdHVz IHJlZyB0ZXN0IGZhaWxlZCBmZgp1bmtub3duOiBzdGF0dXMgcmVnIHRlc3QgZmFpbGVkIGZmCmFo Y19pc2FfcHJvYmUgMTogaW9wb3J0IDB4MWMwMCBhbGxvYyBmYWlsZWQKc2M6IHNjMCBhbHJlYWR5 IGV4aXN0czsgc2tpcHBpbmcgaXQKdmdhOiB2Z2EwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBp dAppc2FfcHJvYmVfY2hpbGRyZW46IGRpc2FibGluZyBQblAgZGV2aWNlcwppc2FfcHJvYmVfY2hp bGRyZW46IHByb2Jpbmcgbm9uLVBuUCBkZXZpY2VzCm9ybTA6IDxJU0EgT3B0aW9uIFJPTXM+IGF0 IGlvbWVtIDB4ZTAwMDAtMHhlM2ZmZiwweGRmODAwLTB4ZGZmZmYsMHhkMDAwMC0weGQxN2ZmLDB4 YzAwMDAtMHhjZmZmZiBvbiBpc2EwCnBtdGltZXIwIG9uIGlzYTAKYWR2MDogbm90IHByb2JlZCAo ZGlzYWJsZWQpCmFoYTA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQphaWMwOiBub3QgcHJvYmVkIChk aXNhYmxlZCkKYnQwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKY3MwOiBub3QgcHJvYmVkIChkaXNh YmxlZCkKZWQwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKZmRjMCBmYWlsZWQgdG8gcHJvYmUgYXQg cG9ydCAweDNmMC0weDNmNSBpcnEgNiBkcnEgMiBvbiBpc2EwCmZlMDogbm90IHByb2JlZCAoZGlz YWJsZWQpCmllMDogbm90IHByb2JlZCAoZGlzYWJsZWQpCmxuYzA6IG5vdCBwcm9iZWQgKGRpc2Fi bGVkKQpwY2ljMCBmYWlsZWQgdG8gcHJvYmUgYXQgcG9ydCAweDNlMCBpb21lbSAweGQwMDAwIG9u IGlzYTAKcGNpYzE6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQpwcGMwOiBwYXJhbGxlbCBwb3J0IG5v dCBmb3VuZC4KcHBjMDogPFBhcmFsbGVsIHBvcnQ+IGZhaWxlZCB0byBwcm9iZSBhdCBpcnEgNyBv biBpc2EwCnNjMDogPFN5c3RlbSBjb25zb2xlPiBhdCBmbGFncyAweDEwMCBvbiBpc2EwCnNjMDog VkdBIDwxNiB2aXJ0dWFsIGNvbnNvbGVzLCBmbGFncz0weDMwMD4Kc2MwOiBmYjAsIGtiZDAsIHRl cm1pbmFsIGVtdWxhdG9yOiBzYyAoc3lzY29ucyB0ZXJtaW5hbCkKc2lvMSBmYWlsZWQgdG8gcHJv YmUgYXQgcG9ydCAweDJmOCBpcnEgMyBvbiBpc2EwCnNpbzI6IG5vdCBwcm9iZWQgKGRpc2FibGVk KQpzaW8zOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKc24wOiBub3QgcHJvYmVkIChkaXNhYmxlZCkK dmdhMDogPEdlbmVyaWMgSVNBIFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBpb21lbSAweGEwMDAw LTB4YmZmZmYgb24gaXNhMApmYjA6IHZnYTAsIHZnYSwgdHlwZTpWR0EgKDUpLCBmbGFnczoweDcw MDdmCmZiMDogcG9ydDoweDNjMC0weDNkZiwgY3J0YzoweDNkNCwgbWVtOjB4YTAwMDAgMHgyMDAw MApmYjA6IGluaXQgbW9kZToyNCwgYmlvcyBtb2RlOjMsIGN1cnJlbnQgbW9kZToyNApmYjA6IHdp bmRvdzoweGMwMGI4MDAwIHNpemU6MzJrIGdyYW46MzJrLCBidWY6MCBzaXplOjMyawp2Z2EwOiB2 Z2E6IFdBUk5JTkc6IHZpZGVvIG1vZGUgc3dpdGNoaW5nIGlzIG5vdCBmdWxseSBzdXBwb3J0ZWQg b24gdGhpcyBhZGFwdGVyClZHQSBwYXJhbWV0ZXJzIHVwb24gcG93ZXItdXAKNTAgMTggMTAgMDAg MDAgMDAgMDMgMDAgMDIgNjcgNWIgNGYgNGYgOWYgNTIgMTYgCjllIDFmIDAwIDRmIDBkIDBlIDAw IDAwIDA3IDgwIDkzIDg3IDhmIDI4IDFmIDhmIAo5ZiBhMyBmZiAwMCAwMSAwMiAwMyAwNCAwNSAx NCAwNyAzOCAzOSAzYSAzYiAzYyAKM2QgM2UgM2YgMGMgMDAgMGYgMDggMDAgMDAgMDAgMDAgMDAg MTAgMGUgMDAgZmYgClZHQSBwYXJhbWV0ZXJzIGluIEJJT1MgZm9yIG1vZGUgMjQKNTAgMTggMTAg MDAgMTAgMDAgMDMgMDAgMDIgNjcgNWYgNGYgNTAgODIgNTUgODEgCmJmIDFmIDAwIDRmIDBkIDBl IDAwIDAwIDAwIDAwIDljIDhlIDhmIDI4IDFmIDk2IApiOSBhMyBmZiAwMCAwMSAwMiAwMyAwNCAw NSAxNCAwNyAzOCAzOSAzYSAzYiAzYyAKM2QgM2UgM2YgMGMgMDAgMGYgMDggMDAgMDAgMDAgMDAg MDAgMTAgMGUgMDAgZmYgCkVHQS9WR0EgcGFyYW1ldGVycyB0byBiZSB1c2VkIGZvciBtb2RlIDI0 CjUwIDE4IDEwIDAwIDAwIDAwIDAzIDAwIDAyIDY3IDViIDRmIDRmIDlmIDUyIDE2IAo5ZSAxZiAw MCA0ZiAwZCAwZSAwMCAwMCAwNyA4MCA5MyA4NyA4ZiAyOCAxZiA4ZiAKOWYgYTMgZmYgMDAgMDEg MDIgMDMgMDQgMDUgMTQgMDcgMzggMzkgM2EgM2IgM2MgCjNkIDNlIDNmIDBjIDAwIDBmIDA4IDAw IDAwIDAwIDAwIDAwIDEwIDBlIDAwIGZmIAp2dDA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQppc2Ff cHJvYmVfY2hpbGRyZW46IHByb2JpbmcgUG5QIGRldmljZXMKRGV2aWNlIGNvbmZpZ3VyYXRpb24g ZmluaXNoZWQuCnByb2NmcyByZWdpc3RlcmVkClRpbWVjb3VudGVyICJUU0MiIGZyZXF1ZW5jeSAx NTk4NjUwMDU5IEh6IHF1YWxpdHkgODAwClRpbWVjb3VudGVycyB0aWNrIGV2ZXJ5IDEwLjAwMCBt c2VjCldBUk5JTkc6IGFwbV9zYXZlciBtb2R1bGUgcmVxdWlyZXMgYXBtIGVuYWJsZWQKc3BsYXNo OiBpbWFnZSBkZWNvZGVyIGZvdW5kOiBhcG1fc2F2ZXIKSVBzZWM6IEluaXRpYWxpemVkIFNlY3Vy aXR5IEFzc29jaWF0aW9uIFByb2Nlc3NpbmcuCnBmbG9nMDogYnBmIGF0dGFjaGVkCmxvMDogYnBm IGF0dGFjaGVkCmNwdTA6IHNldCBzcGVlZCB0byAxMDAuMCUKYWNwaV9jcHU6IHRocm90dGxpbmcg ZW5hYmxlZCwgOCBzdGVwcyAoMTAwJSB0byAxMi41JSksIGN1cnJlbnRseSAxMDAuMCUKYXRhMC1t YXN0ZXI6IHBpbz0weDBjIHdkbWE9MHgyMiB1ZG1hPTB4NDUgY2FibGU9ODBwaW4KYXRhMC1tYXN0 ZXI6IHNldHRpbmcgUElPNCBvbiBJbnRlbCBJQ0g0IGNoaXAKYXRhMC1tYXN0ZXI6IHNldHRpbmcg VURNQTEwMCBvbiBJbnRlbCBJQ0g0IGNoaXAKYWQwOiA8VE9TSElCQSBNSzYwMjVHQVMvS0EyMDBB PiBBVEEtNiBkaXNrIGF0IGF0YTAtbWFzdGVyCmFkMDogNTcyMzFNQiAoMTE3MjEwMjQwIHNlY3Rv cnMpLCAxMTYyODAgQywgMTYgSCwgNjMgUywgNTEyIEIKYWQwOiAxNiBzZWNzL2ludCwgMSBkZXB0 aCBxdWV1ZSwgVURNQTEwMApHRU9NOiBuZXcgZGlzayBhZDAKYXI6IEZyZWVCU0QgY2hlY2sxIGZh aWxlZAphdGExLW1hc3RlcjogcGlvPTB4MGMgd2RtYT0weDIyIHVkbWE9MHg0MiBjYWJsZT00MHBp bgphdGExLW1hc3Rlcjogc2V0dGluZyBQSU80IG9uIEludGVsIElDSDQgY2hpcAphdGExLW1hc3Rl cjogc2V0dGluZyBVRE1BMzMgb24gSW50ZWwgSUNINCBjaGlwCmFjZDA6IDxTbGltdHlwZSBEVkRS VyBTT1NXLTg1MlMvUFJTOT4gRFZEUiBkcml2ZSBhdCBhdGExIGFzIG1hc3RlcgphY2QwOiByZWFk IDQxMzRLQi9zICg0MTM0S0Ivcykgd3JpdGUgNDEzNEtCL3MgKDQxMzRLQi9zKSwgMjA0OEtCIGJ1 ZmZlciwgVURNQTMzCmFjZDA6IFJlYWRzOiBDRFIsIENEUlcsIENEREEgc3RyZWFtLCBEVkRST00s IERWRFIsIHBhY2tldAphY2QwOiBXcml0ZXM6IENEUiwgQ0RSVywgRFZEUiwgdGVzdCB3cml0ZSwg YnVybnByb29mCmFjZDA6IEF1ZGlvOiBwbGF5LCAyNTYgdm9sdW1lIGxldmVscwphY2QwOiBNZWNo YW5pc206IGVqZWN0YWJsZSB0cmF5LCB1bmxvY2tlZAphY2QwOiBNZWRpdW06IG5vL2JsYW5rIGRp c2MKWzBdIGY6MDAgdHlwOjE4IHMoQ0hTKTowLzEvMSBlKENIUyk6MzgyLzI1NC82MyBzOjYzIGw6 NjE1MjgzMgpbMV0gZjowMCB0eXA6NiBzKENIUyk6MzgzLzAvMSBlKENIUyk6MTAyMy8yNTQvNjMg czo2MTUyODk1IGw6MzE0NTUyNzAKWzJdIGY6ODAgdHlwOjE2NSBzKENIUyk6MTAyMy8yNTUvNjMg ZShDSFMpOjEwMjMvMjU0LzYzIHM6Mzc2MDgxNjUgbDo3OTYwMjA3NQpbM10gZjowMCB0eXA6MCBz KENIUyk6MC8wLzAgZShDSFMpOjAvMC8wIHM6MCBsOjAKR0VPTTogQ29uZmlndXJlIGFkMHMxLCBz dGFydCAzMjI1NiBsZW5ndGggMzE1MDI0OTk4NCBlbmQgMzE1MDI4MjIzOQpHRU9NOiBDb25maWd1 cmUgYWQwczIsIHN0YXJ0IDMxNTAyODIyNDAgbGVuZ3RoIDE2MTA1MDk4MjQwIGVuZCAxOTI1NTM4 MDQ3OQpHRU9NOiBDb25maWd1cmUgYWQwczMsIHN0YXJ0IDE5MjU1MzgwNDgwIGxlbmd0aCA0MDc1 NjI2MjQwMCBlbmQgNjAwMTE2NDI4NzkKR0VPTTogQ29uZmlndXJlIGFkMHMzYSwgc3RhcnQgMCBs ZW5ndGggMTM0MjE3NzI4IGVuZCAxMzQyMTc3MjcKR0VPTTogQ29uZmlndXJlIGFkMHMzYiwgc3Rh cnQgMTMyMjA0NDYyMDggbGVuZ3RoIDEwNzM3NDE4MjQgZW5kIDE0Mjk0MTg4MDMxCkdFT006IENv bmZpZ3VyZSBhZDBzM2MsIHN0YXJ0IDAgbGVuZ3RoIDQwNzU2MjYyNDAwIGVuZCA0MDc1NjI2MjM5 OQpHRU9NOiBDb25maWd1cmUgYWQwczNkLCBzdGFydCAxMzQyMTc3MjggbGVuZ3RoIDEzNDIxNzcy OCBlbmQgMjY4NDM1NDU1CkdFT006IENvbmZpZ3VyZSBhZDBzM2UsIHN0YXJ0IDI2ODQzNTQ1NiBs ZW5ndGggNjcxMDg4NjQgZW5kIDMzNTU0NDMxOQpHRU9NOiBDb25maWd1cmUgYWQwczNmLCBzdGFy dCAzMzU1NDQzMjAgbGVuZ3RoIDEyODg0OTAxODg4IGVuZCAxMzIyMDQ0NjIwNwpHRU9NOiBDb25m aWd1cmUgYWQwczNnLCBzdGFydCAxNDI5NDE4ODAzMiBsZW5ndGggMjY0NjIwNzQzNjggZW5kIDQw NzU2MjYyMzk5CmFjcGlfZWMwOiBpbmZvOiBuZXcgbWF4IGRlbGF5IGlzIDExMDAwIHVzCihwcm9i ZTU6c2JwMDowOjU6MCk6IGVycm9yIDIyCihwcm9iZTU6c2JwMDowOjU6MCk6IFVucmV0cnlhYmxl IEVycm9yCihwcm9iZTY6c2JwMDowOjY6MCk6IGVycm9yIDIyCihwcm9iZTY6c2JwMDowOjY6MCk6 IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTA6c2JwMDowOjA6MCk6IGVycm9yIDIyCihwcm9iZTA6 c2JwMDowOjA6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTE6c2JwMDowOjE6MCk6IGVycm9y IDIyCihwcm9iZTE6c2JwMDowOjE6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTI6c2JwMDow OjI6MCk6IGVycm9yIDIyCihwcm9iZTI6c2JwMDowOjI6MCk6IFVucmV0cnlhYmxlIEVycm9yCihw cm9iZTM6c2JwMDowOjM6MCk6IGVycm9yIDIyCihwcm9iZTM6c2JwMDowOjM6MCk6IFVucmV0cnlh YmxlIEVycm9yCihwcm9iZTQ6c2JwMDowOjQ6MCk6IGVycm9yIDIyCihwcm9iZTQ6c2JwMDowOjQ6 MCk6IFVucmV0cnlhYmxlIEVycm9yCk1vdW50aW5nIHJvb3QgZnJvbSB1ZnM6L2Rldi9hZDBzM2EK V0FSTklORzogLyB3YXMgbm90IHByb3Blcmx5IGRpc21vdW50ZWQKc3RhcnRfaW5pdDogdHJ5aW5n IC9zYmluL2luaXQKV0FSTklORzogL2hvbWUgd2FzIG5vdCBwcm9wZXJseSBkaXNtb3VudGVkCldB Uk5JTkc6IC90bXAgd2FzIG5vdCBwcm9wZXJseSBkaXNtb3VudGVkCldBUk5JTkc6IC91c3Igd2Fz IG5vdCBwcm9wZXJseSBkaXNtb3VudGVkCldBUk5JTkc6IC92YXIgd2FzIG5vdCBwcm9wZXJseSBk aXNtb3VudGVkCkxpbnV4IEVMRiBleGVjIGhhbmRsZXIgaW5zdGFsbGVkCkVuaGFuY2VkIFNwZWVk c3RlcCBydW5uaW5nIGF0IDE2MDAgTUh6CnBjaTA6IGRyaXZlciBhZGRlZApmb3VuZC0+CXZlbmRv cj0weDgwODYsIGRldj0weDM1ODQsIHJldmlkPTB4MDIKCWJ1cz0wLCBzbG90PTAsIGZ1bmM9MQoJ Y2xhc3M9MDgtODAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNiwgc3Rh dHJlZz0weDAwODAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwg bWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKcGNpMDowOjE6IHJlcHJvYmlu ZyBvbiBkcml2ZXIgYWRkZWQKcGNpMDowOjE6IFRyYW5zaXRpb24gZnJvbSBEMCB0byBEMwpmb3Vu ZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDM1ODUsIHJldmlkPTB4MDIKCWJ1cz0wLCBzbG90PTAs IGZ1bmM9MwoJY2xhc3M9MDgtODAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4 MDAwNiwgc3RhdHJlZz0weDAwODAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAw ICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKcGNpMDowOjM6 IHJlcHJvYmluZyBvbiBkcml2ZXIgYWRkZWQKcGNpMDowOjM6IFRyYW5zaXRpb24gZnJvbSBEMCB0 byBEMwpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI0Y2QsIHJldmlkPTB4MDMKCWJ1cz0w LCBzbG90PTI5LCBmdW5jPTcKCWNsYXNzPTBjLTAzLTIwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAK CWNtZHJlZz0weDAxMDYsIHN0YXRyZWc9MHgwMjkwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0 dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMp CglpbnRwaW49ZCwgaXJxPTEwCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQg RDAKcGNpMDoyOTo3OiByZXByb2Jpbmcgb24gZHJpdmVyIGFkZGVkCnBjaTA6Mjk6NzogVHJhbnNp dGlvbiBmcm9tIEQwIHRvIEQzCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjRjMywgcmV2 aWQ9MHgwMwoJYnVzPTAsIHNsb3Q9MzEsIGZ1bmM9MwoJY2xhc3M9MGMtMDUtMDAsIGhkcnR5cGU9 MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwMSwgc3RhdHJlZz0weDAyODAsIGNhY2hlbG5zej0w IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhs YXQ9MHgwMCAoMCBucykKCWludHBpbj1iLCBpcnE9MTAKcGNpMDozMTozOiByZXByb2Jpbmcgb24g ZHJpdmVyIGFkZGVkCnBjaTA6MzE6MzogVHJhbnNpdGlvbiBmcm9tIEQwIHRvIEQzCmZvdW5kLT4J dmVuZG9yPTB4ODA4NiwgZGV2PTB4MjRjNSwgcmV2aWQ9MHgwMwoJYnVzPTAsIHNsb3Q9MzEsIGZ1 bmM9NQoJY2xhc3M9MDQtMDEtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAw Nywgc3RhdHJlZz0weDAyOTAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgw IG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1iLCBp cnE9MTAKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMApwY2kwOjMxOjU6 IHJlcHJvYmluZyBvbiBkcml2ZXIgYWRkZWQKcGNpMDozMTo1OiBUcmFuc2l0aW9uIGZyb20gRDAg dG8gRDMKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyNGM2LCByZXZpZD0weDAzCglidXM9 MCwgc2xvdD0zMSwgZnVuYz02CgljbGFzcz0wNy0wMy0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0w CgljbWRyZWc9MHgwMDA1LCBzdGF0cmVnPTB4MDI5MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxh dHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5z KQoJaW50cGluPWIsIGlycT0xMAoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50 IEQwCnBjaTA6MzE6NjogcmVwcm9iaW5nIG9uIGRyaXZlciBhZGRlZApwY2kwOjMxOjY6IFRyYW5z aXRpb24gZnJvbSBEMCB0byBEMwpwY2kxOiBkcml2ZXIgYWRkZWQKZm91bmQtPgl2ZW5kb3I9MHgx MDAyLCBkZXY9MHg0ZTUwLCByZXZpZD0weDAwCglidXM9MSwgc2xvdD0wLCBmdW5jPTAKCWNsYXNz PTAzLTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAzMDcsIHN0YXRyZWc9 MHgwMmIwLCBjYWNoZWxuc3o9OCAoZHdvcmRzKQoJbGF0dGltZXI9MHg0MiAoMTk4MCBucyksIG1p bmdudD0weDA4ICgyMDAwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTYK CXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMApwY2kxOjA6MDog cmVwcm9iaW5nIG9uIGRyaXZlciBhZGRlZApwY2kyOiBkcml2ZXIgYWRkZWQKZm91bmQtPgl2ZW5k b3I9MHg4MDg2LCBkZXY9MHg0MjIwLCByZXZpZD0weDA1CglidXM9Miwgc2xvdD00LCBmdW5jPTAK CWNsYXNzPTAyLTgwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAxMTYsIHN0 YXRyZWc9MHgwMjkwLCBjYWNoZWxuc3o9OCAoZHdvcmRzKQoJbGF0dGltZXI9MHg0MCAoMTkyMCBu cyksIG1pbmdudD0weDAzICg3NTAgbnMpLCBtYXhsYXQ9MHgxOCAoNjAwMCBucykKCWludHBpbj1h LCBpcnE9MTAKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMApwY2kyOjQ6 MDogcmVwcm9iaW5nIG9uIGRyaXZlciBhZGRlZAppd2kwOiA8SW50ZWwoUikgUFJPL1dpcmVsZXNz IDIyMDBCRyBNaW5pUENJPiBtZW0gMHhkMDIwODAwMC0weGQwMjA4ZmZmIGlycSAxMCBhdCBkZXZp Y2UgNC4wIG9uIHBjaTIKaXdpMDogUmVzZXJ2ZWQgMHgxMDAwIGJ5dGVzIGZvciByaWQgMHgxMCB0 eXBlIDMgYXQgMHhkMDIwODAwMAppd2kwOiBicGYgYXR0YWNoZWQKaXdpMDogRXRoZXJuZXQgYWRk cmVzczogMDA6MGU6MzU6OGQ6ZGI6ZTMKaXdpMDogYnBmIGF0dGFjaGVkCml3aTA6IDExYiByYXRl czogMU1icHMgMk1icHMgNS41TWJwcyAxMU1icHMKaXdpMDogMTFnIHJhdGVzOiAxTWJwcyAyTWJw cyA1LjVNYnBzIDExTWJwcyA2TWJwcyA5TWJwcyAxMk1icHMgMThNYnBzIDI0TWJwcyAzNk1icHMg NDhNYnBzIDU0TWJwcwppd2kwOiBicGYgYXR0YWNoZWQKaXdpMDogW0dJQU5ULUxPQ0tFRF0KZm91 bmQtPgl2ZW5kb3I9MHgxMDRjLCBkZXY9MHg4MDMzLCByZXZpZD0weDAwCglidXM9Miwgc2xvdD02 LCBmdW5jPTMKCWNsYXNzPTAxLTgwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0w eDAxMDYsIHN0YXRyZWc9MHgwMjEwLCBjYWNoZWxuc3o9OCAoZHdvcmRzKQoJbGF0dGltZXI9MHg0 MCAoMTkyMCBucyksIG1pbmdudD0weDA3ICgxNzUwIG5zKSwgbWF4bGF0PTB4MDQgKDEwMDAgbnMp CglpbnRwaW49YSwgaXJxPTEwCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDEgRDIgRDMgIGN1 cnJlbnQgRDAKcGNpMjo2OjM6IHJlcHJvYmluZyBvbiBkcml2ZXIgYWRkZWQKcGNpMjo2OjM6IFRy YW5zaXRpb24gZnJvbSBEMCB0byBEMwpwY2kwOiBkcml2ZXIgYWRkZWQKZm91bmQtPgl2ZW5kb3I9 MHg4MDg2LCBkZXY9MHgzNTg0LCByZXZpZD0weDAyCglidXM9MCwgc2xvdD0wLCBmdW5jPTEKCWNs YXNzPTA4LTgwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDYsIHN0YXRy ZWc9MHgwMDgwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1p bmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCnBjaTA6MDoxOiByZXByb2Jpbmcg b24gZHJpdmVyIGFkZGVkCnBjaTA6MDoxOiBUcmFuc2l0aW9uIGZyb20gRDAgdG8gRDMKZm91bmQt Pgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgzNTg1LCByZXZpZD0weDAyCglidXM9MCwgc2xvdD0wLCBm dW5jPTMKCWNsYXNzPTA4LTgwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAw MDYsIHN0YXRyZWc9MHgwMDgwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAo MCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCnBjaTA6MDozOiBy ZXByb2Jpbmcgb24gZHJpdmVyIGFkZGVkCnBjaTA6MDozOiBUcmFuc2l0aW9uIGZyb20gRDAgdG8g RDMKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyNGNkLCByZXZpZD0weDAzCglidXM9MCwg c2xvdD0yOSwgZnVuYz03CgljbGFzcz0wYy0wMy0yMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCglj bWRyZWc9MHgwMTA2LCBzdGF0cmVnPTB4MDI5MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRp bWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJ aW50cGluPWQsIGlycT0xMAoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQz CnBjaTA6Mjk6NzogcmVwcm9iaW5nIG9uIGRyaXZlciBhZGRlZApwY2kwOjI5Ojc6IFRyYW5zaXRp b24gZnJvbSBEMyB0byBEMApwY2kwOjI5Ojc6IFRyYW5zaXRpb24gZnJvbSBEMCB0byBEMwpmb3Vu ZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI0YzMsIHJldmlkPTB4MDMKCWJ1cz0wLCBzbG90PTMx LCBmdW5jPTMKCWNsYXNzPTBjLTA1LTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0w eDAwMDEsIHN0YXRyZWc9MHgwMjgwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgw MCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49 YiwgaXJxPTEwCnBjaTA6MzE6MzogcmVwcm9iaW5nIG9uIGRyaXZlciBhZGRlZApwY2kwOjMxOjM6 IFRyYW5zaXRpb24gZnJvbSBEMCB0byBEMwpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI0 YzUsIHJldmlkPTB4MDMKCWJ1cz0wLCBzbG90PTMxLCBmdW5jPTUKCWNsYXNzPTA0LTAxLTAwLCBo ZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMjkwLCBjYWNo ZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5z KSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YiwgaXJxPTEwCglwb3dlcnNwZWMgMiAgc3Vw cG9ydHMgRDAgRDMgIGN1cnJlbnQgRDMKcGNpMDozMTo1OiByZXByb2Jpbmcgb24gZHJpdmVyIGFk ZGVkCnBjaTA6MzE6NTogVHJhbnNpdGlvbiBmcm9tIEQzIHRvIEQwCnBjbTA6IDxJbnRlbCBJQ0g0 ICg4MjgwMURCKT4gcG9ydCAweDE4YzAtMHgxOGZmLDB4MWMwMC0weDFjZmYgbWVtIDB4ZDAwMDA4 MDAtMHhkMDAwMDhmZiwweGQwMDAwYzAwLTB4ZDAwMDBkZmYgaXJxIDEwIGF0IGRldmljZSAzMS41 IG9uIHBjaTAKcGNtMDogUmVzZXJ2ZWQgMHgxMDAgYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgNCBh dCAweDFjMDAKcGNtMDogUmVzZXJ2ZWQgMHg0MCBieXRlcyBmb3IgcmlkIDB4MTQgdHlwZSA0IGF0 IDB4MThjMApwY20wOiBbR0lBTlQtTE9DS0VEXQpwY20wOiA8VW5rbm93biBBQzk3IENvZGVjIChp ZCA9IDB4NDM1ODU0MzApPgpwY20wOiBDb2RlYyBmZWF0dXJlcyByZXNlcnZlZCwgaGVhZHBob25l LCAxOCBiaXQgREFDLCAxOCBiaXQgQURDLCA1IGJpdCBtYXN0ZXIgdm9sdW1lLCBubyAzRCBTdGVy ZW8gRW5oYW5jZW1lbnQKcGNtMDogUHJpbWFyeSBjb2RlYyBleHRlbmRlZCBmZWF0dXJlcyByZXNl cnZlZCAxLCBBTUFQLCByZXNlcnZlZCA1CnBjbTA6IHNuZGJ1Zl9zZXRtYXAgMWYwYjgwMDAsIDQw MDA7IDB4ZTY4N2IwMDAgLT4gMWYwYjgwMDAKcGNtMDogc25kYnVmX3NldG1hcCAxZjBhMzAwMCwg NDAwMDsgMHhlNjg3ZjAwMCAtPiAxZjBhMzAwMApwY20wOiBtZWFzdXJlZCBhYzk3IGxpbmsgcmF0 ZSBhdCA0ODAxMCBIeiwgd2lsbCB1c2UgNDgwMDAgSHoKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBk ZXY9MHgyNGM2LCByZXZpZD0weDAzCglidXM9MCwgc2xvdD0zMSwgZnVuYz02CgljbGFzcz0wNy0w My0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDA1LCBzdGF0cmVnPTB4MDI5 MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgw MCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWIsIGlycT0xMAoJcG93ZXJzcGVj IDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQzCnBjaTA6MzE6NjogcmVwcm9iaW5nIG9uIGRy aXZlciBhZGRlZApwY2kwOjMxOjY6IFRyYW5zaXRpb24gZnJvbSBEMyB0byBEMApwY2kwOjMxOjY6 IFRyYW5zaXRpb24gZnJvbSBEMCB0byBEMwpwY2kxOiBkcml2ZXIgYWRkZWQKZm91bmQtPgl2ZW5k b3I9MHgxMDAyLCBkZXY9MHg0ZTUwLCByZXZpZD0weDAwCglidXM9MSwgc2xvdD0wLCBmdW5jPTAK CWNsYXNzPTAzLTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAzMDcsIHN0 YXRyZWc9MHgwMmIwLCBjYWNoZWxuc3o9OCAoZHdvcmRzKQoJbGF0dGltZXI9MHg0MiAoMTk4MCBu cyksIG1pbmdudD0weDA4ICgyMDAwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwg aXJxPTYKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMApwY2kx OjA6MDogcmVwcm9iaW5nIG9uIGRyaXZlciBhZGRlZApwY2kyOiBkcml2ZXIgYWRkZWQKZm91bmQt Pgl2ZW5kb3I9MHgxMDRjLCBkZXY9MHg4MDMzLCA= ------=_20041225225327_53204-- From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 26 08:01:23 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 685E216A4CE for ; Sun, 26 Dec 2004 08:01:23 +0000 (GMT) Received: from mail.revolutionsp.com (ganymede.revolutionsp.com [64.246.0.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE44443D49 for ; Sun, 26 Dec 2004 08:01:22 +0000 (GMT) (envelope-from security@revolutionsp.com) Received: from mail.revolutionsp.com (localhost [127.0.0.1]) by mail.revolutionsp.com (Postfix) with ESMTP id E9B0915CA7 for ; Sat, 25 Dec 2004 22:56:42 -0600 (CST) Received: from 81.84.175.77 (SquirrelMail authenticated user security@revolutionsp.com); by mail.revolutionsp.com with HTTP; Sat, 25 Dec 2004 22:56:42 -0600 (CST) Message-ID: <61469.81.84.175.77.1104037002.squirrel@81.84.175.77> In-Reply-To: <200412261731.25493.doconnor@gsoft.com.au> References: <62903.81.84.175.77.1104000639.squirrel@81.84.175.77> <200412261213.46361.doconnor@gsoft.com.au> <63000.81.84.175.77.1104029924.squirrel@81.84.175.77> <200412261731.25493.doconnor@gsoft.com.au> Date: Sat, 25 Dec 2004 22:56:42 -0600 (CST) From: security@revolutionsp.com To: freebsd-hackers@freebsd.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="----=_20041225225642_49957" X-Priority: 3 (Normal) Importance: Normal Subject: Re: Unable to get APM working -- help! X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2004 08:01:23 -0000 ------=_20041225225642_49957 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit > On Sun, 26 Dec 2004 13:28, security@revolutionsp.com wrote: >> > Try acpiconf -i 1 >> >> Same result :/ > > Hmm.. what's your dmesg output when you boot verbose with ACPI enabled? > Check the end of mail >> > I prefer acpi_pcc http://www.spa.is.uec.ac.jp/~nfukuda/software/ which >> I >> > believe does the same thing but only needs a kernel module to work. >> >> Does it work on Pentium-M ? > > Yep. > I'll try it out; meanwhile, I've discovered the sysctl to change this manually. I've checked it works by trying to compile something at the lowest CPU clock speed. It was slow to hell :-) >> >> load, and maxing it (1.6GHz) under load, but with ACPI off. With ACPI >> on >> >> it's always at 1.6GHz. Plus, I've noticed the 'top' CPU values are >> plain >> >> wrong. I was compiling thunderbird, xmms, and firefox and it showed >> all >> >> processes with 0.00% CPU. >> > >> > Do your kernel and userland match? >> >> 5.3-RELEASE from cd and a custom kernel I built. I've just tested, and >> the >> results are widly innacurate ONLY with ACPI turned on.. weird. > > Any chance there is a new BIOS available for that system? > A quick googling session brought up nothing. >> Did you have to do anything in special to make -i 0 work? (it says >> device >> not configured to me.. perhaps I missed something) > > No.. If I try and look at a non existent battery slot it says 'device not > configured' so maybe it thinks you have no batteries for some strange > reason. > I've installed klaptop and it shows battery as -1 and 'not charging' acpiconf -i[0-9] didn't do any good either :/ > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > dmesg (ACPI on, boot verbose) Copyright (c) 1992-2004 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 5.3-RELEASE #1: Sat Dec 25 03:41:40 WET 2004 hugo@porntatil.bsdlan.org:/usr/src/sys/i386/compile/laptop-kernel WARNING: debug.mpsafenet forced to 0 as ipsec requires Giant WARNING: MPSAFE network stack disabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xc09cb000. Calibrating clock(s) ... i8254 clock: 1193164 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1598650059 Hz CPU: Intel(R) Pentium(R) M processor 1.60GHz (1598.65-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6d6 Stepping = 6 Features=0xafe9f9bf real memory = 535691264 (510 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c26000 - 0x000000001f5b4fff, 513339392 bytes (125327 pages) avail memory = 514539520 (490 MB) bios32: Found BIOS32 Service Directory header at 0xc00f6310 bios32: Entry = 0xfd520 (c00fd520) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd520+0x262 pnpbios: Found PnP BIOS data at 0xc00f6350 pnpbios: Entry = f0000:ab76 Rev = 1.0 Other BIOS signatures found: wlan: <802.11 Link Layer> null: random: io: mem: Pentium Pro MTRR support enabled acpi0: on motherboard acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x8000f904 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=80] is there (id=35808086) pcibios: BIOS version 2.10 Found $PIR table, 9 entries at 0xc00fdd00 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded 0 30 A 0x60 6 embedded 0 30 B 0x61 10 embedded 0 30 C 0x62 6 embedded 0 30 D 0x63 6 embedded 2 6 A 0x68 10 embedded 2 6 B 0x69 10 embedded 2 6 C 0x6a 6 embedded 2 4 A 0x61 10 embedded 2 4 B 0x62 6 embedded 2 2 A 0x63 6 embedded 0 0 A 0x60 6 embedded 0 0 B 0x61 10 embedded 0 0 C 0x62 6 embedded 0 0 D 0x63 6 embedded 0 31 A 0x62 6 embedded 0 31 B 0x61 10 embedded 0 29 A 0x60 6 embedded 0 29 B 0x63 6 embedded 0 29 C 0x62 6 embedded 0 29 D 0x6b 10 embedded 0 1 A 0x60 6 embedded 0 1 B 0x61 10 slot 1 1 0 A 0x60 6 slot 1 1 0 B 0x61 10 AcpiOsDerivePciId: bus 0 dev 31 func 0 AcpiOsDerivePciId: bus 0 dev 31 func 0 AcpiOsDerivePciId: bus 0 dev 31 func 1 acpi0: Power Button (fixed) atpic: Programming IRQ9 as level/low AcpiOsDerivePciId: bus 0 dev 0 func 0 AcpiOsDerivePciId: bus 0 dev 0 func 1 acpi_ec0: port 0x66,0x62 on acpi0 acpi_ec0: info: new max delay is 970 us ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 acpi_tz0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 ACPI PCI link initial configuration: \\_SB_.PCI0.LPC0.LNKA irq 0: [ 6] 6+ low,level,sharable 0.1.0 \\_SB_.PCI0.LPC0.LNKA irq 0: [ 6] 6+ low,level,sharable 0.29.0 \\_SB_.PCI0.LPC0.LNKD irq 0: [ 6] 6+ low,level,sharable 0.29.1 \\_SB_.PCI0.LPC0.LNKC irq 0: [ 6] 6+ low,level,sharable 0.29.2 \\_SB_.PCI0.LPC0.LNKH irq 0: [10] 10+ low,level,sharable 0.29.3 \\_SB_.PCI0.LPC0.LNKC irq 0: [ 6] 6+ low,level,sharable 0.31.0 \\_SB_.PCI0.LPC0.LNKB irq 0: [10] 10+ low,level,sharable 0.31.1 pci0: on pcib0 pci0: physical bus=0 map[10]: type 3, range 32, base e0000000, size 28, enabled found-> vendor=0x8086, dev=0x3580, revid=0x02 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0106, statreg=0x3090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3584, revid=0x02 bus=0, slot=0, func=1 class=08-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0080, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3585, revid=0x02 bus=0, slot=0, func=3 class=08-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0080, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3581, revid=0x02 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x00a0, cachelnsz=0 (dwords) lattimer=0x60 (2880 ns), mingnt=0x0c (3000 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 00001800, size 5, enabled pcib0: matched entry for 0.29.INTA (src \\_SB_.PCI0.LPC0.LNKA) pcib0: possible interrupts: 6 ACPI PCI link arbitrated settings: \\_SB_.PCI0.LPC0.LNKA (references 2, priority 10100): interrupts: 6 penalty: 5050 \\_SB_.PCI0.LPC0.LNKC (references 2, priority 10100): interrupts: 6 penalty: 5050 \\_SB_.PCI0.LPC0.LNKD (references 1, priority 5050): interrupts: 6 penalty: 5050 \\_SB_.PCI0.LPC0.LNKH (references 1, priority 20): interrupts: 10 penalty: 20 \\_SB_.PCI0.LPC0.LNKB (references 1, priority 20): interrupts: 10 penalty: 20 pcib0: slot 29 INTA routed to irq 6 via \\_SB_.PCI0.LPC0.LNKA found-> vendor=0x8086, dev=0x24c2, revid=0x03 bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=6 map[20]: type 4, range 32, base 00001820, size 5, enabled pcib0: matched entry for 0.29.INTB (src \\_SB_.PCI0.LPC0.LNKD) pcib0: possible interrupts: 6 ACPI PCI link arbitrated settings: \\_SB_.PCI0.LPC0.LNKC (references 2, priority 10240): interrupts: 6 penalty: 5120 \\_SB_.PCI0.LPC0.LNKD (references 1, priority 5120): interrupts: 6 penalty: 5120 \\_SB_.PCI0.LPC0.LNKH (references 1, priority 40): interrupts: 10 penalty: 40 \\_SB_.PCI0.LPC0.LNKB (references 1, priority 40): interrupts: 10 penalty: 40 pcib0: slot 29 INTB routed to irq 6 via \\_SB_.PCI0.LPC0.LNKD found-> vendor=0x8086, dev=0x24c4, revid=0x03 bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=6 map[20]: type 4, range 32, base 00001840, size 5, enabled pcib0: matched entry for 0.29.INTC (src \\_SB_.PCI0.LPC0.LNKC) pcib0: possible interrupts: 6 ACPI PCI link arbitrated settings: \\_SB_.PCI0.LPC0.LNKC (references 2, priority 10360): interrupts: 6 penalty: 5180 \\_SB_.PCI0.LPC0.LNKH (references 1, priority 60): interrupts: 10 penalty: 60 \\_SB_.PCI0.LPC0.LNKB (references 1, priority 60): interrupts: 10 penalty: 60 pcib0: slot 29 INTC routed to irq 6 via \\_SB_.PCI0.LPC0.LNKC found-> vendor=0x8086, dev=0x24c7, revid=0x03 bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=6 map[10]: type 1, range 32, base d0000000, size 10, enabled pcib0: matched entry for 0.29.INTD (src \\_SB_.PCI0.LPC0.LNKH) pcib0: possible interrupts: 10 ACPI PCI link arbitrated settings: \\_SB_.PCI0.LPC0.LNKH (references 1, priority 80): interrupts: 10 penalty: 80 \\_SB_.PCI0.LPC0.LNKB (references 1, priority 80): interrupts: 10 penalty: 80 pcib0: slot 29 INTD routed to irq 10 via \\_SB_.PCI0.LPC0.LNKH found-> vendor=0x8086, dev=0x24cd, revid=0x03 bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=10 powerspec 2 supports D0 D3 current D0 found-> vendor=0x8086, dev=0x2448, revid=0x83 bus=0, slot=30, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x8880, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x24cc, revid=0x03 bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 00001860, size 4, enabled found-> vendor=0x8086, dev=0x24ca, revid=0x03 bus=0, slot=31, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 map[20]: type 4, range 32, base 00001880, size 5, enabled pcib0: matched entry for 0.31.INTB (src \\_SB_.PCI0.LPC0.LNKB) pcib0: possible interrupts: 10 ACPI PCI link arbitrated settings: \\_SB_.PCI0.LPC0.LNKB (references 1, priority 110): interrupts: 10 penalty: 110 pcib0: slot 31 INTB routed to irq 10 via \\_SB_.PCI0.LPC0.LNKB found-> vendor=0x8086, dev=0x24c3, revid=0x03 bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[10]: type 4, range 32, base 00001c00, size 8, enabled map[14]: type 4, range 32, base 000018c0, size 6, enabled map[18]: type 1, range 32, base d0000c00, size 9, enabled map[1c]: type 1, range 32, base d0000800, size 8, enabled pcib0: matched entry for 0.31.INTB (src \\_SB_.PCI0.LPC0.LNKB) pcib0: slot 31 INTB is already routed to irq 10 found-> vendor=0x8086, dev=0x24c5, revid=0x03 bus=0, slot=31, func=5 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 00002400, size 8, enabled map[14]: type 4, range 32, base 00002000, size 7, enabled pcib0: matched entry for 0.31.INTB (src \\_SB_.PCI0.LPC0.LNKB) pcib0: slot 31 INTB is already routed to irq 10 found-> vendor=0x8086, dev=0x24c6, revid=0x03 bus=0, slot=31, func=6 class=07-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 2 supports D0 D3 current D0 agp0: mem 0xe0000000-0xefffffff at device 0.0 on pci0 agp0: Reserved 0x10000000 bytes for rid 0x10 type 3 at 0xe0000000 agp0: allocating GATT for aperture of size 196M pci0: at device 0.1 (no driver attached) pci0: at device 0.3 (no driver attached) pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x3000-0x3fff pcib1: memory decode 0xd0100000-0xd01fffff pcib1: prefetched decode 0xd8000000-0xdfffffff ACPI PCI link initial configuration: \\_SB_.PCI0.LPC0.LNKA irq* 6: [ 6] 6+ low,level,sharable 1.0.0 pci1: on pcib1 pci1: physical bus=1 map[10]: type 3, range 32, base d8000000, size 27, enabled pcib1: device (null) requested decoded memory range 0xd8000000-0xdfffffff map[14]: type 4, range 32, base 00003000, size 8, enabled pcib1: device (null) requested decoded I/O range 0x3000-0x30ff map[18]: type 1, range 32, base d0100000, size 16, enabled pcib1: device (null) requested decoded memory range 0xd0100000-0xd010ffff pcib1: matched entry for 1.0.INTA (src \\_SB_.PCI0.LPC0.LNKA) pcib1: slot 0 INTA is already routed to irq 6 found-> vendor=0x1002, dev=0x4e50, revid=0x00 bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0307, statreg=0x02b0, cachelnsz=8 (dwords) lattimer=0x42 (1980 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=6 powerspec 2 supports D0 D1 D2 D3 current D0 pci1: at device 0.0 (no driver attached) uhci0: port 0x1800-0x181f irq 6 at device 29.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1800 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 0x1820-0x183f irq 6 at device 29.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1820 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 uhci2: port 0x1840-0x185f irq 6 at device 29.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1840 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered pci0: at device 29.7 (no driver attached) pcib2: at device 30.0 on pci0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0x4000-0x4fff pcib2: memory decode 0xd0200000-0xd05fffff pcib2: prefetched decode 0xfff00000-0xfffff pcib2: Subtractively decoded bridge. ACPI PCI link initial configuration: \\_SB_.PCI0.LPC0.LNKD irq* 6: [ 6] 6+ low,level,sharable 2.2.0 \\_SB_.PCI0.LPC0.LNKB irq*10: [10] 10+ low,level,sharable 2.4.0 \\_SB_.PCI0.LPC0.LNKC irq* 6: [ 6] 6+ low,level,sharable 2.4.1 \\_SB_.PCI0.LPC0.LNKE irq 0: [10] 10+ low,level,sharable 2.6.0 \\_SB_.PCI0.LPC0.LNKF irq 0: [10] 0+ low,level,sharable 2.6.1 \\_SB_.PCI0.LPC0.LNKG irq 0: [ 6] 0+ low,level,sharable 2.6.2 pci2: on pcib2 pci2: physical bus=2 map[10]: type 1, range 32, base d0204000, size 13, enabled pcib2: device (null) requested decoded memory range 0xd0204000-0xd0205fff pcib2: matched entry for 2.2.INTA (src \\_SB_.PCI0.LPC0.LNKD) pcib2: slot 2 INTA is already routed to irq 6 found-> vendor=0x14e4, dev=0x4401, revid=0x01 bus=2, slot=2, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0810, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=6 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base d0208000, size 12, enabled pcib2: device (null) requested decoded memory range 0xd0208000-0xd0208fff pcib2: matched entry for 2.4.INTA (src \\_SB_.PCI0.LPC0.LNKB) pcib2: slot 4 INTA is already routed to irq 10 found-> vendor=0x8086, dev=0x4220, revid=0x05 bus=2, slot=4, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0116, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x03 (750 ns), maxlat=0x18 (6000 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base d0209000, size 12, memory disabled pcib2: device (null) requested decoded memory range 0xd0209000-0xd0209fff pcib2: matched entry for 2.6.INTA (src \\_SB_.PCI0.LPC0.LNKE) pcib2: possible interrupts: 10 ACPI PCI link arbitrated settings: \\_SB_.PCI0.LPC0.LNKG (references 1, priority 5360): interrupts: 6 penalty: 5360 \\_SB_.PCI0.LPC0.LNKE (references 1, priority 180): interrupts: 10 penalty: 180 \\_SB_.PCI0.LPC0.LNKF (references 1, priority 180): interrupts: 10 penalty: 180 pcib2: slot 6 INTA routed to irq 10 via \\_SB_.PCI0.LPC0.LNKE found-> vendor=0x104c, dev=0x8031, revid=0x00 bus=2, slot=6, func=0 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0104, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x40 (16000 ns), maxlat=0x03 (750 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base d020a000, size 11, enabled pcib2: device (null) requested decoded memory range 0xd020a000-0xd020a7ff map[14]: type 1, range 32, base d0200000, size 14, enabled pcib2: device (null) requested decoded memory range 0xd0200000-0xd0203fff pcib2: matched entry for 2.6.INTA (src \\_SB_.PCI0.LPC0.LNKE) pcib2: slot 6 INTA is already routed to irq 10 found-> vendor=0x104c, dev=0x8032, revid=0x00 bus=2, slot=6, func=2 class=0c-00-10, hdrtype=0x00, mfdev=1 cmdreg=0x0116, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x03 (750 ns), maxlat=0x04 (1000 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base d0206000, size 13, enabled pcib2: device (null) requested decoded memory range 0xd0206000-0xd0207fff pcib2: matched entry for 2.6.INTA (src \\_SB_.PCI0.LPC0.LNKE) pcib2: slot 6 INTA is already routed to irq 10 found-> vendor=0x104c, dev=0x8033, revid=0x00 bus=2, slot=6, func=3 class=01-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0106, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x07 (1750 ns), maxlat=0x04 (1000 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 bfe0: mem 0xd0204000-0xd0205fff irq 6 at device 2.0 on pci2 bfe0: Reserved 0x2000 bytes for rid 0x10 type 3 at 0xd0204000 miibus0: on bfe0 bmtphy0: on miibus0 bmtphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto bfe0: bpf attached bfe0: Ethernet address: 00:c0:9f:6a:8e:1c bfe0: [GIANT-LOCKED] pci2: at device 4.0 (no driver attached) cbb0: mem 0xd0209000-0xd0209fff irq 10 at device 6.0 on pci2 cbb0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xd0209000 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [MPSAFE] cbb0: PCI Configuration space: 0x00: 0x8031104c 0x02100107 0x06070000 0x00824008 0x10: 0xd0209000 0x020000a0 0x20030302 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc 0x30: 0x00000000 0xfffffffc 0x00000000 0x0740010a 0x40: 0x00641025 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x18441060 0x02c00019 0x000f0000 0x01a21b22 0x90: 0x606480c0 0x00000000 0x00000000 0x00000000 0xa0: 0xfe120001 0x00c00000 0x00000000 0x00000000 0xb0: 0x08000000 0x00000000 0x00000000 0x00000000 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 fwohci0: vendor=104c, dev=8032 fwohci0: <1394 Open Host Controller Interface> mem 0xd0200000-0xd0203fff,0xd020a000-0xd020a7ff irq 10 at device 6.2 on pci2 fwohci0: Reserved 0x800 bytes for rid 0x10 type 3 at 0xd020a000 fwohci0: [GIANT-LOCKED] fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:c0:9f:00:00:32:14:de fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:c0:9f:32:14:de fwe0: bpf attached fwe0: Ethernet address: 02:c0:9f:32:14:de sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=0xc000ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) pci2: at device 6.3 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1860-0x186f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x1860 ata0: channel #0 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata0-slave: stat=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 ata0: [MPSAFE] ata1: channel #1 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=50 ostat1=00 ata1-master: stat=0x00 err=0x01 lsb=0x14 msb=0xeb ata1-slave: stat=0x00 err=0x00 lsb=0x00 msb=0x00 ata1: reset tp2 stat0=00 stat1=00 devices=0x4 ata1: [MPSAFE] pci0: at device 31.3 (no driver attached) pci0: at device 31.5 (no driver attached) pci0: at device 31.6 (no driver attached) acpi_lid0: on acpi0 acpi_button0: on acpi0 unknown: not probed (disabled) atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ unknown: not probed (disabled) psmcpnp0: irq 12 on acpi0 psm0: current command byte:0047 psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:00000000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) sio0: irq maps: 0x601 0x609 0x601 0x601 sio0 port 0x2f8-0x2ff irq 3 drq 1 flags 0x10 on acpi0 sio0: type 16550A unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it sio: sio0 already exists; skipping it Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 ex_isa_identify() unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff ahc_isa_probe 1: ioport 0x1c00 alloc failed sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xe0000-0xe3fff,0xdf800-0xdffff,0xd0000-0xd17ff,0xc0000-0xcffff on isa0 pmtimer0 on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0-0x3f5 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) pcic0 failed to probe at port 0x3e0 iomem 0xd0000 on isa0 pcic1: not probed (disabled) ppc0: parallel port not found. ppc0: failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio1 failed to probe at port 0x2f8 irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k vga0: vga: WARNING: video mode switching is not fully supported on this adapter VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5b 4f 4f 9f 52 16 9e 1f 00 4f 0d 0e 00 00 07 80 93 87 8f 28 1f 8f 9f a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff EGA/VGA parameters to be used for mode 24 50 18 10 00 00 00 03 00 02 67 5b 4f 4f 9f 52 16 9e 1f 00 4f 0d 0e 00 00 07 80 93 87 8f 28 1f 8f 9f a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. procfs registered Timecounter "TSC" frequency 1598650059 Hz quality 800 Timecounters tick every 10.000 msec WARNING: apm_saver module requires apm enabled splash: image decoder found: apm_saver IPsec: Initialized Security Association Processing. pflog0: bpf attached lo0: bpf attached cpu0: set speed to 100.0% acpi_cpu: throttling enabled, 8 steps (100% to 12.5%), currently 100.0% ata0-master: pio=0x0c wdma=0x22 udma=0x45 cable=80pin ata0-master: setting PIO4 on Intel ICH4 chip ata0-master: setting UDMA100 on Intel ICH4 chip ad0: ATA-6 disk at ata0-master ad0: 57231MB (117210240 sectors), 116280 C, 16 H, 63 S, 512 B ad0: 16 secs/int, 1 depth queue, UDMA100 GEOM: new disk ad0 ar: FreeBSD check1 failed ata1-master: pio=0x0c wdma=0x22 udma=0x42 cable=40pin ata1-master: setting PIO4 on Intel ICH4 chip ata1-master: setting UDMA33 on Intel ICH4 chip acd0: DVDR drive at ata1 as master acd0: read 4134KB/s (4134KB/s) write 4134KB/s (4134KB/s), 2048KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet acd0: Writes: CDR, CDRW, DVDR, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc [0] f:00 typ:18 s(CHS):0/1/1 e(CHS):382/254/63 s:63 l:6152832 [1] f:00 typ:6 s(CHS):383/0/1 e(CHS):1023/254/63 s:6152895 l:31455270 [2] f:80 typ:165 s(CHS):1023/255/63 e(CHS):1023/254/63 s:37608165 l:79602075 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad0s1, start 32256 length 3150249984 end 3150282239 GEOM: Configure ad0s2, start 3150282240 length 16105098240 end 19255380479 GEOM: Configure ad0s3, start 19255380480 length 40756262400 end 60011642879 GEOM: Configure ad0s3a, start 0 length 134217728 end 134217727 GEOM: Configure ad0s3b, start 13220446208 length 1073741824 end 14294188031 GEOM: Configure ad0s3c, start 0 length 40756262400 end 40756262399 GEOM: Configure ad0s3d, start 134217728 length 134217728 end 268435455 GEOM: Configure ad0s3e, start 268435456 length 67108864 end 335544319 GEOM: Configure ad0s3f, start 335544320 length 12884901888 end 13220446207 GEOM: Configure ad0s3g, start 14294188032 length 26462074368 end 40756262399 acpi_ec0: info: new max delay is 11000 us (probe5:sbp0:0:5:0): error 22 (probe5:sbp0:0:5:0): Unretryable Error (probe6:sbp0:0:6:0): error 22 (probe6:sbp0:0:6:0): Unretryable Error (probe0:sbp0:0:0:0): error 22 (probe0:sbp0:0:0:0): Unretryable Error (probe1:sbp0:0:1:0): error 22 (probe1:sbp0:0:1:0): Unretryable Error (probe2:sbp0:0:2:0): error 22 (probe2:sbp0:0:2:0): Unretryable Error (probe3:sbp0:0:3:0): error 22 (probe3:sbp0:0:3:0): Unretryable Error (probe4:sbp0:0:4:0): error 22 (probe4:sbp0:0:4:0): Unretryable Error Mounting root from ufs:/dev/ad0s3a WARNING: / was not properly dismounted start_init: trying /sbin/init WARNING: /home was not properly dismounted WARNING: /tmp was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted ------=_20041225225642_49957 Content-Type: application/octet-stream; name="dmesg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dmesg" ------=_20041225225642_49957 Content-Type: application/octet-stream; name="dmesg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dmesg" Q29weXJpZ2h0IChjKSAxOTkyLTIwMDQgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIDUuMy1SRUxFQVNFICMxOiBTYXQgRGVjIDI1IDAzOjQxOjQw IFdFVCAyMDA0CiAgICBodWdvQHBvcm50YXRpbC5ic2RsYW4ub3JnOi91c3Ivc3JjL3N5cy9pMzg2 L2NvbXBpbGUvbGFwdG9wLWtlcm5lbA== ------=_20041225225642_49957-- From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 26 08:02:08 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 293B816A4CE for ; Sun, 26 Dec 2004 08:02:08 +0000 (GMT) Received: from mail.revolutionsp.com (ganymede.revolutionsp.com [64.246.0.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB6EA43D1D for ; Sun, 26 Dec 2004 08:02:07 +0000 (GMT) (envelope-from security@revolutionsp.com) Received: from mail.revolutionsp.com (localhost [127.0.0.1]) by mail.revolutionsp.com (Postfix) with ESMTP id E394415CA7 for ; Sat, 25 Dec 2004 22:57:27 -0600 (CST) Received: from 81.84.175.77 (SquirrelMail authenticated user security@revolutionsp.com); by mail.revolutionsp.com with HTTP; Sat, 25 Dec 2004 22:57:27 -0600 (CST) Message-ID: <64137.81.84.175.77.1104037047.squirrel@81.84.175.77> In-Reply-To: <200412261731.25493.doconnor@gsoft.com.au> References: <62903.81.84.175.77.1104000639.squirrel@81.84.175.77> <200412261213.46361.doconnor@gsoft.com.au> <63000.81.84.175.77.1104029924.squirrel@81.84.175.77> <200412261731.25493.doconnor@gsoft.com.au> Date: Sat, 25 Dec 2004 22:57:27 -0600 (CST) From: security@revolutionsp.com To: freebsd-hackers@freebsd.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="----=_20041225225727_98939" X-Priority: 3 (Normal) Importance: Normal Subject: Re: Unable to get APM working -- help! X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2004 08:02:08 -0000 ------=_20041225225727_98939 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit > On Sun, 26 Dec 2004 13:28, security@revolutionsp.com wrote: >> > Try acpiconf -i 1 >> >> Same result :/ > > Hmm.. what's your dmesg output when you boot verbose with ACPI enabled? > I'll be mailing it right next from other mail account (it's timeouting on this web mail - subject is 'dmesg from acer laptop') >> > I prefer acpi_pcc http://www.spa.is.uec.ac.jp/~nfukuda/software/ which >> I >> > believe does the same thing but only needs a kernel module to work. >> >> Does it work on Pentium-M ? > > Yep. > I'll try it out; meanwhile, I've discovered the sysctl to change this manually. I've checked it works by trying to compile something at the lowest CPU clock speed. It was slow to hell :-) >> >> load, and maxing it (1.6GHz) under load, but with ACPI off. With ACPI >> on >> >> it's always at 1.6GHz. Plus, I've noticed the 'top' CPU values are >> plain >> >> wrong. I was compiling thunderbird, xmms, and firefox and it showed >> all >> >> processes with 0.00% CPU. >> > >> > Do your kernel and userland match? >> >> 5.3-RELEASE from cd and a custom kernel I built. I've just tested, and >> the >> results are widly innacurate ONLY with ACPI turned on.. weird. > > Any chance there is a new BIOS available for that system? > A quick googling session brought up nothing. >> Did you have to do anything in special to make -i 0 work? (it says >> device >> not configured to me.. perhaps I missed something) > > No.. If I try and look at a non existent battery slot it says 'device not > configured' so maybe it thinks you have no batteries for some strange > reason. > I've installed klaptop and it shows battery as -1 and 'not charging' acpiconf -i[0-9] didn't do any good either :/ > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > ------=_20041225225727_98939 Content-Type: application/octet-stream; name="dmesg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dmesg" ------=_20041225225727_98939 Content-Type: application/octet-stream; name="dmesg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dmesg" ------=_20041225225727_98939 Content-Type: application/octet-stream; name="dmesg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dmesg" Q29weXJpZ2h0IChjKSAxOTkyLTIwMDQgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIDUuMy1SRUxFQVNFICMxOiBTYXQgRGVjIDI1IDAzOjQxOjQw IFdFVCAyMDA0CiAgICBodWdvQHBvcm50YXRpbC5ic2RsYW4ub3JnOi91c3Ivc3JjL3N5cy9pMzg2 L2NvbXBpbGUvbGFwdG9wLWtlcm5lbApXQVJOSU5HOiBkZWJ1Zy5tcHNhZmVuZXQgZm9yY2VkIHRv IDAgYXMgaXBzZWMgcmVxdWlyZXMgR2lhbnQKV0FSTklORzogTVBTQUZFIG5ldHdvcmsgc3RhY2sg ZGlzYWJsZWQsIGV4cGVjdCByZWR1Y2VkIHBlcmZvcm1hbmNlLgpQcmVsb2FkZWQgZWxmIGtlcm5l bCAiL2Jvb3Qva2VybmVsL2tlcm5lbCIgYXQgMHhjMDljYjAwMC4KQ2FsaWJyYXRpbmcgY2xvY2so cykgLi4uIGk4MjU0IGNsb2NrOiAxMTkzMTY0IEh6CkNMS19VU0VfSTgyNTRfQ0FMSUJSQVRJT04g bm90IHNwZWNpZmllZCAtIHVzaW5nIGRlZmF1bHQgZnJlcXVlbmN5ClRpbWVjb3VudGVyICJpODI1 NCIgZnJlcXVlbmN5IDExOTMxODIgSHogcXVhbGl0eSAwCkNhbGlicmF0aW5nIFRTQyBjbG9jayAu Li4gVFNDIGNsb2NrOiAxNTk4NjUwMDU5IEh6CkNQVTogSW50ZWwoUikgUGVudGl1bShSKSBNIHBy b2Nlc3NvciAxLjYwR0h6ICgxNTk4LjY1LU1IeiA2ODYtY2xhc3MgQ1BVKQogIE9yaWdpbiA9ICJH ZW51aW5lSW50ZWwiICBJZCA9IDB4NmQ2ICBTdGVwcGluZyA9IDYKICBGZWF0dXJlcz0weGFmZTlm OWJmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1IsTUNFLENYOCxTRVAsTVRSUixQR0UsTUNBLENNT1Ys UEFULENMRkxVU0gsRFRTLEFDUEksTU1YLEZYU1IsU1NFLFNTRTIsU1MsVE0sUEJFPgpyZWFsIG1l bW9yeSAgPSA1MzU2OTEyNjQgKDUxMCBNQikKUGh5c2ljYWwgbWVtb3J5IGNodW5rKHMpOgoweDAw MDAwMDAwMDAwMDEwMDAgLSAweDAwMDAwMDAwMDAwOWVmZmYsIDY0NzE2OCBieXRlcyAoMTU4IHBh Z2VzKQoweDAwMDAwMDAwMDAxMDAwMDAgLSAweDAwMDAwMDAwMDAzZmZmZmYsIDMxNDU3MjggYnl0 ZXMgKDc2OCBwYWdlcykKMHgwMDAwMDAwMDAwYzI2MDAwIC0gMHgwMDAwMDAwMDFmNWI0ZmZmLCA1 MTMzMzkzOTIgYnl0ZXMgKDEyNTMyNyBwYWdlcykKYXZhaWwgbWVtb3J5ID0gNTE0NTM5NTIwICg0 OTAgTUIpCmJpb3MzMjogRm91bmQgQklPUzMyIFNlcnZpY2UgRGlyZWN0b3J5IGhlYWRlciBhdCAw eGMwMGY2MzEwCmJpb3MzMjogRW50cnkgPSAweGZkNTIwIChjMDBmZDUyMCkgIFJldiA9IDAgIExl biA9IDEKcGNpYmlvczogUENJIEJJT1MgZW50cnkgYXQgMHhmZDUyMCsweDI2MgpwbnBiaW9zOiBG b3VuZCBQblAgQklPUyBkYXRhIGF0IDB4YzAwZjYzNTAKcG5wYmlvczogRW50cnkgPSBmMDAwMDph Yjc2ICBSZXYgPSAxLjAKT3RoZXIgQklPUyBzaWduYXR1cmVzIGZvdW5kOgp3bGFuOiA8ODAyLjEx IExpbmsgTGF5ZXI+Cm51bGw6IDxudWxsIGRldmljZSwgemVybyBkZXZpY2U+CnJhbmRvbTogPGVu dHJvcHkgc291cmNlLCBTb2Z0d2FyZSwgWWFycm93PgppbzogPEkvTz4KbWVtOiA8bWVtb3J5PgpQ ZW50aXVtIFBybyBNVFJSIHN1cHBvcnQgZW5hYmxlZAphY3BpMDogPEFDRVIgS2VzdHJlbD4gb24g bW90aGVyYm9hcmQKYWNwaTA6IFtNUFNBRkVdCnBjaV9vcGVuKDEpOgltb2RlIDEgYWRkciBwb3J0 ICgweDBjZjgpIGlzIDB4ODAwMGY5MDQKcGNpX29wZW4oMWEpOgltb2RlMXJlcz0weDgwMDAwMDAw ICgweDgwMDAwMDAwKQpwY2lfY2ZnY2hlY2s6CWRldmljZSAwIFtjbGFzcz0wNjAwMDBdIFtoZHI9 ODBdIGlzIHRoZXJlIChpZD0zNTgwODA4NikKcGNpYmlvczogQklPUyB2ZXJzaW9uIDIuMTAKRm91 bmQgJFBJUiB0YWJsZSwgOSBlbnRyaWVzIGF0IDB4YzAwZmRkMDAKUENJLU9ubHkgSW50ZXJydXB0 czogbm9uZQpMb2NhdGlvbiAgQnVzIERldmljZSBQaW4gIExpbmsgIElSUXMKZW1iZWRkZWQgICAg MCAgIDMwICAgIEEgICAweDYwICA2CmVtYmVkZGVkICAgIDAgICAzMCAgICBCICAgMHg2MSAgMTAK ZW1iZWRkZWQgICAgMCAgIDMwICAgIEMgICAweDYyICA2CmVtYmVkZGVkICAgIDAgICAzMCAgICBE ICAgMHg2MyAgNgplbWJlZGRlZCAgICAyICAgIDYgICAgQSAgIDB4NjggIDEwCmVtYmVkZGVkICAg IDIgICAgNiAgICBCICAgMHg2OSAgMTAKZW1iZWRkZWQgICAgMiAgICA2ICAgIEMgICAweDZhICA2 CmVtYmVkZGVkICAgIDIgICAgNCAgICBBICAgMHg2MSAgMTAKZW1iZWRkZWQgICAgMiAgICA0ICAg IEIgICAweDYyICA2CmVtYmVkZGVkICAgIDIgICAgMiAgICBBICAgMHg2MyAgNgplbWJlZGRlZCAg ICAwICAgIDAgICAgQSAgIDB4NjAgIDYKZW1iZWRkZWQgICAgMCAgICAwICAgIEIgICAweDYxICAx MAplbWJlZGRlZCAgICAwICAgIDAgICAgQyAgIDB4NjIgIDYKZW1iZWRkZWQgICAgMCAgICAwICAg IEQgICAweDYzICA2CmVtYmVkZGVkICAgIDAgICAzMSAgICBBICAgMHg2MiAgNgplbWJlZGRlZCAg ICAwICAgMzEgICAgQiAgIDB4NjEgIDEwCmVtYmVkZGVkICAgIDAgICAyOSAgICBBICAgMHg2MCAg NgplbWJlZGRlZCAgICAwICAgMjkgICAgQiAgIDB4NjMgIDYKZW1iZWRkZWQgICAgMCAgIDI5ICAg IEMgICAweDYyICA2CmVtYmVkZGVkICAgIDAgICAyOSAgICBEICAgMHg2YiAgMTAKZW1iZWRkZWQg ICAgMCAgICAxICAgIEEgICAweDYwICA2CmVtYmVkZGVkICAgIDAgICAgMSAgICBCICAgMHg2MSAg MTAKc2xvdCAxICAgICAgMSAgICAwICAgIEEgICAweDYwICA2CnNsb3QgMSAgICAgIDEgICAgMCAg ICBCICAgMHg2MSAgMTAKQWNwaU9zRGVyaXZlUGNpSWQ6IGJ1cyAwIGRldiAzMSBmdW5jIDAKQWNw aU9zRGVyaXZlUGNpSWQ6IGJ1cyAwIGRldiAzMSBmdW5jIDAKQWNwaU9zRGVyaXZlUGNpSWQ6IGJ1 cyAwIGRldiAzMSBmdW5jIDEKYWNwaTA6IFBvd2VyIEJ1dHRvbiAoZml4ZWQpCmF0cGljOiBQcm9n cmFtbWluZyBJUlE5IGFzIGxldmVsL2xvdwpBY3BpT3NEZXJpdmVQY2lJZDogYnVzIDAgZGV2IDAg ZnVuYyAwCkFjcGlPc0Rlcml2ZVBjaUlkOiBidXMgMCBkZXYgMCBmdW5jIDEKYWNwaV9lYzA6IDxF bWJlZGRlZCBDb250cm9sbGVyOiBHUEUgMHgxZD4gcG9ydCAweDY2LDB4NjIgb24gYWNwaTAKYWNw aV9lYzA6IGluZm86IG5ldyBtYXggZGVsYXkgaXMgOTcwIHVzCkFDUEkgdGltZXIgbG9va3MgR09P RCBtaW4gPSAyLCBtYXggPSAzLCB3aWR0aCA9IDEKQUNQSSB0aW1lciBsb29rcyBHT09EIG1pbiA9 IDIsIG1heCA9IDMsIHdpZHRoID0gMQpBQ1BJIHRpbWVyIGxvb2tzIEdPT0QgbWluID0gMiwgbWF4 ID0gMywgd2lkdGggPSAxCkFDUEkgdGltZXIgbG9va3MgR09PRCBtaW4gPSAyLCBtYXggPSAzLCB3 aWR0aCA9IDEKQUNQSSB0aW1lciBsb29rcyBHT09EIG1pbiA9IDIsIG1heCA9IDMsIHdpZHRoID0g MQpBQ1BJIHRpbWVyIGxvb2tzIEdPT0QgbWluID0gMiwgbWF4ID0gMywgd2lkdGggPSAxCkFDUEkg dGltZXIgbG9va3MgR09PRCBtaW4gPSAyLCBtYXggPSAzLCB3aWR0aCA9IDEKQUNQSSB0aW1lciBs b29rcyBHT09EIG1pbiA9IDIsIG1heCA9IDMsIHdpZHRoID0gMQpBQ1BJIHRpbWVyIGxvb2tzIEdP T0QgbWluID0gMiwgbWF4ID0gMywgd2lkdGggPSAxCkFDUEkgdGltZXIgbG9va3MgR09PRCBtaW4g PSAyLCBtYXggPSAzLCB3aWR0aCA9IDEKVGltZWNvdW50ZXIgIkFDUEktZmFzdCIgZnJlcXVlbmN5 IDM1Nzk1NDUgSHogcXVhbGl0eSAxMDAwCmFjcGlfdGltZXIwOiA8MjQtYml0IHRpbWVyIGF0IDMu NTc5NTQ1TUh6PiBwb3J0IDB4MTAwOC0weDEwMGIgb24gYWNwaTAKY3B1MDogPEFDUEkgQ1BVICgz IEN4IHN0YXRlcyk+IG9uIGFjcGkwCmFjcGlfdHowOiA8VGhlcm1hbCBab25lPiBvbiBhY3BpMApw Y2liMDogPEFDUEkgSG9zdC1QQ0kgYnJpZGdlPiBwb3J0IDB4Y2Y4LTB4Y2ZmIG9uIGFjcGkwCkFD UEkgUENJIGxpbmsgaW5pdGlhbCBjb25maWd1cmF0aW9uOgpcXF9TQl8uUENJMC5MUEMwLkxOS0Eg aXJxICAwOiBbIDZdICA2KyBsb3csbGV2ZWwsc2hhcmFibGUgMC4xLjAKXFxfU0JfLlBDSTAuTFBD MC5MTktBIGlycSAgMDogWyA2XSAgNisgbG93LGxldmVsLHNoYXJhYmxlIDAuMjkuMApcXF9TQl8u UENJMC5MUEMwLkxOS0QgaXJxICAwOiBbIDZdICA2KyBsb3csbGV2ZWwsc2hhcmFibGUgMC4yOS4x ClxcX1NCXy5QQ0kwLkxQQzAuTE5LQyBpcnEgIDA6IFsgNl0gIDYrIGxvdyxsZXZlbCxzaGFyYWJs ZSAwLjI5LjIKXFxfU0JfLlBDSTAuTFBDMC5MTktIIGlycSAgMDogWzEwXSAxMCsgbG93LGxldmVs LHNoYXJhYmxlIDAuMjkuMwpcXF9TQl8uUENJMC5MUEMwLkxOS0MgaXJxICAwOiBbIDZdICA2KyBs b3csbGV2ZWwsc2hhcmFibGUgMC4zMS4wClxcX1NCXy5QQ0kwLkxQQzAuTE5LQiBpcnEgIDA6IFsx MF0gMTArIGxvdyxsZXZlbCxzaGFyYWJsZSAwLjMxLjEKcGNpMDogPEFDUEkgUENJIGJ1cz4gb24g cGNpYjAKcGNpMDogcGh5c2ljYWwgYnVzPTAKCW1hcFsxMF06IHR5cGUgMywgcmFuZ2UgMzIsIGJh c2UgZTAwMDAwMDAsIHNpemUgMjgsIGVuYWJsZWQKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9 MHgzNTgwLCByZXZpZD0weDAyCglidXM9MCwgc2xvdD0wLCBmdW5jPTAKCWNsYXNzPTA2LTAwLTAw LCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAxMDYsIHN0YXRyZWc9MHgzMDkwLCBj YWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgw IG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MzU4 NCwgcmV2aWQ9MHgwMgoJYnVzPTAsIHNsb3Q9MCwgZnVuYz0xCgljbGFzcz0wOC04MC0wMCwgaGRy dHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDA2LCBzdGF0cmVnPTB4MDA4MCwgY2FjaGVs bnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyks IG1heGxhdD0weDAwICgwIG5zKQpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDM1ODUsIHJl dmlkPTB4MDIKCWJ1cz0wLCBzbG90PTAsIGZ1bmM9MwoJY2xhc3M9MDgtODAtMDAsIGhkcnR5cGU9 MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwNiwgc3RhdHJlZz0weDAwODAsIGNhY2hlbG5zej0w IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhs YXQ9MHgwMCAoMCBucykKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgzNTgxLCByZXZpZD0w eDAyCglidXM9MCwgc2xvdD0xLCBmdW5jPTAKCWNsYXNzPTA2LTA0LTAwLCBoZHJ0eXBlPTB4MDEs IG1mZGV2PTAKCWNtZHJlZz0weDAxMDcsIHN0YXRyZWc9MHgwMGEwLCBjYWNoZWxuc3o9MCAoZHdv cmRzKQoJbGF0dGltZXI9MHg2MCAoMjg4MCBucyksIG1pbmdudD0weDBjICgzMDAwIG5zKSwgbWF4 bGF0PTB4MDAgKDAgbnMpCgltYXBbMjBdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDAxODAw LCBzaXplICA1LCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjI5LklOVEEgKHNy YyBcXF9TQl8uUENJMC5MUEMwLkxOS0EpCnBjaWIwOiBwb3NzaWJsZSBpbnRlcnJ1cHRzOiAgNgpB Q1BJIFBDSSBsaW5rIGFyYml0cmF0ZWQgc2V0dGluZ3M6ClxcX1NCXy5QQ0kwLkxQQzAuTE5LQSAo cmVmZXJlbmNlcyAyLCBwcmlvcml0eSAxMDEwMCk6CglpbnRlcnJ1cHRzOgkgICAgIDYKCXBlbmFs dHk6CSAgNTA1MApcXF9TQl8uUENJMC5MUEMwLkxOS0MgKHJlZmVyZW5jZXMgMiwgcHJpb3JpdHkg MTAxMDApOgoJaW50ZXJydXB0czoJICAgICA2CglwZW5hbHR5OgkgIDUwNTAKXFxfU0JfLlBDSTAu TFBDMC5MTktEIChyZWZlcmVuY2VzIDEsIHByaW9yaXR5IDUwNTApOgoJaW50ZXJydXB0czoJICAg ICA2CglwZW5hbHR5OgkgIDUwNTAKXFxfU0JfLlBDSTAuTFBDMC5MTktIIChyZWZlcmVuY2VzIDEs IHByaW9yaXR5IDIwKToKCWludGVycnVwdHM6CSAgICAxMAoJcGVuYWx0eToJICAgIDIwClxcX1NC Xy5QQ0kwLkxQQzAuTE5LQiAocmVmZXJlbmNlcyAxLCBwcmlvcml0eSAyMCk6CglpbnRlcnJ1cHRz OgkgICAgMTAKCXBlbmFsdHk6CSAgICAyMApwY2liMDogc2xvdCAyOSBJTlRBIHJvdXRlZCB0byBp cnEgNiB2aWEgXFxfU0JfLlBDSTAuTFBDMC5MTktBCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2 PTB4MjRjMiwgcmV2aWQ9MHgwMwoJYnVzPTAsIHNsb3Q9MjksIGZ1bmM9MAoJY2xhc3M9MGMtMDMt MDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwNSwgc3RhdHJlZz0weDAyODAs IGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAg KDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9NgoJbWFwWzIwXTogdHlw ZSA0LCByYW5nZSAzMiwgYmFzZSAwMDAwMTgyMCwgc2l6ZSAgNSwgZW5hYmxlZApwY2liMDogbWF0 Y2hlZCBlbnRyeSBmb3IgMC4yOS5JTlRCIChzcmMgXFxfU0JfLlBDSTAuTFBDMC5MTktEKQpwY2li MDogcG9zc2libGUgaW50ZXJydXB0czogIDYKQUNQSSBQQ0kgbGluayBhcmJpdHJhdGVkIHNldHRp bmdzOgpcXF9TQl8uUENJMC5MUEMwLkxOS0MgKHJlZmVyZW5jZXMgMiwgcHJpb3JpdHkgMTAyNDAp OgoJaW50ZXJydXB0czoJICAgICA2CglwZW5hbHR5OgkgIDUxMjAKXFxfU0JfLlBDSTAuTFBDMC5M TktEIChyZWZlcmVuY2VzIDEsIHByaW9yaXR5IDUxMjApOgoJaW50ZXJydXB0czoJICAgICA2Cglw ZW5hbHR5OgkgIDUxMjAKXFxfU0JfLlBDSTAuTFBDMC5MTktIIChyZWZlcmVuY2VzIDEsIHByaW9y aXR5IDQwKToKCWludGVycnVwdHM6CSAgICAxMAoJcGVuYWx0eToJICAgIDQwClxcX1NCXy5QQ0kw LkxQQzAuTE5LQiAocmVmZXJlbmNlcyAxLCBwcmlvcml0eSA0MCk6CglpbnRlcnJ1cHRzOgkgICAg MTAKCXBlbmFsdHk6CSAgICA0MApwY2liMDogc2xvdCAyOSBJTlRCIHJvdXRlZCB0byBpcnEgNiB2 aWEgXFxfU0JfLlBDSTAuTFBDMC5MTktECmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjRj NCwgcmV2aWQ9MHgwMwoJYnVzPTAsIHNsb3Q9MjksIGZ1bmM9MQoJY2xhc3M9MGMtMDMtMDAsIGhk cnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNSwgc3RhdHJlZz0weDAyODAsIGNhY2hl bG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMp LCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1iLCBpcnE9NgoJbWFwWzIwXTogdHlwZSA0LCBy YW5nZSAzMiwgYmFzZSAwMDAwMTg0MCwgc2l6ZSAgNSwgZW5hYmxlZApwY2liMDogbWF0Y2hlZCBl bnRyeSBmb3IgMC4yOS5JTlRDIChzcmMgXFxfU0JfLlBDSTAuTFBDMC5MTktDKQpwY2liMDogcG9z c2libGUgaW50ZXJydXB0czogIDYKQUNQSSBQQ0kgbGluayBhcmJpdHJhdGVkIHNldHRpbmdzOgpc XF9TQl8uUENJMC5MUEMwLkxOS0MgKHJlZmVyZW5jZXMgMiwgcHJpb3JpdHkgMTAzNjApOgoJaW50 ZXJydXB0czoJICAgICA2CglwZW5hbHR5OgkgIDUxODAKXFxfU0JfLlBDSTAuTFBDMC5MTktIIChy ZWZlcmVuY2VzIDEsIHByaW9yaXR5IDYwKToKCWludGVycnVwdHM6CSAgICAxMAoJcGVuYWx0eToJ ICAgIDYwClxcX1NCXy5QQ0kwLkxQQzAuTE5LQiAocmVmZXJlbmNlcyAxLCBwcmlvcml0eSA2MCk6 CglpbnRlcnJ1cHRzOgkgICAgMTAKCXBlbmFsdHk6CSAgICA2MApwY2liMDogc2xvdCAyOSBJTlRD IHJvdXRlZCB0byBpcnEgNiB2aWEgXFxfU0JfLlBDSTAuTFBDMC5MTktDCmZvdW5kLT4JdmVuZG9y PTB4ODA4NiwgZGV2PTB4MjRjNywgcmV2aWQ9MHgwMwoJYnVzPTAsIHNsb3Q9MjksIGZ1bmM9MgoJ Y2xhc3M9MGMtMDMtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNSwgc3Rh dHJlZz0weDAyODAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwg bWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1jLCBpcnE9NgoJ bWFwWzEwXTogdHlwZSAxLCByYW5nZSAzMiwgYmFzZSBkMDAwMDAwMCwgc2l6ZSAxMCwgZW5hYmxl ZApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4yOS5JTlREIChzcmMgXFxfU0JfLlBDSTAuTFBD MC5MTktIKQpwY2liMDogcG9zc2libGUgaW50ZXJydXB0czogMTAKQUNQSSBQQ0kgbGluayBhcmJp dHJhdGVkIHNldHRpbmdzOgpcXF9TQl8uUENJMC5MUEMwLkxOS0ggKHJlZmVyZW5jZXMgMSwgcHJp b3JpdHkgODApOgoJaW50ZXJydXB0czoJICAgIDEwCglwZW5hbHR5OgkgICAgODAKXFxfU0JfLlBD STAuTFBDMC5MTktCIChyZWZlcmVuY2VzIDEsIHByaW9yaXR5IDgwKToKCWludGVycnVwdHM6CSAg ICAxMAoJcGVuYWx0eToJICAgIDgwCnBjaWIwOiBzbG90IDI5IElOVEQgcm91dGVkIHRvIGlycSAx MCB2aWEgXFxfU0JfLlBDSTAuTFBDMC5MTktICmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4 MjRjZCwgcmV2aWQ9MHgwMwoJYnVzPTAsIHNsb3Q9MjksIGZ1bmM9NwoJY2xhc3M9MGMtMDMtMjAs IGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDEwNiwgc3RhdHJlZz0weDAyOTAsIGNh Y2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAg bnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1kLCBpcnE9MTAKCXBvd2Vyc3BlYyAyICBz dXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMApmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI0 NDgsIHJldmlkPTB4ODMKCWJ1cz0wLCBzbG90PTMwLCBmdW5jPTAKCWNsYXNzPTA2LTA0LTAwLCBo ZHJ0eXBlPTB4MDEsIG1mZGV2PTAKCWNtZHJlZz0weDAxMDcsIHN0YXRyZWc9MHg4ODgwLCBjYWNo ZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDA0ICgxMDAw IG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjRj YywgcmV2aWQ9MHgwMwoJYnVzPTAsIHNsb3Q9MzEsIGZ1bmM9MAoJY2xhc3M9MDYtMDEtMDAsIGhk cnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwZiwgc3RhdHJlZz0weDAyODAsIGNhY2hl bG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMp LCBtYXhsYXQ9MHgwMCAoMCBucykKCW1hcFsyMF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAw MDE4NjAsIHNpemUgIDQsIGVuYWJsZWQKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyNGNh LCByZXZpZD0weDAzCglidXM9MCwgc2xvdD0zMSwgZnVuYz0xCgljbGFzcz0wMS0wMS04YSwgaGRy dHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDA1LCBzdGF0cmVnPTB4MDI4MCwgY2FjaGVs bnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyks IG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0yNTUKCW1hcFsyMF06IHR5cGUgNCwg cmFuZ2UgMzIsIGJhc2UgMDAwMDE4ODAsIHNpemUgIDUsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQg ZW50cnkgZm9yIDAuMzEuSU5UQiAoc3JjIFxcX1NCXy5QQ0kwLkxQQzAuTE5LQikKcGNpYjA6IHBv c3NpYmxlIGludGVycnVwdHM6IDEwCkFDUEkgUENJIGxpbmsgYXJiaXRyYXRlZCBzZXR0aW5nczoK XFxfU0JfLlBDSTAuTFBDMC5MTktCIChyZWZlcmVuY2VzIDEsIHByaW9yaXR5IDExMCk6CglpbnRl cnJ1cHRzOgkgICAgMTAKCXBlbmFsdHk6CSAgIDExMApwY2liMDogc2xvdCAzMSBJTlRCIHJvdXRl ZCB0byBpcnEgMTAgdmlhIFxcX1NCXy5QQ0kwLkxQQzAuTE5LQgpmb3VuZC0+CXZlbmRvcj0weDgw ODYsIGRldj0weDI0YzMsIHJldmlkPTB4MDMKCWJ1cz0wLCBzbG90PTMxLCBmdW5jPTMKCWNsYXNz PTBjLTA1LTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDEsIHN0YXRyZWc9 MHgwMjgwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdu dD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YiwgaXJxPTEwCgltYXBb MTBdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDAxYzAwLCBzaXplICA4LCBlbmFibGVkCglt YXBbMTRdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDAxOGMwLCBzaXplICA2LCBlbmFibGVk CgltYXBbMThdOiB0eXBlIDEsIHJhbmdlIDMyLCBiYXNlIGQwMDAwYzAwLCBzaXplICA5LCBlbmFi bGVkCgltYXBbMWNdOiB0eXBlIDEsIHJhbmdlIDMyLCBiYXNlIGQwMDAwODAwLCBzaXplICA4LCBl bmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjMxLklOVEIgKHNyYyBcXF9TQl8uUENJ MC5MUEMwLkxOS0IpCnBjaWIwOiBzbG90IDMxIElOVEIgaXMgYWxyZWFkeSByb3V0ZWQgdG8gaXJx IDEwCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjRjNSwgcmV2aWQ9MHgwMwoJYnVzPTAs IHNsb3Q9MzEsIGZ1bmM9NQoJY2xhc3M9MDQtMDEtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJ Y21kcmVnPTB4MDAwNywgc3RhdHJlZz0weDAyOTAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0 aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykK CWludHBpbj1iLCBpcnE9MTAKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBE MAoJbWFwWzEwXTogdHlwZSA0LCByYW5nZSAzMiwgYmFzZSAwMDAwMjQwMCwgc2l6ZSAgOCwgZW5h YmxlZAoJbWFwWzE0XTogdHlwZSA0LCByYW5nZSAzMiwgYmFzZSAwMDAwMjAwMCwgc2l6ZSAgNywg ZW5hYmxlZApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4zMS5JTlRCIChzcmMgXFxfU0JfLlBD STAuTFBDMC5MTktCKQpwY2liMDogc2xvdCAzMSBJTlRCIGlzIGFscmVhZHkgcm91dGVkIHRvIGly cSAxMApmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI0YzYsIHJldmlkPTB4MDMKCWJ1cz0w LCBzbG90PTMxLCBmdW5jPTYKCWNsYXNzPTA3LTAzLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAK CWNtZHJlZz0weDAwMDUsIHN0YXRyZWc9MHgwMjkwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0 dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMp CglpbnRwaW49YiwgaXJxPTEwCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQg RDAKYWdwMDogPEludGVsIEdlbmVyaWMgaG9zdCB0byBQQ0kgYnJpZGdlPiBtZW0gMHhlMDAwMDAw MC0weGVmZmZmZmZmIGF0IGRldmljZSAwLjAgb24gcGNpMAphZ3AwOiBSZXNlcnZlZCAweDEwMDAw MDAwIGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDMgYXQgMHhlMDAwMDAwMAphZ3AwOiBhbGxvY2F0 aW5nIEdBVFQgZm9yIGFwZXJ0dXJlIG9mIHNpemUgMTk2TQpwY2kwOiA8YmFzZSBwZXJpcGhlcmFs PiBhdCBkZXZpY2UgMC4xIChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaTA6IDxiYXNlIHBlcmlwaGVy YWw+IGF0IGRldmljZSAwLjMgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpYjE6IDxBQ1BJIFBDSS1Q Q0kgYnJpZGdlPiBhdCBkZXZpY2UgMS4wIG9uIHBjaTAKcGNpYjE6ICAgc2Vjb25kYXJ5IGJ1cyAg ICAgMQpwY2liMTogICBzdWJvcmRpbmF0ZSBidXMgICAxCnBjaWIxOiAgIEkvTyBkZWNvZGUgICAg ICAgIDB4MzAwMC0weDNmZmYKcGNpYjE6ICAgbWVtb3J5IGRlY29kZSAgICAgMHhkMDEwMDAwMC0w eGQwMWZmZmZmCnBjaWIxOiAgIHByZWZldGNoZWQgZGVjb2RlIDB4ZDgwMDAwMDAtMHhkZmZmZmZm ZgpBQ1BJIFBDSSBsaW5rIGluaXRpYWwgY29uZmlndXJhdGlvbjoKXFxfU0JfLlBDSTAuTFBDMC5M TktBIGlycSogNjogWyA2XSAgNisgbG93LGxldmVsLHNoYXJhYmxlIDEuMC4wCnBjaTE6IDxBQ1BJ IFBDSSBidXM+IG9uIHBjaWIxCnBjaTE6IHBoeXNpY2FsIGJ1cz0xCgltYXBbMTBdOiB0eXBlIDMs IHJhbmdlIDMyLCBiYXNlIGQ4MDAwMDAwLCBzaXplIDI3LCBlbmFibGVkCnBjaWIxOiBkZXZpY2Ug KG51bGwpIHJlcXVlc3RlZCBkZWNvZGVkIG1lbW9yeSByYW5nZSAweGQ4MDAwMDAwLTB4ZGZmZmZm ZmYKCW1hcFsxNF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMDMwMDAsIHNpemUgIDgsIGVu YWJsZWQKcGNpYjE6IGRldmljZSAobnVsbCkgcmVxdWVzdGVkIGRlY29kZWQgSS9PIHJhbmdlIDB4 MzAwMC0weDMwZmYKCW1hcFsxOF06IHR5cGUgMSwgcmFuZ2UgMzIsIGJhc2UgZDAxMDAwMDAsIHNp emUgMTYsIGVuYWJsZWQKcGNpYjE6IGRldmljZSAobnVsbCkgcmVxdWVzdGVkIGRlY29kZWQgbWVt b3J5IHJhbmdlIDB4ZDAxMDAwMDAtMHhkMDEwZmZmZgpwY2liMTogbWF0Y2hlZCBlbnRyeSBmb3Ig MS4wLklOVEEgKHNyYyBcXF9TQl8uUENJMC5MUEMwLkxOS0EpCnBjaWIxOiBzbG90IDAgSU5UQSBp cyBhbHJlYWR5IHJvdXRlZCB0byBpcnEgNgpmb3VuZC0+CXZlbmRvcj0weDEwMDIsIGRldj0weDRl NTAsIHJldmlkPTB4MDAKCWJ1cz0xLCBzbG90PTAsIGZ1bmM9MAoJY2xhc3M9MDMtMDAtMDAsIGhk cnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDMwNywgc3RhdHJlZz0weDAyYjAsIGNhY2hl bG5zej04IChkd29yZHMpCglsYXR0aW1lcj0weDQyICgxOTgwIG5zKSwgbWluZ250PTB4MDggKDIw MDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9NgoJcG93ZXJzcGVjIDIg IHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50IEQwCnBjaTE6IDxkaXNwbGF5LCBWR0E+IGF0 IGRldmljZSAwLjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKdWhjaTA6IDxJbnRlbCA4MjgwMURCIChJ Q0g0KSBVU0IgY29udHJvbGxlciBVU0ItQT4gcG9ydCAweDE4MDAtMHgxODFmIGlycSA2IGF0IGRl dmljZSAyOS4wIG9uIHBjaTAKdWhjaTA6IFJlc2VydmVkIDB4MjAgYnl0ZXMgZm9yIHJpZCAweDIw IHR5cGUgNCBhdCAweDE4MDAKdWhjaTA6IFtHSUFOVC1MT0NLRURdCnVzYjA6IDxJbnRlbCA4Mjgw MURCIChJQ0g0KSBVU0IgY29udHJvbGxlciBVU0ItQT4gb24gdWhjaTAKdXNiMDogVVNCIHJldmlz aW9uIDEuMAp1aHViMDogSW50ZWwgVUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8x LjAwLCBhZGRyIDEKdWh1YjA6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVk CnVoY2kxOiA8SW50ZWwgODI4MDFEQiAoSUNINCkgVVNCIGNvbnRyb2xsZXIgVVNCLUI+IHBvcnQg MHgxODIwLTB4MTgzZiBpcnEgNiBhdCBkZXZpY2UgMjkuMSBvbiBwY2kwCnVoY2kxOiBSZXNlcnZl ZCAweDIwIGJ5dGVzIGZvciByaWQgMHgyMCB0eXBlIDQgYXQgMHgxODIwCnVoY2kxOiBbR0lBTlQt TE9DS0VEXQp1c2IxOiA8SW50ZWwgODI4MDFEQiAoSUNINCkgVVNCIGNvbnRyb2xsZXIgVVNCLUI+ IG9uIHVoY2kxCnVzYjE6IFVTQiByZXZpc2lvbiAxLjAKdWh1YjE6IEludGVsIFVIQ0kgcm9vdCBo dWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxCnVodWIxOiAyIHBvcnRzIHdpdGgg MiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aGNpMjogPEludGVsIDgyODAxREIgKElDSDQpIFVT QiBjb250cm9sbGVyIFVTQi1DPiBwb3J0IDB4MTg0MC0weDE4NWYgaXJxIDYgYXQgZGV2aWNlIDI5 LjIgb24gcGNpMAp1aGNpMjogUmVzZXJ2ZWQgMHgyMCBieXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0 IGF0IDB4MTg0MAp1aGNpMjogW0dJQU5ULUxPQ0tFRF0KdXNiMjogPEludGVsIDgyODAxREIgKElD SDQpIFVTQiBjb250cm9sbGVyIFVTQi1DPiBvbiB1aGNpMgp1c2IyOiBVU0IgcmV2aXNpb24gMS4w CnVodWIyOiBJbnRlbCBVSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFk ZHIgMQp1aHViMjogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKcGNpMDog PHNlcmlhbCBidXMsIFVTQj4gYXQgZGV2aWNlIDI5LjcgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNp YjI6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMzAuMCBvbiBwY2kwCnBjaWIyOiAg IHNlY29uZGFyeSBidXMgICAgIDIKcGNpYjI6ICAgc3Vib3JkaW5hdGUgYnVzICAgMgpwY2liMjog ICBJL08gZGVjb2RlICAgICAgICAweDQwMDAtMHg0ZmZmCnBjaWIyOiAgIG1lbW9yeSBkZWNvZGUg ICAgIDB4ZDAyMDAwMDAtMHhkMDVmZmZmZgpwY2liMjogICBwcmVmZXRjaGVkIGRlY29kZSAweGZm ZjAwMDAwLTB4ZmZmZmYKcGNpYjI6ICAgU3VidHJhY3RpdmVseSBkZWNvZGVkIGJyaWRnZS4KQUNQ SSBQQ0kgbGluayBpbml0aWFsIGNvbmZpZ3VyYXRpb246ClxcX1NCXy5QQ0kwLkxQQzAuTE5LRCBp cnEqIDY6IFsgNl0gIDYrIGxvdyxsZXZlbCxzaGFyYWJsZSAyLjIuMApcXF9TQl8uUENJMC5MUEMw LkxOS0IgaXJxKjEwOiBbMTBdIDEwKyBsb3csbGV2ZWwsc2hhcmFibGUgMi40LjAKXFxfU0JfLlBD STAuTFBDMC5MTktDIGlycSogNjogWyA2XSAgNisgbG93LGxldmVsLHNoYXJhYmxlIDIuNC4xClxc X1NCXy5QQ0kwLkxQQzAuTE5LRSBpcnEgIDA6IFsxMF0gMTArIGxvdyxsZXZlbCxzaGFyYWJsZSAy LjYuMApcXF9TQl8uUENJMC5MUEMwLkxOS0YgaXJxICAwOiBbMTBdICAwKyBsb3csbGV2ZWwsc2hh cmFibGUgMi42LjEKXFxfU0JfLlBDSTAuTFBDMC5MTktHIGlycSAgMDogWyA2XSAgMCsgbG93LGxl dmVsLHNoYXJhYmxlIDIuNi4yCnBjaTI6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIyCnBjaTI6IHBo eXNpY2FsIGJ1cz0yCgltYXBbMTBdOiB0eXBlIDEsIHJhbmdlIDMyLCBiYXNlIGQwMjA0MDAwLCBz aXplIDEzLCBlbmFibGVkCnBjaWIyOiBkZXZpY2UgKG51bGwpIHJlcXVlc3RlZCBkZWNvZGVkIG1l bW9yeSByYW5nZSAweGQwMjA0MDAwLTB4ZDAyMDVmZmYKcGNpYjI6IG1hdGNoZWQgZW50cnkgZm9y IDIuMi5JTlRBIChzcmMgXFxfU0JfLlBDSTAuTFBDMC5MTktEKQpwY2liMjogc2xvdCAyIElOVEEg aXMgYWxyZWFkeSByb3V0ZWQgdG8gaXJxIDYKZm91bmQtPgl2ZW5kb3I9MHgxNGU0LCBkZXY9MHg0 NDAxLCByZXZpZD0weDAxCglidXM9Miwgc2xvdD0yLCBmdW5jPTAKCWNsYXNzPTAyLTAwLTAwLCBo ZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAxMDYsIHN0YXRyZWc9MHgwODEwLCBjYWNo ZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHg0MCAoMTkyMCBucyksIG1pbmdudD0weDAwICgw IG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTYKCXBvd2Vyc3BlYyAyICBz dXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMAoJbWFwWzEwXTogdHlwZSAxLCByYW5nZSAz MiwgYmFzZSBkMDIwODAwMCwgc2l6ZSAxMiwgZW5hYmxlZApwY2liMjogZGV2aWNlIChudWxsKSBy ZXF1ZXN0ZWQgZGVjb2RlZCBtZW1vcnkgcmFuZ2UgMHhkMDIwODAwMC0weGQwMjA4ZmZmCnBjaWIy OiBtYXRjaGVkIGVudHJ5IGZvciAyLjQuSU5UQSAoc3JjIFxcX1NCXy5QQ0kwLkxQQzAuTE5LQikK cGNpYjI6IHNsb3QgNCBJTlRBIGlzIGFscmVhZHkgcm91dGVkIHRvIGlycSAxMApmb3VuZC0+CXZl bmRvcj0weDgwODYsIGRldj0weDQyMjAsIHJldmlkPTB4MDUKCWJ1cz0yLCBzbG90PTQsIGZ1bmM9 MAoJY2xhc3M9MDItODAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDExNiwg c3RhdHJlZz0weDAyOTAsIGNhY2hlbG5zej04IChkd29yZHMpCglsYXR0aW1lcj0weDQwICgxOTIw IG5zKSwgbWluZ250PTB4MDMgKDc1MCBucyksIG1heGxhdD0weDE4ICg2MDAwIG5zKQoJaW50cGlu PWEsIGlycT0xMAoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCgltYXBb MTBdOiB0eXBlIDEsIHJhbmdlIDMyLCBiYXNlIGQwMjA5MDAwLCBzaXplIDEyLCBtZW1vcnkgZGlz YWJsZWQKcGNpYjI6IGRldmljZSAobnVsbCkgcmVxdWVzdGVkIGRlY29kZWQgbWVtb3J5IHJhbmdl IDB4ZDAyMDkwMDAtMHhkMDIwOWZmZgpwY2liMjogbWF0Y2hlZCBlbnRyeSBmb3IgMi42LklOVEEg KHNyYyBcXF9TQl8uUENJMC5MUEMwLkxOS0UpCnBjaWIyOiBwb3NzaWJsZSBpbnRlcnJ1cHRzOiAx MApBQ1BJIFBDSSBsaW5rIGFyYml0cmF0ZWQgc2V0dGluZ3M6ClxcX1NCXy5QQ0kwLkxQQzAuTE5L RyAocmVmZXJlbmNlcyAxLCBwcmlvcml0eSA1MzYwKToKCWludGVycnVwdHM6CSAgICAgNgoJcGVu YWx0eToJICA1MzYwClxcX1NCXy5QQ0kwLkxQQzAuTE5LRSAocmVmZXJlbmNlcyAxLCBwcmlvcml0 eSAxODApOgoJaW50ZXJydXB0czoJICAgIDEwCglwZW5hbHR5OgkgICAxODAKXFxfU0JfLlBDSTAu TFBDMC5MTktGIChyZWZlcmVuY2VzIDEsIHByaW9yaXR5IDE4MCk6CglpbnRlcnJ1cHRzOgkgICAg MTAKCXBlbmFsdHk6CSAgIDE4MApwY2liMjogc2xvdCA2IElOVEEgcm91dGVkIHRvIGlycSAxMCB2 aWEgXFxfU0JfLlBDSTAuTFBDMC5MTktFCmZvdW5kLT4JdmVuZG9yPTB4MTA0YywgZGV2PTB4ODAz MSwgcmV2aWQ9MHgwMAoJYnVzPTIsIHNsb3Q9NiwgZnVuYz0wCgljbGFzcz0wNi0wNy0wMCwgaGRy dHlwZT0weDAyLCBtZmRldj0xCgljbWRyZWc9MHgwMTA0LCBzdGF0cmVnPTB4MDIxMCwgY2FjaGVs bnN6PTggKGR3b3JkcykKCWxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5nbnQ9MHg0MCAoMTYw MDAgbnMpLCBtYXhsYXQ9MHgwMyAoNzUwIG5zKQoJaW50cGluPWEsIGlycT0xMAoJcG93ZXJzcGVj IDIgIHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50IEQwCgltYXBbMTBdOiB0eXBlIDEsIHJh bmdlIDMyLCBiYXNlIGQwMjBhMDAwLCBzaXplIDExLCBlbmFibGVkCnBjaWIyOiBkZXZpY2UgKG51 bGwpIHJlcXVlc3RlZCBkZWNvZGVkIG1lbW9yeSByYW5nZSAweGQwMjBhMDAwLTB4ZDAyMGE3ZmYK CW1hcFsxNF06IHR5cGUgMSwgcmFuZ2UgMzIsIGJhc2UgZDAyMDAwMDAsIHNpemUgMTQsIGVuYWJs ZWQKcGNpYjI6IGRldmljZSAobnVsbCkgcmVxdWVzdGVkIGRlY29kZWQgbWVtb3J5IHJhbmdlIDB4 ZDAyMDAwMDAtMHhkMDIwM2ZmZgpwY2liMjogbWF0Y2hlZCBlbnRyeSBmb3IgMi42LklOVEEgKHNy YyBcXF9TQl8uUENJMC5MUEMwLkxOS0UpCnBjaWIyOiBzbG90IDYgSU5UQSBpcyBhbHJlYWR5IHJv dXRlZCB0byBpcnEgMTAKZm91bmQtPgl2ZW5kb3I9MHgxMDRjLCBkZXY9MHg4MDMyLCByZXZpZD0w eDAwCglidXM9Miwgc2xvdD02LCBmdW5jPTIKCWNsYXNzPTBjLTAwLTEwLCBoZHJ0eXBlPTB4MDAs IG1mZGV2PTEKCWNtZHJlZz0weDAxMTYsIHN0YXRyZWc9MHgwMjEwLCBjYWNoZWxuc3o9OCAoZHdv cmRzKQoJbGF0dGltZXI9MHg0MCAoMTkyMCBucyksIG1pbmdudD0weDAzICg3NTAgbnMpLCBtYXhs YXQ9MHgwNCAoMTAwMCBucykKCWludHBpbj1hLCBpcnE9MTAKCXBvd2Vyc3BlYyAyICBzdXBwb3J0 cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMAoJbWFwWzEwXTogdHlwZSAxLCByYW5nZSAzMiwgYmFz ZSBkMDIwNjAwMCwgc2l6ZSAxMywgZW5hYmxlZApwY2liMjogZGV2aWNlIChudWxsKSByZXF1ZXN0 ZWQgZGVjb2RlZCBtZW1vcnkgcmFuZ2UgMHhkMDIwNjAwMC0weGQwMjA3ZmZmCnBjaWIyOiBtYXRj aGVkIGVudHJ5IGZvciAyLjYuSU5UQSAoc3JjIFxcX1NCXy5QQ0kwLkxQQzAuTE5LRSkKcGNpYjI6 IHNsb3QgNiBJTlRBIGlzIGFscmVhZHkgcm91dGVkIHRvIGlycSAxMApmb3VuZC0+CXZlbmRvcj0w eDEwNGMsIGRldj0weDgwMzMsIHJldmlkPTB4MDAKCWJ1cz0yLCBzbG90PTYsIGZ1bmM9MwoJY2xh c3M9MDEtODAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDEwNiwgc3RhdHJl Zz0weDAyMTAsIGNhY2hlbG5zej04IChkd29yZHMpCglsYXR0aW1lcj0weDQwICgxOTIwIG5zKSwg bWluZ250PTB4MDcgKDE3NTAgbnMpLCBtYXhsYXQ9MHgwNCAoMTAwMCBucykKCWludHBpbj1hLCBp cnE9MTAKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMApiZmUw OiA8QnJvYWRjb20gQkNNNDQwMSBGYXN0IEV0aGVybmV0PiBtZW0gMHhkMDIwNDAwMC0weGQwMjA1 ZmZmIGlycSA2IGF0IGRldmljZSAyLjAgb24gcGNpMgpiZmUwOiBSZXNlcnZlZCAweDIwMDAgYnl0 ZXMgZm9yIHJpZCAweDEwIHR5cGUgMyBhdCAweGQwMjA0MDAwCm1paWJ1czA6IDxNSUkgYnVzPiBv biBiZmUwCmJtdHBoeTA6IDxCQ000NDAxIDEwLzEwMGJhc2VUWCBQSFk+IG9uIG1paWJ1czAKYm10 cGh5MDogIDEwYmFzZVQsIDEwYmFzZVQtRkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgsIGF1 dG8KYmZlMDogYnBmIGF0dGFjaGVkCmJmZTA6IEV0aGVybmV0IGFkZHJlc3M6IDAwOmMwOjlmOjZh OjhlOjFjCmJmZTA6IFtHSUFOVC1MT0NLRURdCnBjaTI6IDxuZXR3b3JrPiBhdCBkZXZpY2UgNC4w IChubyBkcml2ZXIgYXR0YWNoZWQpCmNiYjA6IDxQQ0ktQ2FyZEJ1cyBCcmlkZ2U+IG1lbSAweGQw MjA5MDAwLTB4ZDAyMDlmZmYgaXJxIDEwIGF0IGRldmljZSA2LjAgb24gcGNpMgpjYmIwOiBSZXNl cnZlZCAweDEwMDAgYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgMyBhdCAweGQwMjA5MDAwCmNhcmRi dXMwOiA8Q2FyZEJ1cyBidXM+IG9uIGNiYjAKcGNjYXJkMDogPDE2LWJpdCBQQ0NhcmQgYnVzPiBv biBjYmIwCmNiYjA6IFtNUFNBRkVdCmNiYjA6IFBDSSBDb25maWd1cmF0aW9uIHNwYWNlOgogIDB4 MDA6IDB4ODAzMTEwNGMgMHgwMjEwMDEwNyAweDA2MDcwMDAwIDB4MDA4MjQwMDggCiAgMHgxMDog MHhkMDIwOTAwMCAweDAyMDAwMGEwIDB4MjAwMzAzMDIgMHhmZmZmZjAwMCAKICAweDIwOiAweDAw MDAwMDAwIDB4ZmZmZmYwMDAgMHgwMDAwMDAwMCAweGZmZmZmZmZjIAogIDB4MzA6IDB4MDAwMDAw MDAgMHhmZmZmZmZmYyAweDAwMDAwMDAwIDB4MDc0MDAxMGEgCiAgMHg0MDogMHgwMDY0MTAyNSAw eDAwMDAwMDAxIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAKICAweDUwOiAweDAwMDAwMDAwIDB4MDAw MDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIAogIDB4NjA6IDB4MDAwMDAwMDAgMHgwMDAwMDAw MCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgCiAgMHg3MDogMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4 MDAwMDAwMDAgMHgwMDAwMDAwMCAKICAweDgwOiAweDE4NDQxMDYwIDB4MDJjMDAwMTkgMHgwMDBm MDAwMCAweDAxYTIxYjIyIAogIDB4OTA6IDB4NjA2NDgwYzAgMHgwMDAwMDAwMCAweDAwMDAwMDAw IDB4MDAwMDAwMDAgCiAgMHhhMDogMHhmZTEyMDAwMSAweDAwYzAwMDAwIDB4MDAwMDAwMDAgMHgw MDAwMDAwMCAKICAweGIwOiAweDA4MDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAw MDAwIAogIDB4YzA6IDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAg CiAgMHhkMDogMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAKICAw eGUwOiAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIAogIDB4ZjA6 IDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgCmZ3b2hjaTA6IHZl bmRvcj0xMDRjLCBkZXY9ODAzMgpmd29oY2kwOiA8MTM5NCBPcGVuIEhvc3QgQ29udHJvbGxlciBJ bnRlcmZhY2U+IG1lbSAweGQwMjAwMDAwLTB4ZDAyMDNmZmYsMHhkMDIwYTAwMC0weGQwMjBhN2Zm IGlycSAxMCBhdCBkZXZpY2UgNi4yIG9uIHBjaTIKZndvaGNpMDogUmVzZXJ2ZWQgMHg4MDAgYnl0 ZXMgZm9yIHJpZCAweDEwIHR5cGUgMyBhdCAweGQwMjBhMDAwCmZ3b2hjaTA6IFtHSUFOVC1MT0NL RURdCmZ3b2hjaTA6IE9IQ0kgdmVyc2lvbiAxLjEwIChST009MSkKZndvaGNpMDogTm8uIG9mIElz b2Nocm9ub3VzIGNoYW5uZWxzIGlzIDQuCmZ3b2hjaTA6IEVVSTY0IDAwOmMwOjlmOjAwOjAwOjMy OjE0OmRlCmZ3b2hjaTA6IFBoeSAxMzk0YSBhdmFpbGFibGUgUzQwMCwgMiBwb3J0cy4KZndvaGNp MDogTGluayBTNDAwLCBtYXhfcmVjIDIwNDggYnl0ZXMuCmZpcmV3aXJlMDogPElFRUUxMzk0KEZp cmVXaXJlKSBidXM+IG9uIGZ3b2hjaTAKZndlMDogPEV0aGVybmV0IG92ZXIgRmlyZVdpcmU+IG9u IGZpcmV3aXJlMAppZl9md2UwOiBGYWtlIEV0aGVybmV0IGFkZHJlc3M6IDAyOmMwOjlmOjMyOjE0 OmRlCmZ3ZTA6IGJwZiBhdHRhY2hlZApmd2UwOiBFdGhlcm5ldCBhZGRyZXNzOiAwMjpjMDo5Zjoz MjoxNDpkZQpzYnAwOiA8U0JQLTIvU0NTSSBvdmVyIEZpcmVXaXJlPiBvbiBmaXJld2lyZTAKZndv aGNpMDogSW5pdGlhdGUgYnVzIHJlc2V0CmZ3b2hjaTA6IG5vZGVfaWQ9MHhjMDAwZmZjMCwgZ2Vu PTEsIENZQ0xFTUFTVEVSIG1vZGUKZmlyZXdpcmUwOiAxIG5vZGVzLCBtYXhob3AgPD0gMCwgY2Fi bGUgSVJNID0gMCAobWUpCmZpcmV3aXJlMDogYnVzIG1hbmFnZXIgMCAobWUpCnBjaTI6IDxtYXNz IHN0b3JhZ2U+IGF0IGRldmljZSA2LjMgKG5vIGRyaXZlciBhdHRhY2hlZCkKaXNhYjA6IDxQQ0kt SVNBIGJyaWRnZT4gYXQgZGV2aWNlIDMxLjAgb24gcGNpMAppc2EwOiA8SVNBIGJ1cz4gb24gaXNh YjAKYXRhcGNpMDogPEludGVsIElDSDQgVURNQTEwMCBjb250cm9sbGVyPiBwb3J0IDB4MTg2MC0w eDE4NmYsMHgzNzYsMHgxNzAtMHgxNzcsMHgzZjYsMHgxZjAtMHgxZjcgYXQgZGV2aWNlIDMxLjEg b24gcGNpMAphdGFwY2kwOiBSZXNlcnZlZCAweDEwIGJ5dGVzIGZvciByaWQgMHgyMCB0eXBlIDQg YXQgMHgxODYwCmF0YTA6IGNoYW5uZWwgIzAgb24gYXRhcGNpMAphdGFwY2kwOiBSZXNlcnZlZCAw eDggYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgNCBhdCAweDFmMAphdGFwY2kwOiBSZXNlcnZlZCAw eDEgYnl0ZXMgZm9yIHJpZCAweDE0IHR5cGUgNCBhdCAweDNmNgphdGEwOiByZXNldCB0cDEgbWFz az0wMyBvc3RhdDA9NTAgb3N0YXQxPTAwCmF0YTAtbWFzdGVyOiBzdGF0PTB4NTAgZXJyPTB4MDEg bHNiPTB4MDAgbXNiPTB4MDAKYXRhMC1zbGF2ZTogIHN0YXQ9MHgwMCBlcnI9MHgwMSBsc2I9MHgw MCBtc2I9MHgwMAphdGEwOiByZXNldCB0cDIgc3RhdDA9NTAgc3RhdDE9MDAgZGV2aWNlcz0weDE8 QVRBX01BU1RFUj4KYXRhMDogW01QU0FGRV0KYXRhMTogY2hhbm5lbCAjMSBvbiBhdGFwY2kwCmF0 YXBjaTA6IFJlc2VydmVkIDB4OCBieXRlcyBmb3IgcmlkIDB4MTggdHlwZSA0IGF0IDB4MTcwCmF0 YXBjaTA6IFJlc2VydmVkIDB4MSBieXRlcyBmb3IgcmlkIDB4MWMgdHlwZSA0IGF0IDB4Mzc2CmF0 YTE6IHJlc2V0IHRwMSBtYXNrPTAzIG9zdGF0MD01MCBvc3RhdDE9MDAKYXRhMS1tYXN0ZXI6IHN0 YXQ9MHgwMCBlcnI9MHgwMSBsc2I9MHgxNCBtc2I9MHhlYgphdGExLXNsYXZlOiAgc3RhdD0weDAw IGVycj0weDAwIGxzYj0weDAwIG1zYj0weDAwCmF0YTE6IHJlc2V0IHRwMiBzdGF0MD0wMCBzdGF0 MT0wMCBkZXZpY2VzPTB4NDxBVEFQSV9NQVNURVI+CmF0YTE6IFtNUFNBRkVdCnBjaTA6IDxzZXJp YWwgYnVzLCBTTUJ1cz4gYXQgZGV2aWNlIDMxLjMgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpMDog PG11bHRpbWVkaWEsIGF1ZGlvPiBhdCBkZXZpY2UgMzEuNSAobm8gZHJpdmVyIGF0dGFjaGVkKQpw Y2kwOiA8c2ltcGxlIGNvbW1zPiBhdCBkZXZpY2UgMzEuNiAobm8gZHJpdmVyIGF0dGFjaGVkKQph Y3BpX2xpZDA6IDxDb250cm9sIE1ldGhvZCBMaWQgU3dpdGNoPiBvbiBhY3BpMAphY3BpX2J1dHRv bjA6IDxTbGVlcCBCdXR0b24+IG9uIGFjcGkwCnVua25vd246IG5vdCBwcm9iZWQgKGRpc2FibGVk KQphdGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgwNDIpPiBwb3J0IDB4NjQsMHg2MCBp cnEgMSBvbiBhY3BpMAphdGtiZDA6IDxBVCBLZXlib2FyZD4gaXJxIDEgb24gYXRrYmRjMAphdGti ZDogdGhlIGN1cnJlbnQga2JkIGNvbnRyb2xsZXIgY29tbWFuZCBieXRlIDAwNDcKYXRrYmQ6IGtl eWJvYXJkIElEIDB4NDFhYiAoMikKa2JkMCBhdCBhdGtiZDAKa2JkMDogYXRrYmQwLCBBVCAxMDEv MTAyICgyKSwgY29uZmlnOjB4MCwgZmxhZ3M6MHgzZDAwMDAKYXRrYmQwOiBbR0lBTlQtTE9DS0VE XQpwc20wOiB1bmFibGUgdG8gYWxsb2NhdGUgSVJRCnVua25vd246IG5vdCBwcm9iZWQgKGRpc2Fi bGVkKQpwc21jcG5wMDogPFBTLzIgbW91c2UgcG9ydD4gaXJxIDEyIG9uIGFjcGkwCnBzbTA6IGN1 cnJlbnQgY29tbWFuZCBieXRlOjAwNDcKcHNtMDogPFBTLzIgTW91c2U+IGlycSAxMiBvbiBhdGti ZGMwCnBzbTA6IFtHSUFOVC1MT0NLRURdCnBzbTA6IG1vZGVsIEdlbmVyaWMgUFMvMiBtb3VzZSwg ZGV2aWNlIElEIDAtMDAsIDIgYnV0dG9ucwpwc20wOiBjb25maWc6MDAwMDAwMDAsIGZsYWdzOjAw MDAwMDA4LCBwYWNrZXQgc2l6ZTozCnBzbTA6IHN5bmNtYXNrOmMwLCBzeW5jYml0czowMAp1bmtu b3duOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKdW5rbm93bjogbm90IHByb2JlZCAoZGlzYWJsZWQp CnVua25vd246IG5vdCBwcm9iZWQgKGRpc2FibGVkKQp1bmtub3duOiBub3QgcHJvYmVkIChkaXNh YmxlZCkKdW5rbm93bjogbm90IHByb2JlZCAoZGlzYWJsZWQpCnNpbzA6IGlycSBtYXBzOiAweDYw MSAweDYwOSAweDYwMSAweDYwMQpzaW8wIHBvcnQgMHgyZjgtMHgyZmYgaXJxIDMgZHJxIDEgZmxh Z3MgMHgxMCBvbiBhY3BpMApzaW8wOiB0eXBlIDE2NTUwQQp1bmtub3duOiBub3QgcHJvYmVkIChk aXNhYmxlZCkKdW5rbm93bjogbm90IHByb2JlZCAoZGlzYWJsZWQpCnVua25vd246IG5vdCBwcm9i ZWQgKGRpc2FibGVkKQp1bmtub3duOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKdW5rbm93bjogbm90 IHByb2JlZCAoZGlzYWJsZWQpCnVua25vd246IG5vdCBwcm9iZWQgKGRpc2FibGVkKQp1bmtub3du OiBub3QgcHJvYmVkIChkaXNhYmxlZCkKbnB4MDogW0ZBU1RdCm5weDA6IDxtYXRoIHByb2Nlc3Nv cj4gb24gbW90aGVyYm9hcmQKbnB4MDogSU5UIDE2IGludGVyZmFjZQphdGE6IGF0YTAgYWxyZWFk eSBleGlzdHM7IHNraXBwaW5nIGl0CmF0YTogYXRhMSBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcg aXQKYXRrYmRjOiBhdGtiZGMwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdApzaW86IHNpbzAg YWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0ClRyeWluZyBSZWFkX1BvcnQgYXQgMjAzClRyeWlu ZyBSZWFkX1BvcnQgYXQgMjQzClRyeWluZyBSZWFkX1BvcnQgYXQgMjgzClRyeWluZyBSZWFkX1Bv cnQgYXQgMmMzClRyeWluZyBSZWFkX1BvcnQgYXQgMzAzClRyeWluZyBSZWFkX1BvcnQgYXQgMzQz ClRyeWluZyBSZWFkX1BvcnQgYXQgMzgzClRyeWluZyBSZWFkX1BvcnQgYXQgM2MzCmV4X2lzYV9p ZGVudGlmeSgpCnVua25vd246IHN0YXR1cyByZWcgdGVzdCBmYWlsZWQgZmYKdW5rbm93bjogc3Rh dHVzIHJlZyB0ZXN0IGZhaWxlZCBmZgp1bmtub3duOiBzdGF0dXMgcmVnIHRlc3QgZmFpbGVkIGZm CnVua25vd246IHN0YXR1cyByZWcgdGVzdCBmYWlsZWQgZmYKdW5rbm93bjogc3RhdHVzIHJlZyB0 ZXN0IGZhaWxlZCBmZgp1bmtub3duOiBzdGF0dXMgcmVnIHRlc3QgZmFpbGVkIGZmCmFoY19pc2Ff cHJvYmUgMTogaW9wb3J0IDB4MWMwMCBhbGxvYyBmYWlsZWQKc2M6IHNjMCBhbHJlYWR5IGV4aXN0 czsgc2tpcHBpbmcgaXQKdmdhOiB2Z2EwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdAppc2Ff cHJvYmVfY2hpbGRyZW46IGRpc2FibGluZyBQblAgZGV2aWNlcwppc2FfcHJvYmVfY2hpbGRyZW46 IHByb2Jpbmcgbm9uLVBuUCBkZXZpY2VzCm9ybTA6IDxJU0EgT3B0aW9uIFJPTXM+IGF0IGlvbWVt IDB4ZTAwMDAtMHhlM2ZmZiwweGRmODAwLTB4ZGZmZmYsMHhkMDAwMC0weGQxN2ZmLDB4YzAwMDAt MHhjZmZmZiBvbiBpc2EwCnBtdGltZXIwIG9uIGlzYTAKYWR2MDogbm90IHByb2JlZCAoZGlzYWJs ZWQpCmFoYTA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQphaWMwOiBub3QgcHJvYmVkIChkaXNhYmxl ZCkKYnQwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKY3MwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkK ZWQwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKZmRjMCBmYWlsZWQgdG8gcHJvYmUgYXQgcG9ydCAw eDNmMC0weDNmNSBpcnEgNiBkcnEgMiBvbiBpc2EwCmZlMDogbm90IHByb2JlZCAoZGlzYWJsZWQp CmllMDogbm90IHByb2JlZCAoZGlzYWJsZWQpCmxuYzA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQpw Y2ljMCBmYWlsZWQgdG8gcHJvYmUgYXQgcG9ydCAweDNlMCBpb21lbSAweGQwMDAwIG9uIGlzYTAK cGNpYzE6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQpwcGMwOiBwYXJhbGxlbCBwb3J0IG5vdCBmb3Vu ZC4KcHBjMDogPFBhcmFsbGVsIHBvcnQ+IGZhaWxlZCB0byBwcm9iZSBhdCBpcnEgNyBvbiBpc2Ew CnNjMDogPFN5c3RlbSBjb25zb2xlPiBhdCBmbGFncyAweDEwMCBvbiBpc2EwCnNjMDogVkdBIDwx NiB2aXJ0dWFsIGNvbnNvbGVzLCBmbGFncz0weDMwMD4Kc2MwOiBmYjAsIGtiZDAsIHRlcm1pbmFs IGVtdWxhdG9yOiBzYyAoc3lzY29ucyB0ZXJtaW5hbCkKc2lvMSBmYWlsZWQgdG8gcHJvYmUgYXQg cG9ydCAweDJmOCBpcnEgMyBvbiBpc2EwCnNpbzI6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQpzaW8z OiBub3QgcHJvYmVkIChkaXNhYmxlZCkKc24wOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKdmdhMDog PEdlbmVyaWMgSVNBIFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBpb21lbSAweGEwMDAwLTB4YmZm ZmYgb24gaXNhMApmYjA6IHZnYTAsIHZnYSwgdHlwZTpWR0EgKDUpLCBmbGFnczoweDcwMDdmCmZi MDogcG9ydDoweDNjMC0weDNkZiwgY3J0YzoweDNkNCwgbWVtOjB4YTAwMDAgMHgyMDAwMApmYjA6 IGluaXQgbW9kZToyNCwgYmlvcyBtb2RlOjMsIGN1cnJlbnQgbW9kZToyNApmYjA6IHdpbmRvdzow eGMwMGI4MDAwIHNpemU6MzJrIGdyYW46MzJrLCBidWY6MCBzaXplOjMyawp2Z2EwOiB2Z2E6IFdB Uk5JTkc6IHZpZGVvIG1vZGUgc3dpdGNoaW5nIGlzIG5vdCBmdWxseSBzdXBwb3J0ZWQgb24gdGhp cyBhZGFwdGVyClZHQSBwYXJhbWV0ZXJzIHVwb24gcG93ZXItdXAKNTAgMTggMTAgMDAgMDAgMDAg MDMgMDAgMDIgNjcgNWIgNGYgNGYgOWYgNTIgMTYgCjllIDFmIDAwIDRmIDBkIDBlIDAwIDAwIDA3 IDgwIDkzIDg3IDhmIDI4IDFmIDhmIAo5ZiBhMyBmZiAwMCAwMSAwMiAwMyAwNCAwNSAxNCAwNyAz OCAzOSAzYSAzYiAzYyAKM2QgM2UgM2YgMGMgMDAgMGYgMDggMDAgMDAgMDAgMDAgMDAgMTAgMGUg MDAgZmYgClZHQSBwYXJhbWV0ZXJzIGluIEJJT1MgZm9yIG1vZGUgMjQKNTAgMTggMTAgMDAgMTAg MDAgMDMgMDAgMDIgNjcgNWYgNGYgNTAgODIgNTUgODEgCmJmIDFmIDAwIDRmIDBkIDBlIDAwIDAw IDAwIDAwIDljIDhlIDhmIDI4IDFmIDk2IApiOSBhMyBmZiAwMCAwMSAwMiAwMyAwNCAwNSAxNCAw NyAzOCAzOSAzYSAzYiAzYyAKM2QgM2UgM2YgMGMgMDAgMGYgMDggMDAgMDAgMDAgMDAgMDAgMTAg MGUgMDAgZmYgCkVHQS9WR0EgcGFyYW1ldGVycyB0byBiZSB1c2VkIGZvciBtb2RlIDI0CjUwIDE4 IDEwIDAwIDAwIDAwIDAzIDAwIDAyIDY3IDViIDRmIDRmIDlmIDUyIDE2IAo5ZSAxZiAwMCA0ZiAw ZCAwZSAwMCAwMCAwNyA4MCA5MyA4NyA4ZiAyOCAxZiA4ZiAKOWYgYTMgZmYgMDAgMDEgMDIgMDMg MDQgMDUgMTQgMDcgMzggMzkgM2EgM2IgM2MgCjNkIDNlIDNmIDBjIDAwIDBmIDA4IDAwIDAwIDAw IDAwIDAwIDEwIDBlIDAwIGZmIAp2dDA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQppc2FfcHJvYmVf Y2hpbGRyZW46IHByb2JpbmcgUG5QIGRldmljZXMKRGV2aWNlIGNvbmZpZ3VyYXRpb24gZmluaXNo ZWQuCnByb2NmcyByZWdpc3RlcmVkClRpbWVjb3VudGVyICJUU0MiIGZyZXF1ZW5jeSAxNTk4NjUw MDU5IEh6IHF1YWxpdHkgODAwClRpbWVjb3VudGVycyB0aWNrIGV2ZXJ5IDEwLjAwMCBtc2VjCldB Uk5JTkc6IGFwbV9zYXZlciBtb2R1bGUgcmVxdWlyZXMgYXBtIGVuYWJsZWQKc3BsYXNoOiBpbWFn ZSBkZWNvZGVyIGZvdW5kOiBhcG1fc2F2ZXIKSVBzZWM6IEluaXRpYWxpemVkIFNlY3VyaXR5IEFz c29jaWF0aW9uIFByb2Nlc3NpbmcuCnBmbG9nMDogYnBmIGF0dGFjaGVkCmxvMDogYnBmIGF0dGFj aGVkCmNwdTA6IHNldCBzcGVlZCB0byAxMDAuMCUKYWNwaV9jcHU6IHRocm90dGxpbmcgZW5hYmxl ZCwgOCBzdGVwcyAoMTAwJSB0byAxMi41JSksIGN1cnJlbnRseSAxMDAuMCUKYXRhMC1tYXN0ZXI6 IHBpbz0weDBjIHdkbWE9MHgyMiB1ZG1hPTB4NDUgY2FibGU9ODBwaW4KYXRhMC1tYXN0ZXI6IHNl dHRpbmcgUElPNCBvbiBJbnRlbCBJQ0g0IGNoaXAKYXRhMC1tYXN0ZXI6IHNldHRpbmcgVURNQTEw MCBvbiBJbnRlbCBJQ0g0IGNoaXAKYWQwOiA8VE9TSElCQSBNSzYwMjVHQVMvS0EyMDBBPiBBVEEt NiBkaXNrIGF0IGF0YTAtbWFzdGVyCmFkMDogNTcyMzFNQiAoMTE3MjEwMjQwIHNlY3RvcnMpLCAx MTYyODAgQywgMTYgSCwgNjMgUywgNTEyIEIKYWQwOiAxNiBzZWNzL2ludCwgMSBkZXB0aCBxdWV1 ZSwgVURNQTEwMApHRU9NOiBuZXcgZGlzayBhZDAKYXI6IEZyZWVCU0QgY2hlY2sxIGZhaWxlZAph dGExLW1hc3RlcjogcGlvPTB4MGMgd2RtYT0weDIyIHVkbWE9MHg0MiBjYWJsZT00MHBpbgphdGEx LW1hc3Rlcjogc2V0dGluZyBQSU80IG9uIEludGVsIElDSDQgY2hpcAphdGExLW1hc3Rlcjogc2V0 dGluZyBVRE1BMzMgb24gSW50ZWwgSUNINCBjaGlwCmFjZDA6IDxTbGltdHlwZSBEVkRSVyBTT1NX LTg1MlMvUFJTOT4gRFZEUiBkcml2ZSBhdCBhdGExIGFzIG1hc3RlcgphY2QwOiByZWFkIDQxMzRL Qi9zICg0MTM0S0Ivcykgd3JpdGUgNDEzNEtCL3MgKDQxMzRLQi9zKSwgMjA0OEtCIGJ1ZmZlciwg VURNQTMzCmFjZDA6IFJlYWRzOiBDRFIsIENEUlcsIENEREEgc3RyZWFtLCBEVkRST00sIERWRFIs IHBhY2tldAphY2QwOiBXcml0ZXM6IENEUiwgQ0RSVywgRFZEUiwgdGVzdCB3cml0ZSwgYnVybnBy b29mCmFjZDA6IEF1ZGlvOiBwbGF5LCAyNTYgdm9sdW1lIGxldmVscwphY2QwOiBNZWNoYW5pc206 IGVqZWN0YWJsZSB0cmF5LCB1bmxvY2tlZAphY2QwOiBNZWRpdW06IG5vL2JsYW5rIGRpc2MKWzBd IGY6MDAgdHlwOjE4IHMoQ0hTKTowLzEvMSBlKENIUyk6MzgyLzI1NC82MyBzOjYzIGw6NjE1Mjgz MgpbMV0gZjowMCB0eXA6NiBzKENIUyk6MzgzLzAvMSBlKENIUyk6MTAyMy8yNTQvNjMgczo2MTUy ODk1IGw6MzE0NTUyNzAKWzJdIGY6ODAgdHlwOjE2NSBzKENIUyk6MTAyMy8yNTUvNjMgZShDSFMp OjEwMjMvMjU0LzYzIHM6Mzc2MDgxNjUgbDo3OTYwMjA3NQpbM10gZjowMCB0eXA6MCBzKENIUyk6 MC8wLzAgZShDSFMpOjAvMC8wIHM6MCBsOjAKR0VPTTogQ29uZmlndXJlIGFkMHMxLCBzdGFydCAz MjI1NiBsZW5ndGggMzE1MDI0OTk4NCBlbmQgMzE1MDI4MjIzOQpHRU9NOiBDb25maWd1cmUgYWQw czIsIHN0YXJ0IDMxNTAyODIyNDAgbGVuZ3RoIDE2MTA1MDk4MjQwIGVuZCAxOTI1NTM4MDQ3OQpH RU9NOiBDb25maWd1cmUgYWQwczMsIHN0YXJ0IDE5MjU1MzgwNDgwIGxlbmd0aCA0MDc1NjI2MjQw MCBlbmQgNjAwMTE2NDI4NzkKR0VPTTogQ29uZmlndXJlIGFkMHMzYSwgc3RhcnQgMCBsZW5ndGgg MTM0MjE3NzI4IGVuZCAxMzQyMTc3MjcKR0VPTTogQ29uZmlndXJlIGFkMHMzYiwgc3RhcnQgMTMy MjA0NDYyMDggbGVuZ3RoIDEwNzM3NDE4MjQgZW5kIDE0Mjk0MTg4MDMxCkdFT006IENvbmZpZ3Vy ZSBhZDBzM2MsIHN0YXJ0IDAgbGVuZ3RoIDQwNzU2MjYyNDAwIGVuZCA0MDc1NjI2MjM5OQpHRU9N OiBDb25maWd1cmUgYWQwczNkLCBzdGFydCAxMzQyMTc3MjggbGVuZ3RoIDEzNDIxNzcyOCBlbmQg MjY4NDM1NDU1CkdFT006IENvbmZpZ3VyZSBhZDBzM2UsIHN0YXJ0IDI2ODQzNTQ1NiBsZW5ndGgg NjcxMDg4NjQgZW5kIDMzNTU0NDMxOQpHRU9NOiBDb25maWd1cmUgYWQwczNmLCBzdGFydCAzMzU1 NDQzMjAgbGVuZ3RoIDEyODg0OTAxODg4IGVuZCAxMzIyMDQ0NjIwNwpHRU9NOiBDb25maWd1cmUg YWQwczNnLCBzdGFydCAxNDI5NDE4ODAzMiBsZW5ndGggMjY0NjIwNzQzNjggZW5kIDQwNzU2MjYy Mzk5CmFjcGlfZWMwOiBpbmZvOiBuZXcgbWF4IGRlbGF5IGlzIDExMDAwIHVzCihwcm9iZTU6c2Jw MDowOjU6MCk6IGVycm9yIDIyCihwcm9iZTU6c2JwMDowOjU6MCk6IFVucmV0cnlhYmxlIEVycm9y Cihwcm9iZTY6c2JwMDowOjY6MCk6IGVycm9yIDIyCihwcm9iZTY6c2JwMDowOjY6MCk6IFVucmV0 cnlhYmxlIEVycm9yCihwcm9iZTA6c2JwMDowOjA6MCk6IGVycm9yIDIyCihwcm9iZTA6c2JwMDow OjA6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTE6c2JwMDowOjE6MCk6IGVycm9yIDIyCihw cm9iZTE6c2JwMDowOjE6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTI6c2JwMDowOjI6MCk6 IGVycm9yIDIyCihwcm9iZTI6c2JwMDowOjI6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTM6 c2JwMDowOjM6MCk6IGVycm9yIDIyCihwcm9iZTM6c2JwMDowOjM6MCk6IFVucmV0cnlhYmxlIEVy cm9yCihwcm9iZTQ6c2JwMDowOjQ6MCk6IGVycm9yIDIyCihwcm9iZTQ6c2JwMDowOjQ6MCk6IFVu cmV0cnlhYmxlIEVycm9yCk1vdW50aW5nIHJvb3QgZnJvbSB1ZnM6L2Rldi9hZDBzM2EKV0FSTklO RzogLyB3YXMgbm90IHByb3Blcmx5IGRpc21vdW50ZWQKc3RhcnRfaW5pdDogdHJ5aW5nIC9zYmlu L2luaXQKV0FSTklORzogL2hvbWUgd2FzIG5vdCBwcm9wZXJseSBkaXNtb3VudGVkCldBUk5JTkc6 IC90bXAgd2FzIG5vdCBwcm9wZXJseSBkaXNtb3VudGVkCldBUk5JTkc6IC91c3Igd2FzIG5vdCBw cm9wZXJseSBkaXNtb3VudGVkCldBUk5JTkc6IC92YXIgd2FzIG5vdCBwcm9wZXJseSBkaXNtb3Vu dGVkCg== ------=_20041225225727_98939-- From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 26 09:16:32 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D9E0416A4CE for ; Sun, 26 Dec 2004 09:16:32 +0000 (GMT) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id B238443D41 for ; Sun, 26 Dec 2004 09:16:31 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.12.11/8.12.10) with ESMTP id iBQ9GRu1019748; Sun, 26 Dec 2004 19:46:28 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-hackers@freebsd.org Date: Sun, 26 Dec 2004 19:46:25 +1030 User-Agent: KMail/1.7.1 References: <62903.81.84.175.77.1104000639.squirrel@81.84.175.77> <200412261731.25493.doconnor@gsoft.com.au> <61469.81.84.175.77.1104037002.squirrel@81.84.175.77> In-Reply-To: <61469.81.84.175.77.1104037002.squirrel@81.84.175.77> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3201156.qh5PmB1J0Z"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200412261946.26516.doconnor@gsoft.com.au> X-Spam-Score: -5.4 () IN_REP_TO,PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03,USER_AGENT,USER_AGENT_KMAIL X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) cc: security@revolutionsp.com Subject: Re: Unable to get APM working -- help! X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2004 09:16:33 -0000 --nextPart3201156.qh5PmB1J0Z Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sun, 26 Dec 2004 15:26, security@revolutionsp.com wrote: > I'll try it out; meanwhile, I've discovered the sysctl to change this > manually. I've checked it works by trying to compile something at the > lowest CPU clock speed. It was slow to hell :-) That's probably clock throttling which is different.. [Enhanced] Speed Step reduces the clock speed and the CPU core voltage.. cl= ock=20 throttling just idles the CPU for a certain proportion of the time. If you= =20 want slow try forcing them both to the slowest speed.. Pentium-M 75Mhz :) > > Any chance there is a new BIOS available for that system? > > A quick googling session brought up nothing. How about say, checking the makers web site? > > No.. If I try and look at a non existent battery slot it says 'device n= ot > > configured' so maybe it thinks you have no batteries for some strange > > reason. > > I've installed klaptop and it shows battery as -1 and 'not charging' > acpiconf -i[0-9] didn't do any good either :/ Without ACPI support being able to read your battery status no userland=20 program will work. Your dmesg shows acpi_cmbat entries, ie acpi_cmbat0: on acpi0 acpi_cmbat1: on acpi0 which I think is pretty fundamental to being able to read battery status ;) =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart3201156.qh5PmB1J0Z Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBzoFq5ZPcIHs/zowRAhnBAKCqzfgW0LgGokZYQNs0pyMKYxsl0QCgiMC/ 13rxTWyiGN0EPSMMQUPnvqw= =EDXR -----END PGP SIGNATURE----- --nextPart3201156.qh5PmB1J0Z-- From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 26 19:16:39 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A4F0A16A4CE for ; Sun, 26 Dec 2004 19:16:39 +0000 (GMT) Received: from mail.revolutionsp.com (ganymede.revolutionsp.com [64.246.0.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C6CA43D2F for ; Sun, 26 Dec 2004 19:16:39 +0000 (GMT) (envelope-from security@revolutionsp.com) Received: from mail.revolutionsp.com (localhost [127.0.0.1]) by mail.revolutionsp.com (Postfix) with ESMTP id B73BE15CA7 for ; Sun, 26 Dec 2004 10:11:58 -0600 (CST) Received: from 81.84.175.77 (SquirrelMail authenticated user security@revolutionsp.com); by mail.revolutionsp.com with HTTP; Sun, 26 Dec 2004 10:11:58 -0600 (CST) Message-ID: <63322.81.84.175.77.1104077518.squirrel@81.84.175.77> In-Reply-To: <200412261946.26516.doconnor@gsoft.com.au> References: <62903.81.84.175.77.1104000639.squirrel@81.84.175.77> <200412261731.25493.doconnor@gsoft.com.au> <61469.81.84.175.77.1104037002.squirrel@81.84.175.77> <200412261946.26516.doconnor@gsoft.com.au> Date: Sun, 26 Dec 2004 10:11:58 -0600 (CST) From: security@revolutionsp.com To: freebsd-hackers@freebsd.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: Unable to get APM working -- help! X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2004 19:16:39 -0000 > On Sun, 26 Dec 2004 15:26, security@revolutionsp.com wrote: >> I'll try it out; meanwhile, I've discovered the sysctl to change this >> manually. I've checked it works by trying to compile something at the >> lowest CPU clock speed. It was slow to hell :-) > > That's probably clock throttling which is different.. Yes, the sysctl included "throttle". As I said, I'm new to the laptop world.. Is the power saving difference a lot if I just throttle the clock, instead of using enhanced speed step? > > [Enhanced] Speed Step reduces the clock speed and the CPU core voltage.. > clock > throttling just idles the CPU for a certain proportion of the time. If you > want slow try forcing them both to the slowest speed.. Pentium-M 75Mhz :) > >> > Any chance there is a new BIOS available for that system? >> >> A quick googling session brought up nothing. > > How about say, checking the makers web site? > I also did, nothing :-P >> > No.. If I try and look at a non existent battery slot it says 'device >> not >> > configured' so maybe it thinks you have no batteries for some strange >> > reason. >> >> I've installed klaptop and it shows battery as -1 and 'not charging' >> acpiconf -i[0-9] didn't do any good either :/ > > Without ACPI support being able to read your battery status no userland > program will work. > > Your dmesg shows acpi_cmbat entries, ie > acpi_cmbat0: on acpi0 > acpi_cmbat1: on acpi0 > > which I think is pretty fundamental to being able to read battery status > ;) > Yesterday I googled a bit for my laptop name+linux and I found a post from a guy who had the same exact problem under Linux. He had /proc/acpi but no /proc/acpi/battery. I know battery status can be seen, as the laptop shipped with win XP home, which I promptly got rid of, but I installed a game there to see how many FPS I'd get playing with the laptop. So I still messed around with it (windows) for around 35 minutes, and could see the little battery icon discharging. If the acpi_cmbat0/1 shows up on dmesg, what could be wrong? Perhaps this ACPI implementation is a bit weird and I should send a copy of my asl to freebsd-acpi ? > > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 26 19:22:12 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 276FA16A4CE for ; Sun, 26 Dec 2004 19:22:12 +0000 (GMT) Received: from mail.revolutionsp.com (ganymede.revolutionsp.com [64.246.0.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A458A43D39 for ; Sun, 26 Dec 2004 19:22:11 +0000 (GMT) (envelope-from security@revolutionsp.com) Received: from mail.revolutionsp.com (localhost [127.0.0.1]) by mail.revolutionsp.com (Postfix) with ESMTP id 19ABB15CA7 for ; Sun, 26 Dec 2004 10:17:31 -0600 (CST) Received: from 81.84.175.77 (SquirrelMail authenticated user security@revolutionsp.com); by mail.revolutionsp.com with HTTP; Sun, 26 Dec 2004 10:17:31 -0600 (CST) Message-ID: <63338.81.84.175.77.1104077851.squirrel@81.84.175.77> In-Reply-To: <63322.81.84.175.77.1104077518.squirrel@81.84.175.77> References: <62903.81.84.175.77.1104000639.squirrel@81.84.175.77> <200412261731.25493.doconnor@gsoft.com.au> <61469.81.84.175.77.1104037002.squirrel@81.84.175.77> <200412261946.26516.doconnor@gsoft.com.au> <63322.81.84.175.77.1104077518.squirrel@81.84.175.77> Date: Sun, 26 Dec 2004 10:17:31 -0600 (CST) From: security@revolutionsp.com To: freebsd-hackers@freebsd.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: Unable to get APM working -- help! [no acpi_cmbat entries] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2004 19:22:12 -0000 Just a quick add, my dmesg doesn't show acpi_cmbat entries. You probably confused my dmesg with yours (from the dmesg mail I sent you) >> On Sun, 26 Dec 2004 15:26, security@revolutionsp.com wrote: >>> I'll try it out; meanwhile, I've discovered the sysctl to change this >>> manually. I've checked it works by trying to compile something at the >>> lowest CPU clock speed. It was slow to hell :-) >> >> That's probably clock throttling which is different.. > > Yes, the sysctl included "throttle". As I said, I'm new to the laptop > world.. Is the power saving difference a lot if I just throttle the clock, > instead of using enhanced speed step? > >> >> [Enhanced] Speed Step reduces the clock speed and the CPU core voltage.. >> clock >> throttling just idles the CPU for a certain proportion of the time. If >> you >> want slow try forcing them both to the slowest speed.. Pentium-M 75Mhz >> :) >> >>> > Any chance there is a new BIOS available for that system? >>> >>> A quick googling session brought up nothing. >> >> How about say, checking the makers web site? >> > > I also did, nothing :-P > >>> > No.. If I try and look at a non existent battery slot it says 'device >>> not >>> > configured' so maybe it thinks you have no batteries for some strange >>> > reason. >>> >>> I've installed klaptop and it shows battery as -1 and 'not charging' >>> acpiconf -i[0-9] didn't do any good either :/ >> >> Without ACPI support being able to read your battery status no userland >> program will work. >> >> Your dmesg shows acpi_cmbat entries, ie >> acpi_cmbat0: on acpi0 >> acpi_cmbat1: on acpi0 >> >> which I think is pretty fundamental to being able to read battery status >> ;) >> > > Yesterday I googled a bit for my laptop name+linux and I found a post from > a guy who had the same exact problem under Linux. He had /proc/acpi but no > /proc/acpi/battery. > > I know battery status can be seen, as the laptop shipped with win XP home, > which I promptly got rid of, but I installed a game there to see how many > FPS I'd get playing with the laptop. So I still messed around with it > (windows) for around 35 minutes, and could see the little battery icon > discharging. > > If the acpi_cmbat0/1 shows up on dmesg, what could be wrong? Perhaps this > ACPI implementation is a bit weird and I should send a copy of my asl to > freebsd-acpi ? > > >> >> -- >> Daniel O'Connor software and network engineer >> for Genesis Software - http://www.gsoft.com.au >> "The nice thing about standards is that there >> are so many of them to choose from." >> -- Andrew Tanenbaum >> GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C >> > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 26 21:28:37 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD17F16A4CE for ; Sun, 26 Dec 2004 21:28:37 +0000 (GMT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id E006643D31 for ; Sun, 26 Dec 2004 21:28:36 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru (8.13.0/vak/3.0) id iBQLPZTM029147 for freebsd-hackers@freebsd.org.checked; Mon, 27 Dec 2004 00:25:35 +0300 (MSK) (envelope-from rik@cronyx.ru) Received: from cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by hanoi.cronyx.ru (8.13.0/vak/3.0) with ESMTP id iBQLMsr8029130; Mon, 27 Dec 2004 00:22:54 +0300 (MSK) (envelope-from rik@cronyx.ru) Message-ID: <41CF297E.60505@cronyx.ru> Date: Mon, 27 Dec 2004 00:13:34 +0300 From: Roman Kurakin User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.2.1) Gecko/20030426 X-Accept-Language: ru-ru, en MIME-Version: 1.0 To: Norbert Koch References: <000a01c4e9bf$fc7e56a0$fe78a8c0@k62300> In-Reply-To: <000a01c4e9bf$fc7e56a0$fe78a8c0@k62300> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: parameters for tsleep(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2004 21:28:37 -0000 Hi, 1) man tsleep 2) tsleep is just msleep with NULL mutex. if you check sys/kern/kern_synch.c you will see KASSERT (ident != NULL && ... ident is exactly the first parameter. rik Norbert Koch: >Hello. > >I am just writing a device driver for the i82527 (can-bus) chip. >For testing I need the driver to poll the chip instead of running >in interrupt mode. > >My dev_t read function basically looks like this: > >for (;;) >{ > while (chip_has_data(...)) > { > read_chip_data(...); > error = do_uiomove(...); > if (error || enough_read(...)) > { > return error; > } > }; > if (do_not_block_on_read(...)) > { > return EWOULDBLOCK; > } > error = tsleep (XXX, PCATCH|PWAIT, "canrd", hz / 10); > if (error != EWOULDBLOCK) > { > return error; > } >} > >XXX should be 'something' which could be used >as parameter to wakeup(9), I read in tsleep(9). >In the kernel source tree I found one >place where tsleep _only_ sleeps: in sys/isa/ppc.c >(which already seems to be in the attic [?] but >still is in my computer's source tree). >Here, the first parameter was set to NULL. >Doing this I found, that tsleep immediately >returns 0 (which means: wakueup was called) >_without_ waiting. I even crashed or >froze the kernel by calling tsleep (NULL, ...) >for a random number of times. After changing >this to the address of the read-function itself, >all worked fine. No more crashes. > >Just for my understanding: Is this a bug? >Does the first parameter have to point to >something useful? >Is it allowed to point it to a code position? >Or should I use some kind of dummy data in >the softc structure instead? > >What about the second parameter: Is PWAIT >ok here or should I use PZERO or whatever? > >(And btw, why has ppc.c been removed?) > >Thank you. >_______________________________________________ >freebsd-hackers@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 27 02:29:33 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ADCB816A4CE for ; Mon, 27 Dec 2004 02:29:33 +0000 (GMT) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8538543D48 for ; Mon, 27 Dec 2004 02:29:30 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.12.11/8.12.10) with ESMTP id iBR2TNO7039304; Mon, 27 Dec 2004 12:59:24 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-hackers@freebsd.org Date: Mon, 27 Dec 2004 12:59:03 +1030 User-Agent: KMail/1.7.1 References: <62903.81.84.175.77.1104000639.squirrel@81.84.175.77> <63322.81.84.175.77.1104077518.squirrel@81.84.175.77> <63338.81.84.175.77.1104077851.squirrel@81.84.175.77> In-Reply-To: <63338.81.84.175.77.1104077851.squirrel@81.84.175.77> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1770418.ZVx8C5hQyr"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200412271259.18154.doconnor@gsoft.com.au> X-Spam-Score: -5.3 () IN_REP_TO,PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02,TO_BE_REMOVED_REPLY,USER_AGENT,USER_AGENT_KMAIL X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) cc: security@revolutionsp.com Subject: Re: Unable to get APM working -- help! [no acpi_cmbat entries] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2004 02:29:33 -0000 --nextPart1770418.ZVx8C5hQyr Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Mon, 27 Dec 2004 02:47, security@revolutionsp.com wrote: > Just a quick add, my dmesg doesn't show acpi_cmbat entries. You probably > confused my dmesg with yours (from the dmesg mail I sent you) Err, I said you didn't have any cmbat entries.. My point was that the lack = of=20 those entries is probably a hint as to why you can't see any battery info. As you suggest, try posting on freebsd-acpi about it. > >> On Sun, 26 Dec 2004 15:26, security@revolutionsp.com wrote: > >>> I'll try it out; meanwhile, I've discovered the sysctl to change this > >>> manually. I've checked it works by trying to compile something at the > >>> lowest CPU clock speed. It was slow to hell :-) > >> > >> That's probably clock throttling which is different.. > > > > Yes, the sysctl included "throttle". As I said, I'm new to the laptop > > world.. Is the power saving difference a lot if I just throttle the > > clock, instead of using enhanced speed step? > > > >> [Enhanced] Speed Step reduces the clock speed and the CPU core voltage= =2E. > >> clock > >> throttling just idles the CPU for a certain proportion of the time. If > >> you > >> want slow try forcing them both to the slowest speed.. Pentium-M 75Mhz > >> > >> :) > >> : > >>> > Any chance there is a new BIOS available for that system? > >>> > >>> A quick googling session brought up nothing. > >> > >> How about say, checking the makers web site? > > > > I also did, nothing :-P > > > >>> > No.. If I try and look at a non existent battery slot it says 'devi= ce > >>> > >>> not > >>> > >>> > configured' so maybe it thinks you have no batteries for some stran= ge > >>> > reason. > >>> > >>> I've installed klaptop and it shows battery as -1 and 'not charging' > >>> acpiconf -i[0-9] didn't do any good either :/ > >> > >> Without ACPI support being able to read your battery status no userland > >> program will work. > >> > >> Your dmesg shows acpi_cmbat entries, ie > >> acpi_cmbat0: on acpi0 > >> acpi_cmbat1: on acpi0 > >> > >> which I think is pretty fundamental to being able to read battery stat= us > >> ;) > > > > Yesterday I googled a bit for my laptop name+linux and I found a post > > from a guy who had the same exact problem under Linux. He had /proc/acpi > > but no /proc/acpi/battery. > > > > I know battery status can be seen, as the laptop shipped with win XP > > home, which I promptly got rid of, but I installed a game there to see > > how many FPS I'd get playing with the laptop. So I still messed around > > with it (windows) for around 35 minutes, and could see the little batte= ry > > icon discharging. > > > > If the acpi_cmbat0/1 shows up on dmesg, what could be wrong? Perhaps th= is > > ACPI implementation is a bit weird and I should send a copy of my asl to > > freebsd-acpi ? > > > >> -- > >> Daniel O'Connor software and network engineer > >> for Genesis Software - http://www.gsoft.com.au > >> "The nice thing about standards is that there > >> are so many of them to choose from." > >> -- Andrew Tanenbaum > >> GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > > > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to > > "freebsd-hackers-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1770418.ZVx8C5hQyr Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBz3N+5ZPcIHs/zowRAjcJAJ9QGamo2cVqaiKUreuKfiI2EHo4mACeM3m1 1kcO7JPnAGMff64/08q3TF0= =Jahy -----END PGP SIGNATURE----- --nextPart1770418.ZVx8C5hQyr-- From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 27 07:56:41 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B53716A4CE for ; Mon, 27 Dec 2004 07:56:41 +0000 (GMT) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id E822543D46 for ; Mon, 27 Dec 2004 07:56:40 +0000 (GMT) (envelope-from alsbergt@cs.huji.ac.il) Received: from ludo.cs.huji.ac.il ([132.65.80.122]) by cs1.cs.huji.ac.il with esmtp id 1Cipjl-0005Zn-21; Mon, 27 Dec 2004 09:56:17 +0200 Received: from alsbergt by ludo.cs.huji.ac.il with local (Exim 4.34 (FreeBSD)) id 1Cipjl-0002U0-0w; Mon, 27 Dec 2004 09:56:17 +0200 Date: Mon, 27 Dec 2004 09:56:16 +0200 From: Tom Alsberg To: FreeBSD Hackers List Message-ID: <20041227075616.GA9502@cs.huji.ac.il> Mail-Followup-To: Tom Alsberg , FreeBSD Hackers List Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Face: "5"j@Y1Peoz1; ftTv>\|['ox-csmV+:_RDNdi/2lSe2x?0:HVAeVW~ajwQ7RfDlcb^18eJ; t,O,s5-aNdU/DJ2E8h1s,..4}N9$27u`pWmH|; s!zlqqVwr9R^_ji=1\3}Z6gQBYyQ]{gd5-V8s^fYf{$V2*_&S>eA|SH@Y\hOVUjd[5eah{EO@gCr.ydSpJHJIU[QsH~bC?$C@O:SzF=CaUxp80-iknM(]q(W List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2004 07:56:41 -0000 Hi there. I'm trying to use some code I wrote quite a while ago using Doug White's FreeBSD IPMI code (kcs.c, send-kcs-command.c, etc.). It still works as it did back then on FreeBSD 4.10. On FreeBSD 5.3 it does not. Problem seems to be, that i386_set_ioperm isn't doing what it should. The program gets SIGBUS when doing outb, while it shouldn't. I looked in /usr/src/sys/i386/i386/sys_machdep.c, not many changes from 4.10 - all except one are additions that would return an error in case of failure. One seems to be quite modest (struct change): - if (p->p_addr->u_pcb.pcb_ext == 0) - if ((error = i386_extend_pcb(p)) != 0) + if (td->td_pcb->pcb_ext == 0) + if ((error = i386_extend_pcb(td)) != 0) Yet, clearly something fails on FreeBSD 5.3. I can confirm that this is indeed the problem with a few-line program that will i386_set_ioperm and then try to do outb. Any idea if i386_set_ioperm broke somehow in 5.3? Haven't checked much, but it seems that the data it is changing is not being used after all. Thanks, any help appreciated, -- Tom -- Tom Alsberg - hacker (being the best description fitting this space) Web page: http://www.cs.huji.ac.il/~alsbergt/ DISCLAIMER: The above message does not even necessarily represent what my fingers have typed on the keyboard, save anything further. From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 27 10:34:17 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC2DF16A4CE for ; Mon, 27 Dec 2004 10:34:17 +0000 (GMT) Received: from aker.isnic.is (aker.isnic.is [193.4.58.91]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B5EA43D46 for ; Mon, 27 Dec 2004 10:34:17 +0000 (GMT) (envelope-from oli@aker.isnic.is) Received: by aker.isnic.is (Postfix, from userid 1000) id AD8AC8A1C6; Mon, 27 Dec 2004 10:34:15 +0000 (UTC) Date: Mon, 27 Dec 2004 10:34:15 +0000 From: Olafur Osvaldsson To: freebsd-hackers@freebsd.org Message-ID: <20041227103415.GA17649@isnic.is> Mail-Followup-To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Kj7319i9nmIyA2yE" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: Crash after: discard frame without packet header X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2004 10:34:17 -0000 --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I've had two crashes on two different machines (one on each) running the sa= me kernel and same hardware in the last week. I see the following two entries in /var/log/messages on both machines right before the crash: Dec 27 09:00:21 bastet kernel: bge0: discard frame w/o packet header Dec 27 09:02:05 bastet kernel: bge0: discard frame w/o packet header One machine is only running bind and the other also has LPRng services in addition to bind. These messages have not showed up on the other 7 machines of the same hardw= are although only one of those other machines is running bind. I have a dump from the later crash if anyone can help me debug it. A backtrace shows: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D #0 doadump () at pcpu.h:159 #1 0xc060560f in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:3= 97 #2 0xc0605935 in panic (fmt=3D0xc07f164a "%s") at /usr/src/sys/kern/kern_s= hutdown.c:553 #3 0xc07a78c4 in trap_fatal (frame=3D0xe67debd8, eva=3D3217031168) at /usr/src/sys/i386/i386/trap.c:809 #4 0xc07a7607 in trap_pfault (frame=3D0xe67debd8, usermode=3D0, eva=3D3217= 031168) at /usr/src/sys/i386/i386/trap.c:727 #5 0xc07a7241 in trap (frame=3D {tf_fs =3D 24, tf_es =3D 16, tf_ds =3D 16, tf_edi =3D 0, tf_esi =3D -= 1018735520, tf_ebp =3D -427955168, tf_isp =3D -427955196, tf_ebx =3D 0, tf_= edx =3D 0, tf_ecx =3D 0, tf_eax =3D 0, tf_trapno =3D 12, tf_err =3D 0, tf_e= ip =3D -1065938507, tf_cs =3D 8, tf_eflags =3D 66118, tf_esp =3D -101146675= 2, tf_ss =3D -1056834816}) at /usr/src/sys/i386/i386/trap.c:417 #6 0xc079552a in calltrap () at /usr/src/sys/i386/i386/exception.s:140 #7 0x00000018 in ?? () #8 0x00000010 in ?? () #9 0x00000010 in ?? () #10 0x00000000 in ?? () #11 0xc3475460 in ?? () #12 0xe67dec20 in ?? () #13 0xe67dec04 in ?? () #14 0x00000000 in ?? () #15 0x00000000 in ?? () #16 0x00000000 in ?? () #17 0x00000000 in ?? () #18 0x0000000c in ?? () #19 0x00000000 in ?? () #20 0xc07711b5 in uma_find_refcnt (zone=3D0x0, item=3D0x0) at pmap.h:200 #21 0xc05fbd9c in mb_ctor_clust (mem=3D0x0, size=3D2048, arg=3D0xc3b63e00, = how=3D1) at /usr/src/sys/kern/kern_mbuf.c:266 #22 0xc076ff81 in uma_zalloc_arg (zone=3D0xc101fb00, udata=3D0xc3b63e00, fl= ags=3D1) at /usr/src/sys/vm/uma_core.c:1826 #23 0xc04d387b in bge_newbuf_std (sc=3D0xc3637000, i=3D142, m=3D0x0) at mbu= f.h:409 #24 0xc04d682c in bge_rxeof (sc=3D0xc3637000) at /usr/src/sys/dev/bge/if_bg= e.c:2764 #25 0xc04d6c50 in bge_intr (xsc=3D0xc3637000) at /usr/src/sys/dev/bge/if_bg= e.c:2971 #26 0xc05f14fd in ithread_loop (arg=3D0xc347da00) at /usr/src/sys/kern/kern= _intr.c:547 #27 0xc05f05ad in fork_exit (callout=3D0xc05f13a4 , arg=3D0xc= 347da00, frame=3D0xe67ded48) at /usr/src/sys/kern/kern_fork.c:811 #28 0xc079558c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:= 209 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D /Oli --=20 Olafur Osvaldsson Systems Administrator Internet a Islandi hf. Tel: +354 525-5291 Email: oli@isnic.is --Kj7319i9nmIyA2yE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBz+Un8xNRBRknOFwRAl4GAKCsbFhQK2VYJSV8azoMrOZIdsTPNQCgnH2J wCvORV2Ogu1entyP5RRdw5U= =l9OA -----END PGP SIGNATURE----- --Kj7319i9nmIyA2yE-- From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 26 20:40:32 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 250B816A4CE for ; Sun, 26 Dec 2004 20:40:32 +0000 (GMT) Received: from dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NOSPAM.dyndns.dk (84-72-30-72.dclient.hispeed.ch [84.72.30.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0507F43D39 for ; Sun, 26 Dec 2004 20:40:31 +0000 (GMT) (envelope-from bounce@NOSPAM.dyndns.dk) Received: from Mail.NOSPAM.DynDNS.dK (ipv6.NOSPAM.dyndns.dk [2002:5448:1e48:0:210:60ff:fe25:f1e5]) (8.11.6/8.11.6-SPAMMERS-DeLiGHt) with ESMTP id iBQKeGI02749 verified NO) for ; Sun, 26 Dec 2004 21:40:27 +0100 (CET) (envelope-from bounce@NOSPAM.dyndns.dk) Received: (from beer@localhost) by Mail.NOSPAM.DynDNS.dK (8.11.6/FNORD) id iBQKeFW02748; Sun, 26 Dec 2004 21:40:16 +0100 (CET) (envelope-from bounce@NOSPAM.dyndns.dk) Date: Sun, 26 Dec 2004 21:40:16 +0100 (CET) Message-Id: <200412262040.iBQKeFW02748@Mail.NOSPAM.DynDNS.dK> X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: beer set sender to bounce@NOSPAM.dyndns.dk using -f X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed from queue /tmp X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed by beer with -C /etc/mail/sendmail.cf-LOCAL From: Barry Bouwsma Mail-Followup-To: Hackers United To: Hackers United X-Mailman-Approved-At: Mon, 27 Dec 2004 13:14:45 +0000 Subject: Mysterious system freeze-ups on my consoles... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Barry Bouwsma List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2004 20:40:32 -0000 Howdy. I've had this problem on FreeBSD 4.x for some time, on occasion. What happens is that when using a handful of full-screen applications on the normal syscons consoles (alt-F1 on up), the system occasionally locks up entirely right as I'm doing some navigation on the screen. I can't get into the debugger, or do anything at all from the console, the machine has suddenly completely wedged, and whatever else it may have been doing stops. (I haven't tried a remote console debugger.) What would cause such a total lockup -- would it be interrupt/locking related? I'm ignorant here. This happens when I'm online, networked, as the full-screen applications (lynx and links web browsers) don't really work without a network connection, and it has definitely happened when I've been connected over dial-in PPP via a serial port, and more recently I believe I've been connected via a USB-attached ethernet adapter. I don't recall it happening at any time when I was connected via an internal ISA or PCI network card. Is it possible that these freezes are related to the serial port, or over USB? One almost sure-fire way for it to happen with serial-port PPP was to expand a menu of items to select. Recently the freezes happened rather regularly viewing Google with lynx going off the top line to the input field. Version of lynx made no difference, and `links' had the same problem somewhere. Running `lynx' in an xterm, I simply haven't had this problem at all. Nor does normal console use, as far as I can see. 4.x kernel is more than half a year old but I've had the problem for at least a year; have not tried a newer kernel yet. Please let me know if my hypothesis that data arriving via the serial port or via USB combined with cons25-type screen activity could be the cause of this, or if it's just coincidence, as well as what is likely to cause a complete solid wedge, for my education. Thanks. barry bouwsma From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 27 16:24:00 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA4D916A4CE for ; Mon, 27 Dec 2004 16:24:00 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id E4B7C43D31 for ; Mon, 27 Dec 2004 16:23:59 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id iBRGLj8Y005227; Mon, 27 Dec 2004 09:21:45 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 27 Dec 2004 09:22:16 -0700 (MST) Message-Id: <20041227.092216.127891299.imp@bsdimp.com> To: nkoch@gmx.com, freebsd-hackers@freebsd.org From: "M. Warner Losh" In-Reply-To: <41CF297E.60505@cronyx.ru> References: <000a01c4e9bf$fc7e56a0$fe78a8c0@k62300> <41CF297E.60505@cronyx.ru> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: parameters for tsleep(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2004 16:24:00 -0000 In message: <41CF297E.60505@cronyx.ru> Roman Kurakin writes: : >I am just writing a device driver for the i82527 (can-bus) chip. : >For testing I need the driver to poll the chip instead of running : >in interrupt mode. There's a canbus implementation in the pc98 specific part of FreeBSD. Maybe that will be useful to you. Warner From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 27 16:27:57 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AAAF116A4CE for ; Mon, 27 Dec 2004 16:27:57 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41C2C43D41 for ; Mon, 27 Dec 2004 16:27:57 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id iBRGNvSU005261; Mon, 27 Dec 2004 09:23:58 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 27 Dec 2004 09:24:28 -0700 (MST) Message-Id: <20041227.092428.38703876.imp@bsdimp.com> To: alsbergt@cs.huji.ac.il From: "M. Warner Losh" In-Reply-To: <20041227075616.GA9502@cs.huji.ac.il> References: <20041227075616.GA9502@cs.huji.ac.il> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: i386_set_ioperm on FreeBSD 5.3 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2004 16:27:57 -0000 In message: <20041227075616.GA9502@cs.huji.ac.il> Tom Alsberg writes: : Hi there. : : I'm trying to use some code I wrote quite a while ago using Doug : White's FreeBSD IPMI code (kcs.c, send-kcs-command.c, etc.). : : It still works as it did back then on FreeBSD 4.10. On FreeBSD 5.3 it : does not. : : Problem seems to be, that i386_set_ioperm isn't doing what it should. : The program gets SIGBUS when doing outb, while it shouldn't. : : I looked in /usr/src/sys/i386/i386/sys_machdep.c, not many changes : from 4.10 - all except one are additions that would return an error in : case of failure. One seems to be quite modest (struct change): : : - if (p->p_addr->u_pcb.pcb_ext == 0) : - if ((error = i386_extend_pcb(p)) != 0) : + if (td->td_pcb->pcb_ext == 0) : + if ((error = i386_extend_pcb(td)) != 0) : : Yet, clearly something fails on FreeBSD 5.3. I can confirm that this : is indeed the problem with a few-line program that will : i386_set_ioperm and then try to do outb. Any idea if i386_set_ioperm : broke somehow in 5.3? Haven't checked much, but it seems that the : data it is changing is not being used after all. : : Thanks, any help appreciated, We had problems with multiple people opening /dev/io and threads in 4.x. It was a timing related thing. Maybe you're seeing a different timing thing in your program? Warner From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 27 19:56:36 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2296216A520 for ; Mon, 27 Dec 2004 19:56:35 +0000 (GMT) Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id E428A43D48 for ; Mon, 27 Dec 2004 19:56:34 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 18147 invoked from network); 27 Dec 2004 19:56:34 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 27 Dec 2004 19:56:34 -0000 Received: from [10.50.41.243] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id iBRJuJcW088548; Mon, 27 Dec 2004 14:56:27 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-hackers@FreeBSD.org Date: Mon, 27 Dec 2004 14:52:40 -0500 User-Agent: KMail/1.6.2 References: <36627.194.210.13.66.1102679886.squirrel@194.210.13.66> <20041210204824.GA53907@xor.obsecurity.org> In-Reply-To: <20041210204824.GA53907@xor.obsecurity.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200412271452.40348.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: klr@6s-gaming.com cc: Kris Kennaway Subject: Re: HTT/SMP servers instability on 5.3-STABLE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2004 19:56:38 -0000 On Friday 10 December 2004 03:48 pm, Kris Kennaway wrote: > On Fri, Dec 10, 2004 at 05:58:06AM -0600, klr@6s-gaming.com wrote: > > I've heard it can penalize performance because the scheduler isn't > > optimized for logical CPUs. Does having HTT enabled impacts the > > stability of the system? > > No. Actually, for 5.3 it does. HEAD has the problem fixed, not sure about RELENG_5 yet, but due to the way IPIs are done in 5.3, having more than 2 CPUs can be very destabilizing, so disabling HTT on a 2-way system so that it goes from 4 CPUs to 2 CPUs can help stability very much. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 27 22:11:05 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3ADFB16A4CE for ; Mon, 27 Dec 2004 22:11:05 +0000 (GMT) Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B86443D39 for ; Mon, 27 Dec 2004 22:11:05 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 22824 invoked from network); 27 Dec 2004 22:11:04 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 27 Dec 2004 22:11:04 -0000 Received: from [10.50.41.243] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id iBRMArTL089244; Mon, 27 Dec 2004 17:10:59 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-hackers@FreeBSD.org Date: Mon, 27 Dec 2004 15:38:11 -0500 User-Agent: KMail/1.6.2 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200412271538.11938.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx Subject: Re: Kernel crash w/o reason X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2004 22:11:05 -0000 On Friday 24 December 2004 07:13 am, Jan Engelhardt wrote: > >> What should I use instead? A semaphore? > > > >You shouldn't have unrelated kernel threads waiting for a user > >process at all, so this sounds like a design problem, regardless > >of which mutual exclusion primitive you use. (Bear in mind that I > >haven't actually looked into what you're trying to do.) In any > >case, you can always use mutexes to implement whatever other > >synchronization mechanism you need. > > I wanted that the device can only be opened once, and holding a mutex while > it is open seemed like a simple idea. (Since mtx_trylock() will then fail > -- easy to implement.) Use a flag in your softc and use a mutex to protect access to the flag. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 28 03:03:52 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D773616A4CE for ; Tue, 28 Dec 2004 03:03:52 +0000 (GMT) Received: from mail.revolutionsp.com (ganymede.revolutionsp.com [64.246.0.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7EA3243D2F for ; Tue, 28 Dec 2004 03:03:52 +0000 (GMT) (envelope-from security@revolutionsp.com) Received: from mail.revolutionsp.com (localhost [127.0.0.1]) by mail.revolutionsp.com (Postfix) with ESMTP id E56A315CA6 for ; Mon, 27 Dec 2004 17:59:09 -0600 (CST) Received: from 81.84.175.77 (SquirrelMail authenticated user security@revolutionsp.com); by mail.revolutionsp.com with HTTP; Mon, 27 Dec 2004 17:59:09 -0600 (CST) Message-ID: <64234.81.84.175.77.1104191949.squirrel@81.84.175.77> Date: Mon, 27 Dec 2004 17:59:09 -0600 (CST) From: security@revolutionsp.com To: freebsd-hackers@freebsd.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Supported wireless PCI card? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 03:03:53 -0000 Hi, I need to get a wireless card for my lan gateway.. But I have few options as what to buy in my country. I need a card that's supported (FreeBSD 5.3) and is capable of being an access point.. Here is the list of the cards I could find: - Belkin F5D7000 - SMC SMC2802W - SiteCom WL-121 Not too many choices I know.. but these are the only available PCI wireless cards I could find on the local stores. I've heard SMC cards die a few months after heavy usage, but I don't know if these are true claims. Either way, I need one wireless card that can do AP.. which one should I purchase? Regards, Hugo From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 28 04:19:28 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 659F016A4CE for ; Tue, 28 Dec 2004 04:19:28 +0000 (GMT) Received: from watery.cc.kogakuin.ac.jp (watery.cc.kogakuin.ac.jp [133.80.152.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC0C443D2F for ; Tue, 28 Dec 2004 04:19:27 +0000 (GMT) (envelope-from nyan@jp.FreeBSD.org) Received: from localhost (localhost [IPv6:::1])iBS4JFr0065913; Tue, 28 Dec 2004 13:19:15 +0900 (JST) (envelope-from nyan@jp.FreeBSD.org) Date: Tue, 28 Dec 2004 13:18:34 +0900 (JST) Message-Id: <20041228.131834.74695833.nyan@jp.FreeBSD.org> To: imp@bsdimp.com From: Takahashi Yoshihiro In-Reply-To: <20041227.092216.127891299.imp@bsdimp.com> References: <000a01c4e9bf$fc7e56a0$fe78a8c0@k62300> <41CF297E.60505@cronyx.ru> <20041227.092216.127891299.imp@bsdimp.com> X-Mailer: Mew version 4.1 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 28 Dec 2004 13:57:13 +0000 cc: nkoch@gmx.com cc: freebsd-hackers@freebsd.org Subject: Re: parameters for tsleep(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 04:19:28 -0000 In article <20041227.092216.127891299.imp@bsdimp.com> "M. Warner Losh" writes: > In message: <41CF297E.60505@cronyx.ru> > Roman Kurakin writes: > : >I am just writing a device driver for the i82527 (can-bus) chip. > : >For testing I need the driver to poll the chip instead of running > : >in interrupt mode. > > There's a canbus implementation in the pc98 specific part of FreeBSD. > Maybe that will be useful to you. It is for PC-9821 CanBe specific bus, not for Controller Area Network. Sorry to confuse. --- TAKAHASHI Yoshihiro From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 28 22:02:10 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1FEF416A4CE for ; Tue, 28 Dec 2004 22:02:09 +0000 (GMT) Received: from mail.revolutionsp.com (ganymede.revolutionsp.com [64.246.0.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 945A143D39 for ; Tue, 28 Dec 2004 22:02:09 +0000 (GMT) (envelope-from security@revolutionsp.com) Received: from mail.revolutionsp.com (localhost [127.0.0.1]) by mail.revolutionsp.com (Postfix) with ESMTP id 5920415CA6 for ; Tue, 28 Dec 2004 12:57:26 -0600 (CST) Received: from 81.84.175.77 (SquirrelMail authenticated user security@revolutionsp.com); by mail.revolutionsp.com with HTTP; Tue, 28 Dec 2004 12:57:26 -0600 (CST) Message-ID: <64637.81.84.175.77.1104260246.squirrel@81.84.175.77> In-Reply-To: <7603e5d804122802466eeaf6aa@mail.gmail.com> References: <64234.81.84.175.77.1104191949.squirrel@81.84.175.77> <7603e5d804122802466eeaf6aa@mail.gmail.com> Date: Tue, 28 Dec 2004 12:57:26 -0600 (CST) From: security@revolutionsp.com To: freebsd-hackers@freebsd.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: Supported wireless PCI card? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 22:02:10 -0000 Hey, Thanks for the reply! Should I go for the SiteCom one? I only included it on the list because there are really few available PCI wireless cards around here; I didn't see it listed on man wi. Belkin is there (different model) and SMC is there (also a different model). Can you grant me SiteCom's one will correctly be detected and be able to work as a hostap on FreeBSD 5.3 ? Best regards, Hugo > On Mon, 27 Dec 2004 17:59:09 -0600 (CST), security@revolutionsp.com > wrote: >> Hi, >> >> I need to get a wireless card for my lan gateway.. But I have few >> options >> as what to buy in my country. I need a card that's supported (FreeBSD >> 5.3) >> and is capable of being an access point.. >> >> Here is the list of the cards I could find: >> >> - Belkin F5D7000 >> - SMC SMC2802W >> - SiteCom WL-121 ( this one definately works ) >> >> Not too many choices I know.. but these are the only available PCI >> wireless cards I could find on the local stores. >> >> I've heard SMC cards die a few months after heavy usage, but I don't >> know >> if these are true claims. >> >> Either way, I need one wireless card that can do AP.. which one should I >> purchase? >> >> Regards, >> >> Hugo >> >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to >> "freebsd-hackers-unsubscribe@freebsd.org" >> > From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 29 22:15:46 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DCA5D16A4CE for ; Wed, 29 Dec 2004 22:15:46 +0000 (GMT) Received: from vsmtp3.tin.it (vsmtp3alice.tin.it [212.216.176.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FB9143D64 for ; Wed, 29 Dec 2004 22:15:46 +0000 (GMT) (envelope-from rionda@gufi.org) Received: from kaiser.sig11.org (82.50.115.31) by vsmtp3.tin.it (7.0.027) id 41C401F10054226F for freebsd-hackers@freebsd.org; Wed, 29 Dec 2004 23:15:45 +0100 Received: from localhost.localdomain (localhost [127.0.0.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by kaiser.sig11.org (Postfix) with ESMTP id 0C2A462DF for ; Wed, 29 Dec 2004 23:15:42 +0100 (CET) From: Matteo Riondato To: freebsd-hackers@freebsd.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-iTnCslV98sUySqT0X+/5" Date: Wed, 29 Dec 2004 23:15:40 +0100 Message-Id: <1104358540.2895.10.camel@kaiser.sig11.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 FreeBSD GNOME Team Port Subject: Creating Compressed Loop FS from stdin X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2004 22:15:47 -0000 --=-iTnCslV98sUySqT0X+/5 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi folks! I think you know what FreeSBIE is and that we use compressed loop filesystems for /usr and /var directories on our LiveCD.=20 At the moment, to create compressed filesystems, we rely on sysutils/cloop-utils, but I know /usr/bin/mkuzip is present in HEAD and in RELENG_5 and would like to switch to that. However, it seems that I cannot create valid cloopfs with mkuzip. To create the cloop image, I use: /usr/local/bin/mkisofs -lrJL $FREESBIEBASEDIR/usr | /usr/bin/mkuzip -v \ -o $FREESBIEBASEDIR/cloop/usr.cloop -s 65536 /dev/stdin (similar line for /var clooped image) Creation of the clooped images does finish without any error, but I cannot mount it: #kldload geom_uzip #mdconfig -a -t vnode usr.cloop md0 #mount_cd9660 /dev/md0.uzip /mnt mount_cd9660: /dev/md0.uzip: Input/output error Can you give me any hint? Perhaps I'm missing something in the creation of the image. I will provide further information if needed. Thank you in advance. Best Regards --=20 Rionda aka Matteo Riondato GUFI Staff Member (http://www.gufi.org) FreeSBIE Developer (http://www.freesbie.org) BSD-FAQ-it Main Developer (http://utenti.gufi.org/~rionda) Sent from: kaiser.sig11.org running FreeBSD-6.0-CURRENT --=-iTnCslV98sUySqT0X+/5 Content-Type: application/pgp-signature; name=signature.asc Content-Description: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBB0yyM2Mp4pR7Fa+wRAnvXAJ4rT4yb392CL8it6EmK1sobs6nmkACgprCn d4s5oUlUvPpMCDWBNv+prBs= =wVbM -----END PGP SIGNATURE----- --=-iTnCslV98sUySqT0X+/5-- From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 29 23:05:23 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F289C16A4CE for ; Wed, 29 Dec 2004 23:05:22 +0000 (GMT) Received: from smtp.k12us.com (smtp.k12us.com [65.112.222.15]) by mx1.FreeBSD.org (Postfix) with SMTP id 620C043D2D for ; Wed, 29 Dec 2004 23:05:22 +0000 (GMT) (envelope-from csw@k12hq.com) Received: (qmail 81046 invoked by uid 1001); 29 Dec 2004 23:05:21 -0000 Date: Wed, 29 Dec 2004 18:05:21 -0500 From: Christopher Weimann To: freebsd-hackers@freebsd.org Message-ID: <20041229230521.GB31984@smtp.k12us.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i Subject: execl bug? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2004 23:05:23 -0000 It seems that the open handle is carried through and usable by the child program unless the parent has done something to move the file pointer. For example the program below (tst.c) opens a file, reads a line, rewinds then uses execl to call "cat -" which ought to send the file to stdout. I thought I must be misunderstanding how execl is supposed to work so I tried it on a Redhat box to see if everything behaves the same. It doesn't. On Redhat the file is displayed just as I would expect. At first I thought this was a close-on-exec problem but that is not set, plus it works if I remove the fgets call. What am I missing? #include #include #include #include #include #include #include #include #include int main(argc, argv) int argc; char **argv; { pid_t pid; int status ; char buff[ 513 ]; int tempfd = -1 ; if ((tempfd=open("tst.c", O_RDWR|O_CREAT, 0600)) < 0) { perror("open"); } close(0); dup(tempfd); close(tempfd); printf( "\nclose on exec is %d \n" , fcntl( fileno(stdin), F_GETFD) && FD_CLOEXEC ) ; /* comment out the following three lines and all is well on FreeBSD */ fgets( buff, 512, stdin ) ; printf( "%s", buff ) ; rewind( stdin ) ; if ( (pid = fork()) < 0){ perror("execl error"); _exit(1) ; } else if (pid == 0) { /* child */ if (execl( "/bin/cat","cat", "-" , (char *) 0) < 0) { perror("execl error"); _exit(1) ; } } if (waitpid(pid, &status, 0) < 0){ /* parent */ perror("execl error"); exit(1) ; } if( WIFEXITED(status) ) { exit(WEXITSTATUS(status)); }else{ exit( 1 ) ; } } -- From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 30 00:10:45 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 480F216A4CE for ; Thu, 30 Dec 2004 00:10:45 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD70C43D39 for ; Thu, 30 Dec 2004 00:10:44 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.1) id iBU0AhKZ004199; Wed, 29 Dec 2004 18:10:43 -0600 (CST) (envelope-from dan) Date: Wed, 29 Dec 2004 18:10:43 -0600 From: Dan Nelson To: Christopher Weimann Message-ID: <20041230001043.GA88403@dan.emsphone.com> References: <20041229230521.GB31984@smtp.k12us.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041229230521.GB31984@smtp.k12us.com> X-OS: FreeBSD 5.3-STABLE X-message-flag: Outlook Error User-Agent: Mutt/1.5.6i cc: freebsd-hackers@freebsd.org Subject: Re: execl bug? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2004 00:10:45 -0000 In the last episode (Dec 29), Christopher Weimann said: > It seems that the open handle is carried through and usable by the > child program unless the parent has done something to move the file > pointer. For example the program below (tst.c) opens a file, reads a > line, rewinds then uses execl to call "cat -" which ought to send the > file to stdout. > > I thought I must be misunderstanding how execl is supposed to work so > I tried it on a Redhat box to see if everything behaves the same. It > doesn't. On Redhat the file is displayed just as I would expect. I think your problem here is with rewind(). There's nothing that says it has to change the underlying filedescriptor; FreeBSD's fseek code knows that the beginning of the file is still within its stdio buffer, so it simply resets the seek offset in the FILE* back to zero. See the code in /usr/src/lib/libc/stdio/fseek.c . Replacing your rewind() with an lseek(0,0,SEEK_SET) makes the program work. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 30 01:10:55 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 922E816A4CE for ; Thu, 30 Dec 2004 01:10:55 +0000 (GMT) Received: from smtp.k12us.com (smtp.k12us.com [65.112.222.15]) by mx1.FreeBSD.org (Postfix) with SMTP id 08C1E43D45 for ; Thu, 30 Dec 2004 01:10:55 +0000 (GMT) (envelope-from csw@k12hq.com) Received: (qmail 96082 invoked by uid 1001); 30 Dec 2004 01:10:54 -0000 Date: Wed, 29 Dec 2004 20:10:54 -0500 From: Christopher Weimann To: Dan Nelson Message-ID: <20041230011054.GC31984@smtp.k12us.com> References: <20041229230521.GB31984@smtp.k12us.com> <20041230001043.GA88403@dan.emsphone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041230001043.GA88403@dan.emsphone.com> User-Agent: Mutt/1.5.4i cc: freebsd-hackers@freebsd.org Subject: Re: execl bug? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2004 01:10:55 -0000 On 12/29/2004-06:10PM, Dan Nelson wrote: > > I think your problem here is with rewind(). There's nothing that says > it has to change the underlying filedescriptor; FreeBSD's fseek code > knows that the beginning of the file is still within its stdio buffer, > so it simply resets the seek offset in the FILE* back to zero. See the > code in /usr/src/lib/libc/stdio/fseek.c . Replacing your rewind() with > an lseek(0,0,SEEK_SET) makes the program work. > > -- > Dan Nelson > dnelson@allantgroup.com > Perfect! It works, and it even makes sense to me :) Thank you! -- From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 30 10:34:36 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 38EC816A4CE for ; Thu, 30 Dec 2004 10:34:36 +0000 (GMT) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id 1BF1F43D31 for ; Thu, 30 Dec 2004 10:34:35 +0000 (GMT) (envelope-from roam@ringlet.net) Received: (qmail 8331 invoked from network); 30 Dec 2004 10:34:31 -0000 Received: from unknown (HELO straylight.ringlet.net) (213.16.36.84) by gandalf.online.bg with SMTP; 30 Dec 2004 10:34:31 -0000 Received: (qmail 1942 invoked by uid 1000); 30 Dec 2004 10:34:33 -0000 Date: Thu, 30 Dec 2004 12:34:33 +0200 From: Peter Pentchev To: Matteo Riondato Message-ID: <20041230103433.GB830@straylight.m.ringlet.net> Mail-Followup-To: Matteo Riondato , freebsd-hackers@freebsd.org, Maxim Sobolev References: <1104358540.2895.10.camel@kaiser.sig11.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wq9mPyueHGvFACwf" Content-Disposition: inline In-Reply-To: <1104358540.2895.10.camel@kaiser.sig11.org> User-Agent: Mutt/1.5.6i cc: freebsd-hackers@freebsd.org cc: Maxim Sobolev Subject: Re: Creating Compressed Loop FS from stdin X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2004 10:34:36 -0000 --wq9mPyueHGvFACwf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 29, 2004 at 11:15:40PM +0100, Matteo Riondato wrote: > Hi folks! >=20 > I think you know what FreeSBIE > is and that we use compressed loop filesystems for /usr and /var > directories on our LiveCD.=20 > At the moment, to create compressed filesystems, we rely on > sysutils/cloop-utils, but I know /usr/bin/mkuzip is present in HEAD and > in RELENG_5 and would like to switch to that. However, it seems that I > cannot create valid cloopfs with mkuzip. > To create the cloop image, I use: >=20 > /usr/local/bin/mkisofs -lrJL $FREESBIEBASEDIR/usr | /usr/bin/mkuzip -v \ > -o $FREESBIEBASEDIR/cloop/usr.cloop -s 65536 /dev/stdin Well, as you can see from the very first line output by mkuzip in that case (if -v is indeed specified), it thinks that the input file is 0 bytes long. This is so because the first thing mkuzip does is a stat(2) on the input file descriptor, and when you point it at /dev/stdin, stat() returns a length of 0 bytes since it is impossible to determine beforehand how much data will be produced by the pipe. This could be fixed by the following patch. I'm CC'ing Maxim Sobolev, the author of mkuzip(8); Maxim, do you have any objections to this patch? G'luck, Peter Index: src/usr.bin/mkuzip/mkuzip.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/usr.bin/mkuzip/mkuzip.c,v retrieving revision 1.2 diff -u -r1.2 mkuzip.c --- src/usr.bin/mkuzip/mkuzip.c 10 Sep 2004 23:16:05 -0000 1.2 +++ src/usr.bin/mkuzip/mkuzip.c 30 Dec 2004 10:32:38 -0000 @@ -122,10 +122,23 @@ signal(SIGXFSZ, exit); atexit(cleanup); =20 - if (stat(iname, &sb) !=3D 0) { + fdr =3D open(iname, O_RDONLY); + if (fdr < 0) { err(1, "%s", iname); /* Not reached */ } + + /* Try seeking to the end; if that fails, fall back to fstat() */ + sb.st_size =3D lseek(fdr, 0, SEEK_END); + if (sb.st_size < 1 && fstat(fdr, &sb) !=3D 0) { + err(1, "%s", iname); + /* Not reached */ + } + if (sb.st_size < 1) { + errx(1, "Could not determine the size of %s", iname); + /* Not reached */ + } + lseek(fdr, 0, SEEK_SET); hdr.nblocks =3D sb.st_size / hdr.blksz; if ((sb.st_size % hdr.blksz) !=3D 0) { if (verbose !=3D 0) @@ -135,11 +148,6 @@ } toc =3D safe_malloc((hdr.nblocks + 1) * sizeof(*toc)); =20 - fdr =3D open(iname, O_RDONLY); - if (fdr < 0) { - err(1, "%s", iname); - /* Not reached */ - } fdw =3D open(oname, O_WRONLY | O_TRUNC | O_CREAT, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH); if (fdw < 0) { --=20 Peter Pentchev roam@ringlet.net roam@cnsys.bg roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence claims to be an Epimenides paradox, but it is lying. --wq9mPyueHGvFACwf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFB09m57Ri2jRYZRVMRAlRcAKCH3qxE19Ay+kvmF0Ot6L/tlXzCEgCeJ7UL bAPkDq8VR/D1OpkMkNEPGag= =Zn97 -----END PGP SIGNATURE----- --wq9mPyueHGvFACwf-- From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 30 12:28:35 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6AB5716A4CE; Thu, 30 Dec 2004 12:28:35 +0000 (GMT) Received: from vsmtp2.tin.it (vsmtp2alice.tin.it [212.216.176.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id E004B43D3F; Thu, 30 Dec 2004 12:28:34 +0000 (GMT) (envelope-from rionda@gufi.org) Received: from kaiser.sig11.org (82.50.115.31) by vsmtp2.tin.it (7.0.027) id 41D2DD4D00058214; Thu, 30 Dec 2004 13:28:33 +0100 Received: from localhost.localdomain (localhost [127.0.0.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by kaiser.sig11.org (Postfix) with ESMTP id F09CC63B7; Thu, 30 Dec 2004 13:28:29 +0100 (CET) From: Matteo Riondato To: Peter Pentchev In-Reply-To: <20041230103433.GB830@straylight.m.ringlet.net> References: <1104358540.2895.10.camel@kaiser.sig11.org> <20041230103433.GB830@straylight.m.ringlet.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-s6HoEYy6hN4BVWE5bD2Y" Date: Thu, 30 Dec 2004 13:28:28 +0100 Message-Id: <1104409708.6657.1.camel@kaiser.sig11.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 FreeBSD GNOME Team Port cc: freebsd-hackers@freebsd.org cc: Maxim Sobolev Subject: Re: Creating Compressed Loop FS from stdin X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: rionda@gufi.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2004 12:28:35 -0000 --=-s6HoEYy6hN4BVWE5bD2Y Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Il giorno Gio, 30-12-2004 alle 12:34 +0200, Peter Pentchev ha scritto: > This could be fixed by the following patch. I'm CC'ing Maxim Sobolev, > the author of mkuzip(8); Maxim, do you have any objections to this patch? Thank you for the answer and fo the patch! I hope Maxim will commit it soon. Best Regards --=20 Rionda aka Matteo Riondato GUFI Staff Member (http://www.gufi.org) FreeSBIE Developer (http://www.freesbie.org) BSD-FAQ-it Main Developer (http://utenti.gufi.org/~rionda) Sent from: kaiser.sig11.org running FreeBSD-6.0-CURRENT --=-s6HoEYy6hN4BVWE5bD2Y Content-Type: application/pgp-signature; name=signature.asc Content-Description: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBB0/Rs2Mp4pR7Fa+wRAtGhAJ9mi+8F4bXI9mNg1zsj9khEr6cKcwCeP3dD fR1hUUhaQEvkG5IV6rpNJTs= =dSmN -----END PGP SIGNATURE----- --=-s6HoEYy6hN4BVWE5bD2Y-- From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 30 12:31:20 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6FB4116A4CF for ; Thu, 30 Dec 2004 12:31:20 +0000 (GMT) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id A901A43D41 for ; Thu, 30 Dec 2004 12:31:18 +0000 (GMT) (envelope-from roam@ringlet.net) Received: (qmail 9593 invoked from network); 30 Dec 2004 12:31:14 -0000 Received: from unknown (HELO straylight.ringlet.net) (213.16.36.84) by gandalf.online.bg with SMTP; 30 Dec 2004 12:31:14 -0000 Received: (qmail 56428 invoked by uid 1000); 30 Dec 2004 12:31:16 -0000 Date: Thu, 30 Dec 2004 14:31:16 +0200 From: Peter Pentchev To: Matteo Riondato Message-ID: <20041230123116.GE830@straylight.m.ringlet.net> Mail-Followup-To: Matteo Riondato , freebsd-hackers@freebsd.org, Maxim Sobolev References: <1104358540.2895.10.camel@kaiser.sig11.org> <20041230103433.GB830@straylight.m.ringlet.net> <1104409708.6657.1.camel@kaiser.sig11.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3XA6nns4nE4KvaS/" Content-Disposition: inline In-Reply-To: <1104409708.6657.1.camel@kaiser.sig11.org> User-Agent: Mutt/1.5.6i cc: freebsd-hackers@freebsd.org cc: Maxim Sobolev Subject: Re: Creating Compressed Loop FS from stdin X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2004 12:31:20 -0000 --3XA6nns4nE4KvaS/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 30, 2004 at 01:28:28PM +0100, Matteo Riondato wrote: > Il giorno Gio, 30-12-2004 alle 12:34 +0200, Peter Pentchev ha scritto: > > This could be fixed by the following patch. I'm CC'ing Maxim Sobolev, > > the author of mkuzip(8); Maxim, do you have any objections to this patc= h? >=20 > Thank you for the answer and fo the patch! I hope Maxim will commit it > soon. Actually, if Maxim has no objections, I could commit it myself. However, it would be totally understandable if he doesn't answer in the next day or three, what with the calendar moving ahead and all :) G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@cnsys.bg roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If this sentence didn't exist, somebody would have invented it. --3XA6nns4nE4KvaS/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFB0/UU7Ri2jRYZRVMRAsjRAJ9JoJgyU94V85TCxiOzelgbquiGbACePdMd vke0rta/I7qRFjJszNNygRk= =oMuS -----END PGP SIGNATURE----- --3XA6nns4nE4KvaS/-- From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 30 12:49:49 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 202A316A4CE; Thu, 30 Dec 2004 12:49:49 +0000 (GMT) Received: from recife.ipadnet.com.br (recife.ipadnet.com.br [200.249.204.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0927843D31; Thu, 30 Dec 2004 12:49:48 +0000 (GMT) (envelope-from mario.lobo@ipad.com.br) Received: from marioLobo ([200.249.204.142]) by recife.ipadnet.com.br (8.12.8/8.12.8) with ESMTP id iBUCu0wT032197; Thu, 30 Dec 2004 09:56:00 -0300 From: mario.lobo@ipad.com.br Organization: IPAD To: freebsd-questions@freebsd.org Date: Thu, 30 Dec 2004 09:53:49 -0300 MIME-Version: 1.0 Message-ID: <41D3D02D.16937.7488E@localhost> Priority: normal X-mailer: Pegasus Mail for Windows (4.21c) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: Quoted-printable Content-description: Mail message body cc: freebsd-hackers@freebsd.org Subject: Support for Adaptec Ultra 320 (29320) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: mario.lobo@ipad.com.br List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2004 12:49:49 -0000 Hi everyone ! I hope all had a nice Xmas and I wish a happy new year to you all !! I=B4m not sure I saw this issue here before but is there support for the A= daptec Ultra 320 (29320) scsi controller on FreeBSD 5.3 ? I know it is a new controller. Thanks, -- //| //|| // | // || -//--//---|| ARIO LOBO // // || --------------------------------- mario.lobo@ipad.com.br http://www.ipad.com.br From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 30 12:54:11 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C03D16A4CE; Thu, 30 Dec 2004 12:54:11 +0000 (GMT) Received: from mail2out.barnet.com.au (mail2out.barnet.com.au [202.83.176.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id C949843D46; Thu, 30 Dec 2004 12:54:10 +0000 (GMT) (envelope-from edwin@mavetju.org) Received: by mail2out.barnet.com.au (Postfix, from userid 27) id 5A17570743C; Thu, 30 Dec 2004 23:54:09 +1100 (EST) X-Viruscan-Id: <41D3FA7100008E90F7E952@BarNet> Received: from mail2-auth.barnet.com.au (mail2.barnet.com.au [202.83.176.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) Authority" (verified OK)) by mail2.barnet.com.au (Postfix) with ESMTP id 1ACB7707439; Thu, 30 Dec 2004 23:54:09 +1100 (EST) Received: from k7.mavetju (edwin-3.int.barnet.com.au [10.10.12.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) Certificate Authority" (verified OK)) by mail2-auth.barnet.com.au (Postfix) with ESMTP id 8F6B6707426; Thu, 30 Dec 2004 23:54:08 +1100 (EST) Received: by k7.mavetju (Postfix, from userid 1001) id 8123760EA; Thu, 30 Dec 2004 23:54:07 +1100 (EST) Date: Thu, 30 Dec 2004 23:54:07 +1100 From: Edwin Groothuis To: mario.lobo@ipad.com.br Message-ID: <20041230125407.GB1430@k7.mavetju> Mail-Followup-To: Edwin Groothuis , mario.lobo@ipad.com.br, freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org References: <41D3D02D.16937.7488E@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41D3D02D.16937.7488E@localhost> User-Agent: Mutt/1.5.6i cc: freebsd-hackers@freebsd.org cc: freebsd-questions@freebsd.org Subject: Re: Support for Adaptec Ultra 320 (29320) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2004 12:54:11 -0000 On Thu, Dec 30, 2004 at 09:53:49AM -0300, mario.lobo@ipad.com.br wrote: > Hi everyone ! > > I hope all had a nice Xmas and I wish a happy new year to you all !! > > I?m not sure I saw this issue here before but is there support for the Adaptec Ultra 320 (29320) > scsi controller on FreeBSD 5.3 ? 5.3? yes. Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://weblog.barnet.com.au/edwin/ From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 30 12:58:18 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA21216A4CF for ; Thu, 30 Dec 2004 12:58:18 +0000 (GMT) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id 851A743D41 for ; Thu, 30 Dec 2004 12:58:17 +0000 (GMT) (envelope-from roam@ringlet.net) Received: (qmail 22727 invoked from network); 30 Dec 2004 12:58:13 -0000 Received: from unknown (HELO straylight.ringlet.net) (213.16.36.84) by gandalf.online.bg with SMTP; 30 Dec 2004 12:58:13 -0000 Received: (qmail 75696 invoked by uid 1000); 30 Dec 2004 12:58:15 -0000 Date: Thu, 30 Dec 2004 14:58:15 +0200 From: Peter Pentchev To: mario.lobo@ipad.com.br Message-ID: <20041230125815.GF830@straylight.m.ringlet.net> Mail-Followup-To: mario.lobo@ipad.com.br, freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org References: <41D3D02D.16937.7488E@localhost> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6v9BRtpmy+umdQlo" Content-Disposition: inline In-Reply-To: <41D3D02D.16937.7488E@localhost> User-Agent: Mutt/1.5.6i cc: freebsd-hackers@freebsd.org cc: freebsd-questions@freebsd.org Subject: Re: Support for Adaptec Ultra 320 (29320) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2004 12:58:18 -0000 --6v9BRtpmy+umdQlo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 30, 2004 at 09:53:49AM -0300, mario.lobo@ipad.com.br wrote: > Hi everyone ! >=20 > I hope all had a nice Xmas and I wish a happy new year to you all !! >=20 > I?m not sure I saw this issue here before but is there support for the > Adaptec Ultra 320 (29320) scsi controller on FreeBSD 5.3 ? >=20 > I know it is a new controller. According to the CVS history of the src/sys/dev/aic7xxx/ahd_pci.c file, the 'ahd' driver (which supports Adaptec Ultra 320) was added to FreeBSD about two and a half years ago :) http://cvsweb.FreeBSD.org/src/sys/dev/aic7xxx/ahd_pci.c G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@cnsys.bg roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence is false. --6v9BRtpmy+umdQlo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFB0/tn7Ri2jRYZRVMRAqudAKC8ffyS7w/OQ8rZYHe8QwlRb1uYYgCfSuhY 0ALk+aNxgi2TVFRDXYVvwoY= =V9zF -----END PGP SIGNATURE----- --6v9BRtpmy+umdQlo-- From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 30 13:00:28 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8582B16A4CE for ; Thu, 30 Dec 2004 13:00:28 +0000 (GMT) Received: from nerve.riss-telecom.ru (nerve.riss-telecom.ru [80.66.65.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A95F43D45 for ; Thu, 30 Dec 2004 13:00:27 +0000 (GMT) (envelope-from frol@nerve.riss-telecom.ru) Received: from nerve.riss-telecom.ru (4fr5gfgavy0hndvo@localhost [127.0.0.1]) by nerve.riss-telecom.ru (8.13.1/8.13.1) with ESMTP id iBUD01Uq023781; Thu, 30 Dec 2004 19:00:01 +0600 (NOVT) (envelope-from frol@nerve.riss-telecom.ru) Received: (from frol@localhost) by nerve.riss-telecom.ru (8.13.1/8.13.1/Submit) id iBUD01SJ023780; Thu, 30 Dec 2004 19:00:01 +0600 (NOVT) (envelope-from frol) Date: Thu, 30 Dec 2004 19:00:01 +0600 From: Dmitry Frolov To: FreeBSD Hackers List Message-ID: <20041230130001.GA23464@nerve.riss-telecom.ru> Mail-Followup-To: FreeBSD Hackers List , Tom Alsberg References: <20041227075616.GA9502@cs.huji.ac.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041227075616.GA9502@cs.huji.ac.il> Organization: RISS-Telecom, JSC X-PGP-Fingerprint: 5232 98E7 596E 21C2 52B5 FCAE 8088 3F87 88BC 27B0 User-Agent: Mutt/1.5.6i cc: Tom Alsberg Subject: Re: i386_set_ioperm on FreeBSD 5.3 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2004 13:00:28 -0000 * Tom Alsberg [27.12.2004 13:57]: > Hi there. > > I'm trying to use some code I wrote quite a while ago using Doug > White's FreeBSD IPMI code (kcs.c, send-kcs-command.c, etc.). > > It still works as it did back then on FreeBSD 4.10. On FreeBSD 5.3 it > does not. > > Problem seems to be, that i386_set_ioperm isn't doing what it should. > The program gets SIGBUS when doing outb, while it shouldn't. I was able to work around this by using io(4). wbr&w, dmitry. -- Dmitry Frolov RISS-Telecom Network, Novosibirsk, Russia 66415911@ICQ, +7 3832 NO WA1T, DVF-RIPE From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 30 13:01:15 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 82A7516A4CF for ; Thu, 30 Dec 2004 13:01:15 +0000 (GMT) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id 567B743D41 for ; Thu, 30 Dec 2004 13:01:14 +0000 (GMT) (envelope-from roam@ringlet.net) Received: (qmail 25727 invoked from network); 30 Dec 2004 13:01:10 -0000 Received: from unknown (HELO straylight.ringlet.net) (213.16.36.84) by gandalf.online.bg with SMTP; 30 Dec 2004 13:01:10 -0000 Received: (qmail 75799 invoked by uid 1000); 30 Dec 2004 13:01:12 -0000 Date: Thu, 30 Dec 2004 15:01:12 +0200 From: Peter Pentchev To: Edwin Groothuis , mario.lobo@ipad.com.br, freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org Message-ID: <20041230130112.GG830@straylight.m.ringlet.net> Mail-Followup-To: Edwin Groothuis , mario.lobo@ipad.com.br, freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org References: <41D3D02D.16937.7488E@localhost> <20041230125407.GB1430@k7.mavetju> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="64j1qyTOoGvYcHb1" Content-Disposition: inline In-Reply-To: <20041230125407.GB1430@k7.mavetju> User-Agent: Mutt/1.5.6i Subject: Re: Support for Adaptec Ultra 320 (29320) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2004 13:01:15 -0000 --64j1qyTOoGvYcHb1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 30, 2004 at 11:54:07PM +1100, Edwin Groothuis wrote: > On Thu, Dec 30, 2004 at 09:53:49AM -0300, mario.lobo@ipad.com.br wrote: > > Hi everyone ! > >=20 > > I hope all had a nice Xmas and I wish a happy new year to you all !! > >=20 > > I?m not sure I saw this issue here before but is there support for > > the Adaptec Ultra 320 (29320) scsi controller on FreeBSD 5.3 ? >=20 > 5.3? yes. According to the CVS history of the ahd_pci.c file (URL mentioned in my other reply), the 'ahd' driver is supported not only in 5.3, but also in 5.2.1, 5.2, 5.1, 5.0, and actually all the way back to 4.7 :) G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@cnsys.bg roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If you think this sentence is confusing, then change one pig. --64j1qyTOoGvYcHb1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFB0/wY7Ri2jRYZRVMRAsE+AJ4+hGvnKyFJd29QVf9QiW0UdhoVHwCggB9F v6sfHhOx/4g53kTqhmyUutw= =4sYv -----END PGP SIGNATURE----- --64j1qyTOoGvYcHb1-- From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 30 13:10:46 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8233716A4CE; Thu, 30 Dec 2004 13:10:46 +0000 (GMT) Received: from recife.ipadnet.com.br (recife.ipadnet.com.br [200.249.204.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F4F343D46; Thu, 30 Dec 2004 13:10:45 +0000 (GMT) (envelope-from mario.lobo@ipad.com.br) Received: from marioLobo ([200.249.204.142]) by recife.ipadnet.com.br (8.12.8/8.12.8) with ESMTP id iBUDGxwT002717; Thu, 30 Dec 2004 10:16:59 -0300 From: mario.lobo@ipad.com.br Organization: IPAD To: freebsd-hackers@freebsd.org Date: Thu, 30 Dec 2004 10:14:48 -0300 MIME-Version: 1.0 Message-ID: <41D3D518.6263.1A7E18@localhost> Priority: normal In-reply-to: <20041230125815.GF830@straylight.m.ringlet.net> References: <41D3D02D.16937.7488E@localhost> X-mailer: Pegasus Mail for Windows (4.21c) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body cc: freebsd-questions@freebsd.org Subject: Re: Support for Adaptec Ultra 320 (29320) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: mario.lobo@ipad.com.br List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2004 13:10:46 -0000 Thanks for the quick reply ! We just bought 4 Pentiums HT servers and the person that bought them assumed that because windows Xp has no drivers for it, no-os-else does ! what a bummer ! Worst of all was me, that fell for it, and that have been using Free since 2.2.8, and should have looked into the Docs before posting here ! Sorry for that and thanks for not flaming me ! -- //| //|| // | // || -//--//---|| ARIO LOBO // // || --------------------------------- mario.lobo@ipad.com.br http://www.ipad.com.br On 30 Dec 2004 at 14:58, Peter Pentchev wrote: > On Thu, Dec 30, 2004 at 09:53:49AM -0300, mario.lobo@ipad.com.br wrote: > > Hi everyone ! > > > > I hope all had a nice Xmas and I wish a happy new year to you all !! > > > > I?m not sure I saw this issue here before but is there support for the > > Adaptec Ultra 320 (29320) scsi controller on FreeBSD 5.3 ? > > > > I know it is a new controller. > > According to the CVS history of the src/sys/dev/aic7xxx/ahd_pci.c file, > the 'ahd' driver (which supports Adaptec Ultra 320) was added to FreeBSD > about two and a half years ago :) > > http://cvsweb.FreeBSD.org/src/sys/dev/aic7xxx/ahd_pci.c > > G'luck, > Peter > > -- > Peter Pentchev roam@ringlet.net roam@cnsys.bg roam@FreeBSD.org > PGP key: http://people.FreeBSD.org/~roam/roam.key.asc > Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 > This sentence is false. > From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 30 14:00:11 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2796316A4CE for ; Thu, 30 Dec 2004 14:00:11 +0000 (GMT) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id 257DD43D2D for ; Thu, 30 Dec 2004 14:00:10 +0000 (GMT) (envelope-from roam@ringlet.net) Received: (qmail 23821 invoked from network); 30 Dec 2004 14:00:05 -0000 Received: from unknown (HELO straylight.ringlet.net) (213.16.36.84) by gandalf.online.bg with SMTP; 30 Dec 2004 14:00:05 -0000 Received: (qmail 89301 invoked by uid 1000); 30 Dec 2004 14:00:08 -0000 Date: Thu, 30 Dec 2004 16:00:08 +0200 From: Peter Pentchev To: Maxim Sobolev Message-ID: <20041230140007.GH830@straylight.m.ringlet.net> Mail-Followup-To: Maxim Sobolev , Matteo Riondato , freebsd-hackers@FreeBSD.ORG References: <1104358540.2895.10.camel@kaiser.sig11.org> <20041230103433.GB830@straylight.m.ringlet.net> <1104409708.6657.1.camel@kaiser.sig11.org> <20041230123116.GE830@straylight.m.ringlet.net> <41D4036B.1060600@portaone.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="82evfD9Ogz2JrdWZ" Content-Disposition: inline In-Reply-To: <41D4036B.1060600@portaone.com> User-Agent: Mutt/1.5.6i cc: freebsd-hackers@FreeBSD.ORG cc: Matteo Riondato Subject: Re: Creating Compressed Loop FS from stdin X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2004 14:00:11 -0000 --82evfD9Ogz2JrdWZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 30, 2004 at 03:32:27PM +0200, Maxim Sobolev wrote: > Peter Pentchev wrote: > >On Thu, Dec 30, 2004 at 01:28:28PM +0100, Matteo Riondato wrote: > > > >>Il giorno Gio, 30-12-2004 alle 12:34 +0200, Peter Pentchev ha scritto: > >> > >>>This could be fixed by the following patch. I'm CC'ing Maxim Sobolev, > >>>the author of mkuzip(8); Maxim, do you have any objections to this pat= ch? > >> > >>Thank you for the answer and fo the patch! I hope Maxim will commit it > >>soon. > > > > > >Actually, if Maxim has no objections, I could commit it myself. > >However, it would be totally understandable if he doesn't answer in > >the next day or three, what with the calendar moving ahead and all :) >=20 > It will not help, since AFAIK you can't seek stdin anyway, or even if I= =20 > am wrong and you can seek it to the end you will be unable to seek it=20 > backward. I tested the patch before posting it, fully expecting to find that stdin really cannot be seeked (sought? :), and surprisingly it worked, at least on RELENG_5 as of today! > I've already replied to this message, but Matteo has some very strange=20 > settings of his smtp relay so that neither my original message nor my=20 > follow-up in which I had forwarded mail delivery error message got throug= h. >=20 > -Maxim >=20 > -------- Original Message -------- > Subject: Re: Creating Compressed Loop FS from stdin > Date: Fri, 17 Dec 2004 17:14:48 +0200 > From: Maxim Sobolev > Organization: Porta Software Ltd > To: Matteo Riondato > References: <1103290915.8516.9.camel@kaiser.sig11.org> >=20 > This is not going to work by design unfortunately. cloop format has > serious design flaw: it contains variable-lengh header at the beginning > of the compressed image, so that before doing compression mkuzip(1) uses > stat(2) call at the original file to get its size and reserve necessary > space, which doesn't work with /dev/stdin as you may guess. Original GNU > utility either keeps the whole compressed image in memory or uses some > form of temporary storage (I don't quite remember) to work around this > problem. Well, another solution would be to make mkuzip use a temporary file (obviously, keeping the whole thing in memory would be a bad idea for big ISO filesystems ;). However, as I noted above, my lseek patch works at least for RELENG_5. Can somebody test it on -CURRENT? G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@cnsys.bg roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This inert sentence is my body, but my soul is alive, dancing in the sparks= of your brain. --82evfD9Ogz2JrdWZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFB1Ann7Ri2jRYZRVMRAp8iAJ9guDPyhybLrdP/UaBmAioq8+PiFACfRxdU zS4zglsQT5rHFfPWP45HaMo= =IkSk -----END PGP SIGNATURE----- --82evfD9Ogz2JrdWZ-- From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 30 14:23:57 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D36616A4CE for ; Thu, 30 Dec 2004 14:23:57 +0000 (GMT) Received: from episec.com (episec.com [69.55.237.141]) by mx1.FreeBSD.org (Postfix) with SMTP id F2E6B43D2D for ; Thu, 30 Dec 2004 14:23:56 +0000 (GMT) (envelope-from edelkind-freebsd-hackers@episec.com) Received: (qmail 81961 invoked by uid 1024); 30 Dec 2004 14:23:56 -0000 Date: Thu, 30 Dec 2004 09:23:56 -0500 From: ari edelkind To: freebsd-hackers@FreeBSD.ORG Message-ID: <20041230142356.GQ3608@episec.com> Mail-Followup-To: ari edelkind , freebsd-hackers@FreeBSD.ORG References: <1104358540.2895.10.camel@kaiser.sig11.org> <20041230103433.GB830@straylight.m.ringlet.net> <1104409708.6657.1.camel@kaiser.sig11.org> <20041230123116.GE830@straylight.m.ringlet.net> <41D4036B.1060600@portaone.com> <20041230140007.GH830@straylight.m.ringlet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041230140007.GH830@straylight.m.ringlet.net> Subject: Re: Creating Compressed Loop FS from stdin X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2004 14:23:57 -0000 roam@ringlet.net wrote: > > It will not help, since AFAIK you can't seek stdin anyway, or even if I > > am wrong and you can seek it to the end you will be unable to seek it > > backward. > > I tested the patch before posting it, fully expecting to find that stdin > really cannot be seeked (sought? :), and surprisingly it worked, at least > on RELENG_5 as of today! You can always seek stdin, if stdin happens to be associated with a seekable descriptor. It isn't given any special treatment simply because it has a vector of 0. That is, if you use something along the lines of: % ./seekme Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D518B16A4D1 for ; Thu, 30 Dec 2004 14:55:46 +0000 (GMT) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id 58F0243D48 for ; Thu, 30 Dec 2004 14:55:45 +0000 (GMT) (envelope-from roam@ringlet.net) Received: (qmail 23854 invoked from network); 30 Dec 2004 14:55:40 -0000 Received: from unknown (HELO straylight.ringlet.net) (213.16.36.84) by gandalf.online.bg with SMTP; 30 Dec 2004 14:55:40 -0000 Received: (qmail 10554 invoked by uid 1000); 30 Dec 2004 14:55:43 -0000 Date: Thu, 30 Dec 2004 16:55:43 +0200 From: Peter Pentchev To: Maxim Sobolev Message-ID: <20041230145543.GJ830@straylight.m.ringlet.net> Mail-Followup-To: Maxim Sobolev , Matteo Riondato , freebsd-hackers@FreeBSD.ORG References: <1104358540.2895.10.camel@kaiser.sig11.org> <20041230103433.GB830@straylight.m.ringlet.net> <1104409708.6657.1.camel@kaiser.sig11.org> <20041230123116.GE830@straylight.m.ringlet.net> <41D4036B.1060600@portaone.com> <20041230140007.GH830@straylight.m.ringlet.net> <41D40EA0.2060009@portaone.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="x+RZeZVNR8VILNfK" Content-Disposition: inline In-Reply-To: <41D40EA0.2060009@portaone.com> User-Agent: Mutt/1.5.6i cc: freebsd-hackers@FreeBSD.ORG cc: Matteo Riondato Subject: Re: Creating Compressed Loop FS from stdin X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2004 14:55:47 -0000 --x+RZeZVNR8VILNfK Content-Type: multipart/mixed; boundary="BEa57a89OpeoUzGD" Content-Disposition: inline --BEa57a89OpeoUzGD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 30, 2004 at 04:20:16PM +0200, Maxim Sobolev wrote: > You don't check return code of the second lseek - I bet it fails. This=20 > probably leads to creation of seemingly valid loop fs (i.e. with valid=20 > header), but filled with zeroes or some random junk. I said I'd tested it before posting it the first time. It works. It creates a valid loop fs, containing exactly the files that are in the input ISO image. However, your point is valid; here's another patch which returns to the start only if the original lseek() did not move away (or failed), and checks the return value, too. This version of mkuzip works on today's RELENG_5, as can be seen from the attached mkuzip.script sequence of commands. G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@cnsys.bg roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 Nostalgia ain't what it used to be. --BEa57a89OpeoUzGD Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="mkuzip.script" Content-Transfer-Encoding: quoted-printable Script started on Thu Dec 30 16:50:57 2004 Starting interactive C shell [roam@straylight ~/fbsd/r/src/usr.bin/mkuzip]> `make -V .OBJDIR`/`make -V P= ROG` -v -s 65536 -o dns-stdin.uz /dev/stdin < ~/dns.iso data size 5505024 bytes, number of clusters 84, index lengh 680 bytes cluster #0, in 65536 bytes, out 2263 bytes cluster #1, in 65536 bytes, out 11581 bytes [snip more of the same] cluster #82, in 65536 bytes, out 11684 bytes cluster #83, in 65536 bytes, out 752 bytes padding data with 161 bytes so that file size is multiple of 512 compressed data to 1361920 bytes, saved 4143104 bytes, 75.26% decrease. [roam@straylight ~/fbsd/r/src/usr.bin/mkuzip]> sudo mdconfig -a -f dns-stdi= n.uz otp-md5 455 st1434 ext Password:=20 md0 [roam@straylight ~/fbsd/r/src/usr.bin/mkuzip]> sudo mount_cd9660 /dev/md0.u= zip /mnt [roam@straylight ~/fbsd/r/src/usr.bin/mkuzip]> sudo find /mnt | wc -l 604 [roam@straylight ~/fbsd/r/src/usr.bin/mkuzip]> sudo md5 /mnt/djbdns-1.05/ti= nydns MD5 (/mnt/djbdns-1.05/tinydns) =3D d16c2fe610c19148ff005fb35242561c [roam@straylight ~/fbsd/r/src/usr.bin/mkuzip]> sudo md5 /home/roam/fbsd/r/p= orts/dns/djbdns/work/djbdns-1.05/tinydns MD5 (/home/roam/fbsd/r/ports/dns/djbdns/work/djbdns-1.05/tinydns) =3D d16c2= fe610c19148ff005fb35242561c [roam@straylight ~/fbsd/r/src/usr.bin/mkuzip]> sudo umount /mnt [roam@straylight ~/fbsd/r/src/usr.bin/mkuzip]> sudo mdconfig -d -u 0 [roam@straylight ~/fbsd/r/src/usr.bin/mkuzip]> exit exit Script done on Thu Dec 30 16:52:53 2004 --BEa57a89OpeoUzGD Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="mkuzip-size.patch" Content-Transfer-Encoding: quoted-printable Index: src/usr.bin/mkuzip/mkuzip.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/usr.bin/mkuzip/mkuzip.c,v retrieving revision 1.2 diff -u -r1.2 mkuzip.c --- src/usr.bin/mkuzip/mkuzip.c 10 Sep 2004 23:16:05 -0000 1.2 +++ src/usr.bin/mkuzip/mkuzip.c 30 Dec 2004 14:47:35 -0000 @@ -122,10 +122,28 @@ signal(SIGXFSZ, exit); atexit(cleanup); =20 - if (stat(iname, &sb) !=3D 0) { + fdr =3D open(iname, O_RDONLY); + if (fdr < 0) { + err(1, "%s", iname); + /* Not reached */ + } + + /* Try seeking to the end; if that fails, fall back to fstat() */ + memset(&sb, 0, sizeof(sb)); + sb.st_size =3D lseek(fdr, 0, SEEK_END); + if (sb.st_size < 1) { + if (fstat(fdr, &sb) !=3D 0) { + err(1, "%s", iname); + /* Not reached */ + } + } else if (lseek(fdr, 0, SEEK_SET) !=3D 0) { err(1, "%s", iname); /* Not reached */ } + if (sb.st_size < 1) { + errx(1, "Could not determine the size of %s", iname); + /* Not reached */ + } hdr.nblocks =3D sb.st_size / hdr.blksz; if ((sb.st_size % hdr.blksz) !=3D 0) { if (verbose !=3D 0) @@ -135,11 +153,6 @@ } toc =3D safe_malloc((hdr.nblocks + 1) * sizeof(*toc)); =20 - fdr =3D open(iname, O_RDONLY); - if (fdr < 0) { - err(1, "%s", iname); - /* Not reached */ - } fdw =3D open(oname, O_WRONLY | O_TRUNC | O_CREAT, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH); if (fdw < 0) { --BEa57a89OpeoUzGD-- --x+RZeZVNR8VILNfK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFB1Bbv7Ri2jRYZRVMRAlo2AKCZZwJH/yWQOk4jZqXUsuQwAsKPIQCfRQ0p T+mowuggWUd5tIox/i//QZc= =eg9L -----END PGP SIGNATURE----- --x+RZeZVNR8VILNfK-- From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 30 14:59:51 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 529C416A4CE for ; Thu, 30 Dec 2004 14:59:51 +0000 (GMT) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id 437F543D49 for ; Thu, 30 Dec 2004 14:59:50 +0000 (GMT) (envelope-from roam@ringlet.net) Received: (qmail 25661 invoked from network); 30 Dec 2004 14:59:46 -0000 Received: from unknown (HELO straylight.ringlet.net) (213.16.36.84) by gandalf.online.bg with SMTP; 30 Dec 2004 14:59:46 -0000 Received: (qmail 10618 invoked by uid 1000); 30 Dec 2004 14:59:49 -0000 Date: Thu, 30 Dec 2004 16:59:49 +0200 From: Peter Pentchev To: Maxim Sobolev Message-ID: <20041230145949.GK830@straylight.m.ringlet.net> Mail-Followup-To: Maxim Sobolev , Matteo Riondato , freebsd-hackers@FreeBSD.ORG References: <1104358540.2895.10.camel@kaiser.sig11.org> <20041230103433.GB830@straylight.m.ringlet.net> <1104409708.6657.1.camel@kaiser.sig11.org> <20041230123116.GE830@straylight.m.ringlet.net> <41D4036B.1060600@portaone.com> <20041230140007.GH830@straylight.m.ringlet.net> <41D40EA0.2060009@portaone.com> <20041230145543.GJ830@straylight.m.ringlet.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9/GiYV45wF7IL3Iq" Content-Disposition: inline In-Reply-To: <20041230145543.GJ830@straylight.m.ringlet.net> User-Agent: Mutt/1.5.6i cc: freebsd-hackers@FreeBSD.ORG cc: Matteo Riondato Subject: Re: Creating Compressed Loop FS from stdin X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2004 14:59:51 -0000 --9/GiYV45wF7IL3Iq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 30, 2004 at 04:55:43PM +0200, Peter Pentchev wrote: > On Thu, Dec 30, 2004 at 04:20:16PM +0200, Maxim Sobolev wrote: > > You don't check return code of the second lseek - I bet it fails. This= =20 > > probably leads to creation of seemingly valid loop fs (i.e. with valid= =20 > > header), but filled with zeroes or some random junk. >=20 > I said I'd tested it before posting it the first time. It works. > It creates a valid loop fs, containing exactly the files that are in > the input ISO image. Errr. Oops. Sorry everyone - the patch does not really work. I keep testing it with a *file* passed on mkuzip's stdin, all the while feeling surprised that lseek() works on the pipe... when there is no pipe at all :( I just tested it with a real pipe, and of course, it failed. Again, sorry for wasting your time; I guess it'd be best if I tucked in for the holidays now :( G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@cnsys.bg roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 The rest of this sentence is written in Thailand, on --9/GiYV45wF7IL3Iq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFB1Bfk7Ri2jRYZRVMRAtTsAKCX3XQ6sGIKifE0+u478mdDWTQK7QCgp8f+ vzbE8dAaD85Q963ZxkiDFYQ= =9zP0 -----END PGP SIGNATURE----- --9/GiYV45wF7IL3Iq-- From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 29 15:12:02 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D5DDD16A4CE for ; Wed, 29 Dec 2004 15:12:02 +0000 (GMT) Received: from vsmtp1.tin.it (vsmtp1.tin.it [212.216.176.141]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE7EC43D2D for ; Wed, 29 Dec 2004 15:12:01 +0000 (GMT) (envelope-from rionda@freesbie.org) Received: from kaiser.sig11.org (82.50.115.31) by vsmtp1.tin.it (7.0.027) id 41CEBADE00162290 for freebsd-hackers@freebsd.org; Wed, 29 Dec 2004 16:11:58 +0100 Received: from localhost.localdomain (localhost [127.0.0.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by kaiser.sig11.org (Postfix) with ESMTP id 638116181 for ; Wed, 29 Dec 2004 16:11:57 +0100 (CET) From: Matteo Riondato To: freebsd-hackers@freebsd.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-a7gS7PyUCiKYQlrqwK32" Date: Wed, 29 Dec 2004 16:11:56 +0100 Message-Id: <1104333116.2895.3.camel@kaiser.sig11.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 FreeBSD GNOME Team Port X-Mailman-Approved-At: Thu, 30 Dec 2004 16:05:45 +0000 Subject: Creating Compressed Loop FS from stdin X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2004 15:12:02 -0000 --=-a7gS7PyUCiKYQlrqwK32 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi folks! I think you know what FreeSBIE is and that we use compressed loop filesystems for /usr and /var directories on our LiveCD.=20 At the moment, to create compressed filesystems, we rely on sysutils/cloop-utils, but I know /usr/bin/mkuzip is present in HEAD and in RELENG_5 and would like to switch to that. However, it seems that I cannot create valid cloopfs with mkuzip. To create the cloop image, I use: /usr/local/bin/mkisofs -lrJL $FREESBIEBASEDIR/usr | /usr/bin/mkuzip -v \ -o $FREESBIEBASEDIR/cloop/usr.cloop -s 65536 /dev/stdin (similar line for /var clooped image) Creation of the clooped images does finish without any error, but I cannot mount it: #kldload geom_uzip #mdconfig -a -t vnode usr.cloop md0 #mount_cd9660 /dev/md0.uzip /mnt mount_cd9660: /dev/md0.uzip: Input/output error Can you give me any hint? Perhaps I'm missing something in the creation of the image. I will provide further information if needed. Thank you in advance. Best Regards --=20 Rionda aka Matteo Riondato GUFI Staff Member (http://www.gufi.org) FreeSBIE Developer (http://www.freesbie.org) BSD-FAQ-it Main Developer (http://utenti.gufi.org/~rionda) Sent from: kaiser.sig11.org running FreeBSD-6.0-CURRENT --=-a7gS7PyUCiKYQlrqwK32 Content-Type: application/pgp-signature; name=signature.asc Content-Description: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBB0sk82Mp4pR7Fa+wRAjLLAJ9C19c0sh2AOwTJ8BGSqWcmUfmDnwCeIVDH N4cbzWY6imrTWKq48j0iYY8= =6z5v -----END PGP SIGNATURE----- --=-a7gS7PyUCiKYQlrqwK32-- From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 30 13:39:26 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5289E16A4CE for ; Thu, 30 Dec 2004 13:39:26 +0000 (GMT) Received: from www.portaone.com (web.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5707543D1D for ; Thu, 30 Dec 2004 13:39:25 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [192.168.0.73] (portacare.portaone.com [195.140.247.242]) (authenticated bits=0) by www.portaone.com (8.12.11/8.12.11) with ESMTP id iBUDWZuL016318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Dec 2004 14:32:37 +0100 (CET) (envelope-from sobomax@portaone.com) Message-ID: <41D4036B.1060600@portaone.com> Date: Thu, 30 Dec 2004 15:32:27 +0200 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Pentchev References: <1104358540.2895.10.camel@kaiser.sig11.org> <20041230103433.GB830@straylight.m.ringlet.net> <1104409708.6657.1.camel@kaiser.sig11.org> <20041230123116.GE830@straylight.m.ringlet.net> In-Reply-To: <20041230123116.GE830@straylight.m.ringlet.net> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/589/Wed Nov 17 13:38:41 2004 clamav-milter version 0.80j on www.portaone.com X-Virus-Status: Clean X-Mailman-Approved-At: Thu, 30 Dec 2004 16:05:45 +0000 cc: freebsd-hackers@FreeBSD.ORG cc: Matteo Riondato Subject: Re: Creating Compressed Loop FS from stdin X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2004 13:39:26 -0000 Peter Pentchev wrote: > On Thu, Dec 30, 2004 at 01:28:28PM +0100, Matteo Riondato wrote: > >>Il giorno Gio, 30-12-2004 alle 12:34 +0200, Peter Pentchev ha scritto: >> >>>This could be fixed by the following patch. I'm CC'ing Maxim Sobolev, >>>the author of mkuzip(8); Maxim, do you have any objections to this patch? >> >>Thank you for the answer and fo the patch! I hope Maxim will commit it >>soon. > > > Actually, if Maxim has no objections, I could commit it myself. > However, it would be totally understandable if he doesn't answer in > the next day or three, what with the calendar moving ahead and all :) It will not help, since AFAIK you can't seek stdin anyway, or even if I am wrong and you can seek it to the end you will be unable to seek it backward. I've already replied to this message, but Matteo has some very strange settings of his smtp relay so that neither my original message nor my follow-up in which I had forwarded mail delivery error message got through. -Maxim -------- Original Message -------- Subject: Re: Creating Compressed Loop FS from stdin Date: Fri, 17 Dec 2004 17:14:48 +0200 From: Maxim Sobolev Organization: Porta Software Ltd To: Matteo Riondato References: <1103290915.8516.9.camel@kaiser.sig11.org> This is not going to work by design unfortunately. cloop format has serious design flaw: it contains variable-lengh header at the beginning of the compressed image, so that before doing compression mkuzip(1) uses stat(2) call at the original file to get its size and reserve necessary space, which doesn't work with /dev/stdin as you may guess. Original GNU utility either keeps the whole compressed image in memory or uses some form of temporary storage (I don't quite remember) to work around this problem. Regards, Maxim -------- Original Message -------- Subject: Returned mail: see transcript for details Date: Fri, 17 Dec 2004 16:14:58 +0100 (CET) From: Mail Delivery Subsystem To: The original message was received at Fri, 17 Dec 2004 16:14:55 +0100 (CET) from [192.168.1.26] ----- The following addresses had permanent fatal errors ----- (reason: 550 Error: Sorry, unallowed MIME charset (too much spam)) ----- Transcript of session follows ----- ... while talking to relay.gufi.org.: >>> DATA <<< 550 Error: Sorry, unallowed MIME charset (too much spam) 554 5.0.0 Service unavailable From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 30 14:20:30 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC4DC16A4CE for ; Thu, 30 Dec 2004 14:20:30 +0000 (GMT) Received: from www.portaone.com (web.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE5CF43D49 for ; Thu, 30 Dec 2004 14:20:29 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [192.168.0.73] (portacare.portaone.com [195.140.247.242]) (authenticated bits=0) by www.portaone.com (8.12.11/8.12.11) with ESMTP id iBUEKOn7021787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Dec 2004 15:20:26 +0100 (CET) (envelope-from sobomax@portaone.com) Message-ID: <41D40EA0.2060009@portaone.com> Date: Thu, 30 Dec 2004 16:20:16 +0200 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Pentchev References: <1104358540.2895.10.camel@kaiser.sig11.org> <20041230103433.GB830@straylight.m.ringlet.net> <1104409708.6657.1.camel@kaiser.sig11.org> <20041230123116.GE830@straylight.m.ringlet.net> <41D4036B.1060600@portaone.com> <20041230140007.GH830@straylight.m.ringlet.net> In-Reply-To: <20041230140007.GH830@straylight.m.ringlet.net> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/589/Wed Nov 17 13:38:41 2004 clamav-milter version 0.80j on www.portaone.com X-Virus-Status: Clean X-Mailman-Approved-At: Thu, 30 Dec 2004 16:05:45 +0000 cc: freebsd-hackers@FreeBSD.ORG cc: Matteo Riondato Subject: Re: Creating Compressed Loop FS from stdin X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2004 14:20:31 -0000 You don't check return code of the second lseek - I bet it fails. This probably leads to creation of seemingly valid loop fs (i.e. with valid header), but filled with zeroes or some random junk. -Maxim Peter Pentchev wrote: > On Thu, Dec 30, 2004 at 03:32:27PM +0200, Maxim Sobolev wrote: > >>Peter Pentchev wrote: >> >>>On Thu, Dec 30, 2004 at 01:28:28PM +0100, Matteo Riondato wrote: >>> >>> >>>>Il giorno Gio, 30-12-2004 alle 12:34 +0200, Peter Pentchev ha scritto: >>>> >>>> >>>>>This could be fixed by the following patch. I'm CC'ing Maxim Sobolev, >>>>>the author of mkuzip(8); Maxim, do you have any objections to this patch? >>>> >>>>Thank you for the answer and fo the patch! I hope Maxim will commit it >>>>soon. >>> >>> >>>Actually, if Maxim has no objections, I could commit it myself. >>>However, it would be totally understandable if he doesn't answer in >>>the next day or three, what with the calendar moving ahead and all :) >> >>It will not help, since AFAIK you can't seek stdin anyway, or even if I >>am wrong and you can seek it to the end you will be unable to seek it >>backward. > > > I tested the patch before posting it, fully expecting to find that stdin > really cannot be seeked (sought? :), and surprisingly it worked, at least > on RELENG_5 as of today! > > >>I've already replied to this message, but Matteo has some very strange >>settings of his smtp relay so that neither my original message nor my >>follow-up in which I had forwarded mail delivery error message got through. >> >>-Maxim >> >>-------- Original Message -------- >>Subject: Re: Creating Compressed Loop FS from stdin >>Date: Fri, 17 Dec 2004 17:14:48 +0200 >>From: Maxim Sobolev >>Organization: Porta Software Ltd >>To: Matteo Riondato >>References: <1103290915.8516.9.camel@kaiser.sig11.org> >> >>This is not going to work by design unfortunately. cloop format has >>serious design flaw: it contains variable-lengh header at the beginning >>of the compressed image, so that before doing compression mkuzip(1) uses >>stat(2) call at the original file to get its size and reserve necessary >>space, which doesn't work with /dev/stdin as you may guess. Original GNU >>utility either keeps the whole compressed image in memory or uses some >>form of temporary storage (I don't quite remember) to work around this >>problem. > > > Well, another solution would be to make mkuzip use a temporary file > (obviously, keeping the whole thing in memory would be a bad idea for > big ISO filesystems ;). However, as I noted above, my lseek patch > works at least for RELENG_5. Can somebody test it on -CURRENT? > > G'luck, > Peter > From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 30 16:39:26 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 968B616A4CE for ; Thu, 30 Dec 2004 16:39:26 +0000 (GMT) Received: from www.portaone.com (web.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E99443D1D for ; Thu, 30 Dec 2004 16:39:25 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [192.168.0.73] (portacare.portaone.com [195.140.247.242]) (authenticated bits=0) by www.portaone.com (8.12.11/8.12.11) with ESMTP id iBUF8Imj027066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Dec 2004 16:08:20 +0100 (CET) (envelope-from sobomax@portaone.com) Message-ID: <41D419DA.4050603@portaone.com> Date: Thu, 30 Dec 2004 17:08:10 +0200 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Pentchev References: <1104358540.2895.10.camel@kaiser.sig11.org> <20041230103433.GB830@straylight.m.ringlet.net> <1104409708.6657.1.camel@kaiser.sig11.org> <20041230123116.GE830@straylight.m.ringlet.net> <41D4036B.1060600@portaone.com> <20041230140007.GH830@straylight.m.ringlet.net> <41D40EA0.2060009@portaone.com> <20041230145543.GJ830@straylight.m.ringlet.net> <20041230145949.GK830@straylight.m.ringlet.net> In-Reply-To: <20041230145949.GK830@straylight.m.ringlet.net> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/589/Wed Nov 17 13:38:41 2004 clamav-milter version 0.80j on www.portaone.com X-Virus-Status: Clean X-Mailman-Approved-At: Thu, 30 Dec 2004 16:44:27 +0000 cc: freebsd-hackers@FreeBSD.ORG cc: Matteo Riondato Subject: Re: Creating Compressed Loop FS from stdin X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2004 16:39:26 -0000 Never mind - people are inheretedly error prone creatures. ;-) In your case shell has been passing file descriptor of the open file, not pipe, so that seeking has been working properly. Anyway, I think that your patch is useful, since it should allow using disk devices. -Maxim Peter Pentchev wrote: > On Thu, Dec 30, 2004 at 04:55:43PM +0200, Peter Pentchev wrote: > >>On Thu, Dec 30, 2004 at 04:20:16PM +0200, Maxim Sobolev wrote: >> >>>You don't check return code of the second lseek - I bet it fails. This >>>probably leads to creation of seemingly valid loop fs (i.e. with valid >>>header), but filled with zeroes or some random junk. >> >>I said I'd tested it before posting it the first time. It works. >>It creates a valid loop fs, containing exactly the files that are in >>the input ISO image. > > > Errr. Oops. > > Sorry everyone - the patch does not really work. I keep testing it with > a *file* passed on mkuzip's stdin, all the while feeling surprised that > lseek() works on the pipe... when there is no pipe at all :( > > I just tested it with a real pipe, and of course, it failed. Again, > sorry for wasting your time; I guess it'd be best if I tucked in for > the holidays now :( > > G'luck, > Peter > From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 30 19:28:52 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CFEEB16A4CE for ; Thu, 30 Dec 2004 19:28:52 +0000 (GMT) Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id E13D843D3F for ; Thu, 30 Dec 2004 19:28:51 +0000 (GMT) (envelope-from erik.u@dnainternet.net) Received: from b-216-194.cable.kpy.customers.dnainternet.fi ([212.149.216.194]:56880smtp2.dnainternet.net with ESMTP id S1228771AbUL3T2u (ORCPT ); Thu, 30 Dec 2004 21:28:50 +0200 Message-ID: <41D456F1.50702@dnainternet.net> Date: Thu, 30 Dec 2004 21:28:49 +0200 From: Erik Udo User-Agent: Mozilla Thunderbird 1.0 (X11/20041209) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Asus a7v880 mobo integrated sound not working X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2004 19:28:53 -0000 On FreeBSD 5.3-STABLE (cvsupped few hours ago) I haven't gotten integrated sound working on my motherboard. I should have AD1888 AC97. I almost got it working using the snd_via8233 driver. Here's some more info: pcm0: port 0xe400-0xe4ff irq 22 at device 17.5 on pci0 pcm0: [GIANT-LOCKED] pcm0: pcm0@pci0:17:5: class=0x040100 card=0x810d1043 chip=0x30591106 rev=0x60 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT8233/33A/8235/8237 AC97 Enhanced Audio Controller' class = multimedia subclass = audio Mixer vol is currently set to 100:10 Mixer pcm is currently set to 46:46 It just plays everything fine, xmms doesn't give any errors about missing device etc. The audio analyser shows jumping bars and so on. I just can't hear the sound. I tried all sockets, but it works fine on MS Windows. So it's a driver problem. And here's what i've done: Kldload snd_dirver (loaded all sound modules) Added the line "{ 0x41445368, 0x00, 0, "AD1888", 0 }," to ac97.c (dmesg changes) I tried FreeSBIE 1.1, it had the same problems too. So i guess this can be solved with a simple patch. Could anyone do that? Or even help me? I'll provide any info needed asap. From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 30 19:39:15 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 53EA516A4CE for ; Thu, 30 Dec 2004 19:39:15 +0000 (GMT) Received: from ds.netgate.net (ds.netgate.net [205.214.170.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F9B543D1F for ; Thu, 30 Dec 2004 19:39:15 +0000 (GMT) (envelope-from ctodd@chrismiller.com) Received: (qmail 18908 invoked from network); 30 Dec 2004 19:39:11 -0000 Received: from vp4.netgate.net (ibrew@205.214.170.248) by ds.netgate.net with SMTP; 30 Dec 2004 19:39:11 -0000 Date: Thu, 30 Dec 2004 11:39:11 -0800 (PST) From: ctodd@chrismiller.com X-X-Sender: ibrew@vp4.netgate.net To: Erik Udo In-Reply-To: <41D456F1.50702@dnainternet.net> Message-ID: References: <41D456F1.50702@dnainternet.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org Subject: Re: Asus a7v880 mobo integrated sound not working X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2004 19:39:15 -0000 On Thu, 30 Dec 2004, Erik Udo wrote: > On FreeBSD 5.3-STABLE (cvsupped few hours ago) > > I haven't gotten integrated sound working on my > motherboard. I should have AD1888 AC97. I almost got it working > using the snd_via8233 driver. Try using the opensound driver, it's free for personal use, you just have to reinstall it when the trial version expires. If you like it, it's $30. I tried this driver out because I have 8 channel sound, and it sees everything on the card. I haven't tried it under X apps yet. Also you might try installing ximp3-0.1.15 from ports and play an mp3 at the command line. You can also `cat sndstat` to look for problems. You may need to increase the verbosity of `sysctl hw.snd.verbose` to 2 or 3 to find out what may be causing your problem. Hope this helps. Chris From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 30 20:40:01 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CAECE16A4CE for ; Thu, 30 Dec 2004 20:40:01 +0000 (GMT) Received: from sasami.jurai.net (sasami.jurai.net [69.17.104.113]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5598943D2D for ; Thu, 30 Dec 2004 20:40:01 +0000 (GMT) (envelope-from mdodd@FreeBSD.ORG) Received: from sasami.jurai.net (winter@sasami.jurai.net [69.17.104.113]) by sasami.jurai.net (8.13.1/8.13.1) with ESMTP id iBUKdtSc077698; Thu, 30 Dec 2004 15:39:57 -0500 (EST) (envelope-from mdodd@FreeBSD.ORG) Date: Thu, 30 Dec 2004 15:39:55 -0500 (EST) From: "Matthew N. Dodd" X-X-Sender: winter@sasami.jurai.net To: Erik Udo In-Reply-To: <41D456F1.50702@dnainternet.net> Message-ID: <20041230153657.A22202@sasami.jurai.net> References: <41D456F1.50702@dnainternet.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.5.6 (sasami.jurai.net [69.17.104.113]); Thu, 30 Dec 2004 15:39:57 -0500 (EST) cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Asus a7v880 mobo integrated sound not working X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2004 20:40:01 -0000 On Thu, 30 Dec 2004, Erik Udo wrote: > And here's what i've done: > Kldload snd_dirver (loaded all sound modules) > Added the line "{ 0x41445368, 0x00, 0, "AD1888", 0 }," to ac97.c > (dmesg changes) > I tried FreeSBIE 1.1, it had the same problems too. > > So i guess this can be solved with a simple patch. Could anyone do that? Try this line in ac97.c: { 0x41445368, 0x00, 0, "AD1888", ad198x_patch }, -- 10 40 80 C0 00 FF FF FF FF C0 00 00 00 00 10 AA AA 03 00 00 00 08 00 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 30 21:10:06 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 24B9D16A4CE for ; Thu, 30 Dec 2004 21:10:06 +0000 (GMT) Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4397943D49 for ; Thu, 30 Dec 2004 21:10:05 +0000 (GMT) (envelope-from erik.u@dnainternet.net) Received: from b-216-194.cable.kpy.customers.dnainternet.fi ([212.149.216.194]:59894smtp2.dnainternet.net with ESMTP id S1228759AbUL3VKD (ORCPT ); Thu, 30 Dec 2004 23:10:03 +0200 Message-ID: <41D46EAA.4020708@dnainternet.net> Date: Thu, 30 Dec 2004 23:10:02 +0200 From: Erik Udo User-Agent: Mozilla Thunderbird 1.0 (X11/20041209) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <41D456F1.50702@dnainternet.net> <20041230153657.A22202@sasami.jurai.net> In-Reply-To: <20041230153657.A22202@sasami.jurai.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Asus a7v880 mobo integrated sound not working X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2004 21:10:06 -0000 Matthew N. Dodd wrote: > On Thu, 30 Dec 2004, Erik Udo wrote: > >> And here's what i've done: >> Kldload snd_dirver (loaded all sound modules) >> Added the line "{ 0x41445368, 0x00, 0, "AD1888", 0 }," to >> ac97.c (dmesg changes) >> I tried FreeSBIE 1.1, it had the same problems too. >> >> So i guess this can be solved with a simple patch. Could anyone do that? > > > Try this line in ac97.c: > > { 0x41445368, 0x00, 0, "AD1888", ad198x_patch }, > Heh, thanks. I got the audio working already. I found some kern/70XXX bugreport that had a patch that made audio working! This is AWESOME! So integrated LAN worked in the first try, and audio does too now. Asus a7v880 is a motherboard i recommend for FreeBSD :) I just hope someone puts this in RELENG_5. --- sys/dev/sound/pcm/ac97.c.orig Tue Nov 11 23:15:17 2003 +++ sys/dev/sound/pcm/ac97.c Tue Aug 10 23:58:11 2004 @@ -124,6 +124,7 @@ { 0x41445360, 0x00, 0, "AD1885", 0 }, { 0x41445361, 0x00, 0, "AD1886", ad1886_patch }, { 0x41445362, 0x00, 0, "AD1887", 0 }, + { 0x41445368, 0x00, 0, "AD1888", ad198x_patch }, { 0x41445363, 0x00, 0, "AD1886A", 0 }, { 0x41445370, 0x00, 0, "AD1980", ad198x_patch }, { 0x41445372, 0x00, 0, "AD1981A", 0 }, From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 30 21:33:45 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE50D16A4CF for ; Thu, 30 Dec 2004 21:33:45 +0000 (GMT) Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71BA043D1F for ; Thu, 30 Dec 2004 21:33:45 +0000 (GMT) (envelope-from erik.u@dnainternet.net) Received: from b-216-194.cable.kpy.customers.dnainternet.fi ([212.149.216.194]:63531smtp2.dnainternet.net with ESMTP id S1228782AbUL3Vdo (ORCPT ); Thu, 30 Dec 2004 23:33:44 +0200 Message-ID: <41D47438.2040407@dnainternet.net> Date: Thu, 30 Dec 2004 23:33:44 +0200 From: Erik Udo User-Agent: Mozilla Thunderbird 1.0 (X11/20041209) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <41D456F1.50702@dnainternet.net> <20041230153657.A22202@sasami.jurai.net> <41D46EAA.4020708@dnainternet.net> In-Reply-To: <41D46EAA.4020708@dnainternet.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Asus a7v880 mobo integrated sound not working X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-hackers@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2004 21:33:45 -0000 Erik Udo wrote: > Matthew N. Dodd wrote: > >> On Thu, 30 Dec 2004, Erik Udo wrote: >> >>> And here's what i've done: >>> Kldload snd_dirver (loaded all sound modules) >>> Added the line "{ 0x41445368, 0x00, 0, "AD1888", 0 }," to >>> ac97.c (dmesg changes) >>> I tried FreeSBIE 1.1, it had the same problems too. >>> >>> So i guess this can be solved with a simple patch. Could anyone do that? >> >> >> >> Try this line in ac97.c: >> >> { 0x41445368, 0x00, 0, "AD1888", ad198x_patch }, >> > Heh, thanks. > I got the audio working already. I found some kern/70XXX bugreport > that had a patch that made audio working! This is AWESOME! > So integrated LAN worked in the first try, and audio does too now. > Asus a7v880 is a motherboard i recommend for FreeBSD :) > I just hope someone puts this in RELENG_5. > > --- sys/dev/sound/pcm/ac97.c.orig Tue Nov 11 23:15:17 2003 > +++ sys/dev/sound/pcm/ac97.c Tue Aug 10 23:58:11 2004 > @@ -124,6 +124,7 @@ > { 0x41445360, 0x00, 0, "AD1885", 0 }, > { 0x41445361, 0x00, 0, "AD1886", ad1886_patch }, > { 0x41445362, 0x00, 0, "AD1887", 0 }, > + { 0x41445368, 0x00, 0, "AD1888", ad198x_patch }, > { 0x41445363, 0x00, 0, "AD1886A", 0 }, > { 0x41445370, 0x00, 0, "AD1980", ad198x_patch }, > { 0x41445372, 0x00, 0, "AD1981A", 0 }, > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > I take that back... The sound rate is too fast. I think i should set hw.snd.pcm0.ac97rate to 48000 but there is no hw.snd.pcm0.ac97rate... From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 31 00:06:23 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77A7416A4CE for ; Fri, 31 Dec 2004 00:06:23 +0000 (GMT) Received: from backmaster.cdsnet.net (backmaster.cdsnet.net [63.163.68.2]) by mx1.FreeBSD.org (Postfix) with SMTP id 1703843D49 for ; Fri, 31 Dec 2004 00:06:23 +0000 (GMT) (envelope-from mrcpu@backmaster.cdsnet.net) Received: (qmail 34789 invoked by uid 29999); 31 Dec 2004 00:06:22 -0000 Date: Thu, 30 Dec 2004 16:06:22 -0800 From: Jaye Mathisen To: hackers@freebsd.org Message-ID: <20041231000622.GJ2992@backmaster.cdsnet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i X-Mailman-Approved-At: Fri, 31 Dec 2004 12:56:41 +0000 Subject: Anybody have a working X config file for 5.3 and x.org under vmware workstation? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2004 00:06:23 -0000 I've kind of switched to using vmware to host my FreeBSD OS, and usually do everything from the command line. But now I guess I'd like X. There's some old stuff on the vmware site for drivers for older versions of FreeBSD, but I'd like to use 5.3 and x.org... Thanks in advance. From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 31 06:36:09 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F02A16A4CE for ; Fri, 31 Dec 2004 06:36:09 +0000 (GMT) Received: from web60604.mail.yahoo.com (web60604.mail.yahoo.com [216.109.118.242]) by mx1.FreeBSD.org (Postfix) with SMTP id 8A36143D54 for ; Fri, 31 Dec 2004 06:36:08 +0000 (GMT) (envelope-from kb9agt@yahoo.com) Received: (qmail 42914 invoked by uid 60001); 31 Dec 2004 06:36:07 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=zF/oGBiyP0CShyicPD8LBVjFjKs24r4FA0QqMmmABc3lH1H2iDTDiQ/tqlrkFrE4QODvBYS95SW+fK/MdkZNUl1cqNC71v+UaZH9bzRsn8hr9TVS9Oosm9f7GbPDkq6Jhh2a2LbS7dlw1SCPJLxHh1i3hMzLbb/yot04LE0KGpY= ; Message-ID: <20041231063607.42912.qmail@web60604.mail.yahoo.com> Received: from [207.112.224.53] by web60604.mail.yahoo.com via HTTP; Thu, 30 Dec 2004 22:36:07 PST Date: Thu, 30 Dec 2004 22:36:07 -0800 (PST) From: Douglas Allen To: freebsd-hackers@freebsd.org MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 31 Dec 2004 12:56:41 +0000 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Networking Two Computers via USB X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2004 06:36:09 -0000 Hi hackers, I am interested in connecting my Linux machine to my windows XP machine. I was going to try the USB ports first. Now I've opened a can of worms. Assuming one could buy a USB A-male to A-male cable, is there a danger in connecting each computer directly? Where can I get more information on the pin outs of the USB ports? I see that adaptors are sold for such purposes. Is that because there is some danger of frying those ports? I know there is a power connection on a USB port. I don't need to supply power to any PC port. What leads may I use just for data? Do they need to be like a null- modem cable? Probably that's why there are so many schemes to xfer data such as flash memory keys. I want to go direct without a hub or an adaptor. Is there a cable to make it all work ok? Any reply would be greatly welcome. 73s all. --------------------------------- Do you Yahoo!? Yahoo! Mail - You care about security. So do we. From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 31 13:29:32 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2DE6C16A4CE for ; Fri, 31 Dec 2004 13:29:32 +0000 (GMT) Received: from mail27.syd.optusnet.com.au (mail27.syd.optusnet.com.au [211.29.133.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6852A43D41 for ; Fri, 31 Dec 2004 13:29:31 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) iBVDTTmL002968 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 1 Jan 2005 00:29:30 +1100 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])iBVDTTxP028739; Sat, 1 Jan 2005 00:29:29 +1100 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)iBVDTSci028738; Sat, 1 Jan 2005 00:29:28 +1100 (EST) (envelope-from pjeremy) Date: Sat, 1 Jan 2005 00:29:28 +1100 From: Peter Jeremy To: Jaye Mathisen Message-ID: <20041231132928.GB28111@cirb503493.alcatel.com.au> References: <20041231000622.GJ2992@backmaster.cdsnet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041231000622.GJ2992@backmaster.cdsnet.net> User-Agent: Mutt/1.4.2i cc: hackers@freebsd.org Subject: Re: Anybody have a working X config file for 5.3 and x.org under vmware workstation? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2004 13:29:32 -0000 On Thu, 2004-Dec-30 16:06:22 -0800, Jaye Mathisen wrote: >There's some old stuff on the vmware site for drivers for older versions >of FreeBSD, but I'd like to use 5.3 and x.org... I've found it "just works" (TM) - at least with VMware 4.5. Use the VMware drivers in X.org. There is one thing that you need to manually configure - from memory, it's the resolution. My actual config files are at work and I won't have access to them for another week and a bit. -- Peter Jeremy From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 31 14:56:22 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B52BC16A4CE for ; Fri, 31 Dec 2004 14:56:22 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 679C543D4C for ; Fri, 31 Dec 2004 14:56:22 +0000 (GMT) (envelope-from svs.santosh@gmail.com) Received: by rproxy.gmail.com with SMTP id g11so155852rne for ; Fri, 31 Dec 2004 06:56:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=J+ZKbppNIo6lqbfm/VhcIcHRerrNizWHQd892anmYdfQOPpK1+Ji6+LSsnTUUpMi/GU7FTW89YiYe1A/JfMxSQW2yg1h8q7b3hsHZlrnNvO8o8+NwZQ3gXiC9Ww3ui6zYE53sRcDoY4KNz4Me9U3oT8TLMM9FFnAtZB7YFOAhag= Received: by 10.38.12.19 with SMTP id 19mr276715rnl; Fri, 31 Dec 2004 06:56:21 -0800 (PST) Received: by 10.38.24.39 with HTTP; Fri, 31 Dec 2004 06:56:21 -0800 (PST) Message-ID: Date: Fri, 31 Dec 2004 20:26:21 +0530 From: Venkata Subramanian To: hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Wish You All a HAPPY & PROSPEROUS NEW YEAR.. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Venkata Subramanian List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2004 14:56:22 -0000 Hi All, We all done a Great Job in 2004, let the Greatness Continue.... I wish all of you a Very Happy and Prosperous New Year 2005 Thanks, Venkat From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 31 15:46:55 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B1C016A4CE for ; Fri, 31 Dec 2004 15:46:55 +0000 (GMT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E55643D1F for ; Fri, 31 Dec 2004 15:46:54 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [10.1.1.7]) iBVFkoHo006572 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 31 Dec 2004 16:46:52 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id iBVFjuUU071137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Dec 2004 16:45:57 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.11/8.12.11) with ESMTP id iBVFjupO016556; Fri, 31 Dec 2004 16:45:56 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id iBVFjuiH016555; Fri, 31 Dec 2004 16:45:56 +0100 (CET) (envelope-from ticso) Date: Fri, 31 Dec 2004 16:45:56 +0100 From: Bernd Walter To: Douglas Allen Message-ID: <20041231154555.GX81585@cicely12.cicely.de> References: <20041231063607.42912.qmail@web60604.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041231063607.42912.qmail@web60604.mail.yahoo.com> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.6i X-Spam-Status: No, hits=-4.9 required=3.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Report: * -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on cicely12.cicely.de cc: freebsd-hackers@freebsd.org Subject: Re: Networking Two Computers via USB X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2004 15:46:55 -0000 On Thu, Dec 30, 2004 at 10:36:07PM -0800, Douglas Allen wrote: > Hi hackers, > > I am interested in connecting my Linux machine to my windows XP machine. Neither Linux nor Windows is FreeBSD, why do you ask in a FreeBSD list? > I was going to try the USB ports first. Now I've opened a can of worms. > > Assuming one could buy a USB A-male to A-male cable, is there a danger in connecting > > each computer directly? Where can I get more information on the pin outs of the USB ports? > > I see that adaptors are sold for such purposes. Is that because there is some danger of > > frying those ports? I know there is a power connection on a USB port. I don't need to supply > > power to any PC port. What leads may I use just for data? Do they need to be like a null- > > modem cable? Probably that's why there are so many schemes to xfer data such as flash > > memory keys. I want to go direct without a hub or an adaptor. Is there a cable to make it > > all work ok? Any reply would be greatly welcome. 73s all. USB is single master. You can't connect two masters (hosts) directly together. A-A cables are illegal in sense of the USB specs, they don't work and can even damage the systems. Thosese cables are mostly sold because in a early USB specification there was only A connectors and a early hardware designs used A connectors instead of B. I personally would avoid such hardware. There are other options to connects computers together via USB. - Use two USB-Ethernet adapters and X-link them together and do Ethernet. - Use two USB-serial adapters and X-link them together and do ppp, slip, xmomdem or whatever. - Use a special host to host adapter - those simulate an serial adapter at each host side. AFAIK those adapters are all limited to USB-1.1 speed, so the Ethernet way can be faster if both sides can do high speed. -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 31 18:19:58 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5DD6816A4CE for ; Fri, 31 Dec 2004 18:19:58 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC05643D2D for ; Fri, 31 Dec 2004 18:19:57 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id iBVIISgn007063; Fri, 31 Dec 2004 11:18:28 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 31 Dec 2004 11:18:39 -0700 (MST) Message-Id: <20041231.111839.28844669.imp@bsdimp.com> To: kb9agt@yahoo.com From: "M. Warner Losh" In-Reply-To: <20041231063607.42912.qmail@web60604.mail.yahoo.com> References: <20041231063607.42912.qmail@web60604.mail.yahoo.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: Networking Two Computers via USB X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2004 18:19:58 -0000 In message: <20041231063607.42912.qmail@web60604.mail.yahoo.com> Douglas Allen writes: : I was going to try the USB ports first. Now I've opened a can of worms. You can't do it directly, but need a special fob that supports this. The reason is that USB has only one root, and both hosts want to be root. Warner