From owner-freebsd-current@FreeBSD.ORG Sun Sep 11 00:17:01 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B979E16A41F for ; Sun, 11 Sep 2005 00:17:01 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D43843D45 for ; Sun, 11 Sep 2005 00:17:01 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.4/8.13.4) with ESMTP id j8B0H0DB064064; Sat, 10 Sep 2005 17:17:00 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j8B0Gxt9064063; Sat, 10 Sep 2005 17:16:59 -0700 (PDT) (envelope-from obrien) Date: Sat, 10 Sep 2005 17:16:59 -0700 From: "David O'Brien" To: "Philip S. Schulz" Message-ID: <20050911001659.GA62710@dragon.NUXI.org> Mail-Followup-To: freebsd-current@freebsd.org, "Philip S. Schulz" , Emanuel Strobl References: <200509101915.32081@harrymail> <43231B50.7010302@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43231B50.7010302@gmx.de> X-Operating-System: FreeBSD 7.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.9i Cc: Emanuel Strobl , freebsd-current@freebsd.org Subject: Re: cvsup stuff in BETA4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Sep 2005 00:17:01 -0000 On Sat, Sep 10, 2005 at 07:43:44PM +0200, Philip S. Schulz wrote: > on 10.09.2005 19:15 Uhr Emanuel Strobl said the following: > >Hello, > > > >I just installed BETA4 on my laptop and saw that the stable-supfile still > >has RELENG_5 as default tag. Shouldn't this be changed to RELENG_6? > >Another question: Why are these example files in the base system while > >cvsup itself isn't? I think they should be located > >in /usr/local/share/examples, or /usr/local/etc together with the port... > > Because you would still need to build ezm3 to build cvsup. And, AFAIK, > there are platforms where cvsup is not fully supported, amd64 comes to > mind... No. It is that way purely by tradition. We feel that it is easiest to keep the cvsup example files in the base system so that we can make it easier for the user to have the right RELENG_X tag, etc... CVSup isn't in /usr/src because it is written in Modula-3 and we don't want to bring a Modula-3 compiler into the base system. It has nothing to do with architectures. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Sun Sep 11 01:16:04 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2419116A41F for ; Sun, 11 Sep 2005 01:16:04 +0000 (GMT) (envelope-from mischa.peters@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 961A543D49 for ; Sun, 11 Sep 2005 01:16:03 +0000 (GMT) (envelope-from mischa.peters@gmail.com) Received: by xproxy.gmail.com with SMTP id i31so2133759wxd for ; Sat, 10 Sep 2005 18:16:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=K1U1/ih01JHte0ZZozWfBk41zNlpmAv9/yrdCsBcWINkt255hqORfwco/Ucm2xWOmrXCIjp8bVGwH/pHbGM1O0o2NUGM5ASTQouGD3+vSwxRbHoGyFv36Y7ZWgU4bJ1Mc7Z3RQxloxNMvVNa3vNOJZIFrLaKWEVG20pO7hyzSEs= Received: by 10.70.102.16 with SMTP id z16mr61150wxb; Sat, 10 Sep 2005 18:16:01 -0700 (PDT) Received: by 10.70.76.10 with HTTP; Sat, 10 Sep 2005 18:16:01 -0700 (PDT) Message-ID: <25e9cd01050910181638582ce@mail.gmail.com> Date: Sun, 11 Sep 2005 03:16:01 +0200 From: Mischa Peters To: freebsd-current@freebsd.org, Dimitry Andric In-Reply-To: <25e9cd0105091015332c4b80b1@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <25e9cd0105082823337369bb6d@mail.gmail.com> <4312C7BC.1010603@home.pl> <25e9cd0105083006006713c8ca@mail.gmail.com> <25e9cd01050910132847bdf260@mail.gmail.com> <1925484655.20050911000627@andric.com> <25e9cd0105091015332c4b80b1@mail.gmail.com> Cc: Subject: Re: LSI Logic fibre channel adapter in FreeBSD 6.0-BETA3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mischa.peters@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Sep 2005 01:16:04 -0000 Hi Dim! I have used your patch on mpt_pci.c and it works! :) Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.0-BETA4 #3: Sun Sep 11 03:04:09 CEST 2005 WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Celeron(TM) CPU 1300MHz (1302.97-MHz 686-class= CPU) Origin =3D "GenuineIntel" Id =3D 0x6b4 Stepping =3D 4 Features=3D0x383fbff real memory =3D 1073676288 (1023 MB) avail memory =3D 1041797120 (993 MB) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) pci_link0: irq 5 on acpi0 pci_link1: irq 10 on acpi0 pci_link2: irq 11 on acpi0 pci_link3: irq 12 on acpi0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff,0x4000-0x407f,0x4080-0x40ff,0x5000-0x500f on acpi0 pci0: on pcib0 agp0: mem 0xf0000000-0xf3ffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) twe0: <3ware Storage Controller. Driver version 1.50.01.002> port 0xb000-0xb00f mem 0xf8000000-0xf87fffff irq 10 at device 7.0 on pci0 twe0: [GIANT-LOCKED] twe0: 4 ports, Firmware FE7X 1.05.00.063, BIOS BE7X 1.08.00.048 mpt0: port 0xb400-0xb4ff mem 0xf8940000-0xf894ffff,0xf8950000-0xf895ffff irq 10 at device 11.0 on pci0 mpt0: [GIANT-LOCKED] mpt0: MPI Version=3D1.2.9.0 mpt0: Unhandled Event Notify Frame. Event 0xa. mpt0: mpt_read_cfg_header: Config Info Status 20 mpt1: port 0xb800-0xb8ff mem 0xf8920000-0xf892ffff,0xf8930000-0xf893ffff irq 11 at device 11.1 on pci0 mpt1: [GIANT-LOCKED] mpt1: MPI Version=3D1.2.9.0 mpt1: Unhandled Event Notify Frame. Event 0xa. mpt1: mpt_read_cfg_header: Config Info Status 20 atapci0: port 0xbc00-0xbc07,0xc000-0xc003,0xc400-0xc407,0xc800-0xc803,0xcc00-0xcc3f mem 0xf8900000-0xf891ffff irq 11 at device 12.0 on pci0 ata2: on atapci0 ata3: on atapci0 fxp0: port 0xd000-0xd03f mem 0xf8960000-0xf8960fff,0xf8800000-0xf88fffff irq 12 at device 13.0 on pci0 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:30:48:41:ba:1d isab0: at device 17.0 on pci0 isa0: on isab0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xd400-0xd40f at device 17.1 on pci0 ata0: on atapci1 ata1: on atapci1 uhci0: port 0xd800-0xd81f irq 12 at device 17.2 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xdc00-0xdc1f irq 12 at device 17.3 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xe000-0xe01f irq 12 at device 17.4 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered acpi_tz0: on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acp= i0 sio0: type 16550A, console sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0: port 0x378-0x37f,0x778-0x77b irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff,0xcc000-0xccfff,0xcd000-0xd0fff,0xd1000-0xd8fff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 1302965595 Hz quality 800 Timecounters tick every 1.000 msec ad1: 19595MB at ata0-slave UDMA100 twed0: on twe0 da0 at mpt0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device=20 da0: 100.000MB/s transfers, Tagged Queueing Enabled da1 at mpt0 bus 0 target 0 lun 1 da1: Fixed Direct Access SCSI-2 device=20 da1: 100.000MB/s transfers, Tagged Queueing Enabled da2 at mpt0 bus 0 target 0 lun 2 da2: Fixed Direct Access SCSI-2 device=20 da2: 100.000MB/s transfers, Tagged Queueing Enabled Trying to mount root from ufs:/dev/ad1s1a Thanx!! Mischa From owner-freebsd-current@FreeBSD.ORG Sun Sep 11 01:19:08 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 341F516A41F for ; Sun, 11 Sep 2005 01:19:08 +0000 (GMT) (envelope-from joao.barros@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id E46D543D48 for ; Sun, 11 Sep 2005 01:19:06 +0000 (GMT) (envelope-from joao.barros@gmail.com) Received: by wproxy.gmail.com with SMTP id i21so1408906wra for ; Sat, 10 Sep 2005 18:19:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=h3R4cFtnQzK0n6KfqPiziQyeAt7HLwjRVIZu/HQKs66zrNwAnXejrzkZ+j0NQ8R1Ox08CF1MR4fzAEAm+S2jFatpLrOb8TxqVm2xo1ljj1P2C2PIaB/oej2KIxTKfZi6zTLtQMaIYJ6f36D+GcxtA/ibuu07+sivypyLJ7JydqU= Received: by 10.54.51.33 with SMTP id y33mr1518884wry; Sat, 10 Sep 2005 18:19:05 -0700 (PDT) Received: by 10.54.38.21 with HTTP; Sat, 10 Sep 2005 18:19:05 -0700 (PDT) Message-ID: <70e8236f05091018192d76725a@mail.gmail.com> Date: Sun, 11 Sep 2005 02:19:05 +0100 From: Joao Barros To: Scott Long In-Reply-To: <43236E04.4020208@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <70e8236f05070208212e36c375@mail.gmail.com> <200507291318.24428.jhb@FreeBSD.org> <70e8236f050807192628b0405e@mail.gmail.com> <200508081311.51857.jhb@FreeBSD.org> <70e8236f05090321007f621845@mail.gmail.com> <70e8236f05090513381584dda0@mail.gmail.com> <70e8236f0509051350e020f76@mail.gmail.com> <70e8236f05091016251510408c@mail.gmail.com> <43236E04.4020208@samsco.org> Cc: freebsd-current@freebsd.org, Warner Losh , Mike Tancsa Subject: Re: 6.0-CURRENT SNAP004 hangs on amr (patch) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: joao.barros@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Sep 2005 01:19:08 -0000 On 9/11/05, Scott Long wrote: > Thanks for the invesitgative work. I strenously objected to this change > when it went in, and this kind of problem is precisely the reason why. > Turning off device power on the PCI bus willy-nilly is such an > incredibly bad idea, even if the hope with it is to get a few extra > minutes of battery life on a laptop. >=20 > I worked around this problem with the AAC devices, but I don't know if > the AMR devices can be worked around the same way. I've asked Warner in > private to back out the change. If he refuses, then I'm afraid that > you'll need to remember an undocumented workaround, or find another OS. >=20 > Scott It took me more than a week and almost 20 kernel (and some buildworlds) compilations to get the problem identified and be able to use a workaround. It will take me much more than that to make me walk from FreeBSD :) I can't stress enough my respect for this project and the people who make it what it is: Thank you! -- Joao Barros From owner-freebsd-current@FreeBSD.ORG Sun Sep 11 03:10:54 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7588016A41F; Sun, 11 Sep 2005 03:10:54 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 18F5543D45; Sun, 11 Sep 2005 03:10:54 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j8B39GN1063823; Sat, 10 Sep 2005 21:09:16 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 10 Sep 2005 21:08:59 -0600 (MDT) Message-Id: <20050910.210859.133432771.imp@bsdimp.com> To: joao.barros@gmail.com From: "M. Warner Losh" In-Reply-To: <70e8236f05091016251510408c@mail.gmail.com> References: <70e8236f05090513381584dda0@mail.gmail.com> <70e8236f0509051350e020f76@mail.gmail.com> <70e8236f05091016251510408c@mail.gmail.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 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sat, 10 Sep 2005 21:09:17 -0600 (MDT) Cc: freebsd-current@freebsd.org, mike@sentex.net Subject: Re: 6.0-CURRENT SNAP004 hangs on amr (patch) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Sep 2005 03:10:54 -0000 In message: <70e8236f05091016251510408c@mail.gmail.com> Joao Barros writes: : I believe a workaround for this issue would be verifying before : disabling the device, that no more that one device shares that : particular pci slot. : : Comments? No. That's not a fair workaround. There's too many other cases that this would break. Amrs are farily rare, and having a workaround that negatively affects other hardware is undesirable. The problem is that the AMR device attaches to only one of the PCI devices, when it should attach a dummy driver to the second one. This is due to flaws in the amr hardware design, which we've also seen in the aac cards. Warner From owner-freebsd-current@FreeBSD.ORG Sun Sep 11 03:13:37 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E60D516A41F for ; Sun, 11 Sep 2005 03:13:37 +0000 (GMT) (envelope-from dimitry@andric.com) Received: from tensor.xs4all.nl (tensor.xs4all.nl [194.109.160.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71D9343D46 for ; Sun, 11 Sep 2005 03:13:37 +0000 (GMT) (envelope-from dimitry@andric.com) Received: from kilgore.dim (kilgore.dim [192.168.0.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.xs4all.nl (Postfix) with ESMTP id DFD2BB840; Sun, 11 Sep 2005 05:13:35 +0200 (CEST) Date: Sun, 11 Sep 2005 05:13:10 +0200 From: Dimitry Andric X-Mailer: The Bat! (v3.61.03 beta) Professional X-Priority: 3 (Normal) Message-ID: <18910663357.20050911051310@andric.com> To: Mischa Peters In-Reply-To: <25e9cd01050910181638582ce@mail.gmail.com> References: <25e9cd0105082823337369bb6d@mail.gmail.com> <4312C7BC.1010603@home.pl> <25e9cd0105083006006713c8ca@mail.gmail.com> <25e9cd01050910132847bdf260@mail.gmail.com> <1925484655.20050911000627@andric.com> <25e9cd0105091015332c4b80b1@mail.gmail.com> <25e9cd01050910181638582ce@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="----------11B19ACB1E1A941" Cc: freebsd-current@freebsd.org Subject: Re: LSI Logic fibre channel adapter in FreeBSD 6.0-BETA3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dimitry Andric List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Sep 2005 03:13:38 -0000 ------------11B19ACB1E1A941 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On 2005-09-11 at 03:16:01 Mischa Peters wrote: > I have used your patch on mpt_pci.c and it works! :) Nice! Did you also actually test your SCSI devices to see if nothing exploded? :) > mpt0: port 0xb400-0xb4ff mem > 0xf8940000-0xf894ffff,0xf8950000-0xf895ffff irq 10 at device 11.0 on > pci0 > mpt0: [GIANT-LOCKED] > mpt0: MPI Version=1.2.9.0 > mpt0: Unhandled Event Notify Frame. Event 0xa. Did you see this 'unhandled event' stuff before on 4.11? Anyway, if everything seems to be correct, can someone please commit this patch? It seems trivial enough, and then at least the manpage and hardware compatibility list are in sync with reality for 6.0... ------------11B19ACB1E1A941 Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.1 (MingW32) iD8DBQFDI6DGsF6jCi4glqMRAu69AJ9frVN0oVmgLdobEhpRPUbdax/1YgCfc2By XGSND/JWrrXtFRwdVsR3pzs= =TCe9 -----END PGP MESSAGE----- ------------11B19ACB1E1A941-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 11 03:17:18 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD25816A41F; Sun, 11 Sep 2005 03:17:18 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B56A43D45; Sun, 11 Sep 2005 03:17:18 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j8B3EIcp063877; Sat, 10 Sep 2005 21:14:18 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 10 Sep 2005 21:14:00 -0600 (MDT) Message-Id: <20050910.211400.45157820.imp@bsdimp.com> To: scottl@samsco.org From: "M. Warner Losh" In-Reply-To: <43236E04.4020208@samsco.org> References: <70e8236f0509051350e020f76@mail.gmail.com> <70e8236f05091016251510408c@mail.gmail.com> <43236E04.4020208@samsco.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sat, 10 Sep 2005 21:14:18 -0600 (MDT) Cc: joao.barros@gmail.com, freebsd-current@freebsd.org, mike@sentex.net Subject: Re: 6.0-CURRENT SNAP004 hangs on amr (patch) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Sep 2005 03:17:19 -0000 In message: <43236E04.4020208@samsco.org> Scott Long writes: : Thanks for the invesitgative work. I strenously objected to this change : when it went in, and this kind of problem is precisely the reason why. : Turning off device power on the PCI bus willy-nilly is such an : incredibly bad idea, even if the hope with it is to get a few extra : minutes of battery life on a laptop. It is *NOT* an incredibly bad idea. It is suggested by the standards, and is done by other OSes, including Windows. I know you don't like it, but it is very beneficial in many circumstances. It helps with heat issues as well as power consumption. : I worked around this problem with the AAC devices, but I don't know if : the AMR devices can be worked around the same way. I've asked Warner in : private to back out the change. If he refuses, then I'm afraid that : you'll need to remember an undocumented workaround, or find another OS. I've said before that the right fix is to fix the device drivers that have knowledge of these split devices. I still stand by that assessment. So far only two drivers have been affected (amr and aac). I'm disinclined to change it because of those two devices. However, I'll start thinking about this in detail and reconsider it after some thought. There may be a better workaround. Warner From owner-freebsd-current@FreeBSD.ORG Sun Sep 11 03:31:54 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC29F16A41F; Sun, 11 Sep 2005 03:31:54 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D45943D45; Sun, 11 Sep 2005 03:31:54 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j8B3Ttcs064012; Sat, 10 Sep 2005 21:29:56 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 10 Sep 2005 21:29:38 -0600 (MDT) Message-Id: <20050910.212938.106824122.imp@bsdimp.com> To: joao.barros@gmail.com From: "M. Warner Losh" In-Reply-To: <70e8236f05091016251510408c@mail.gmail.com> References: <70e8236f05090513381584dda0@mail.gmail.com> <70e8236f0509051350e020f76@mail.gmail.com> <70e8236f05091016251510408c@mail.gmail.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 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sat, 10 Sep 2005 21:29:56 -0600 (MDT) Cc: freebsd-current@freebsd.org, mike@sentex.net Subject: Re: 6.0-CURRENT SNAP004 hangs on amr (patch) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Sep 2005 03:31:55 -0000 In message: <70e8236f05091016251510408c@mail.gmail.com> Joao Barros writes: : Looking at pciconf -l -v : : pcib3@pci2:0:0: class=0x060400 card=0x000000dc chip=0xb1548086 rev=0x00 hdr=0x01 : vendor = 'Intel Corporation' : device = 'S21152BA,S21154AE/BE PCI to PCI Bridge' : class = bridge : subclass = PCI-PCI : none1@pci2:1:0: class=0x010000 card=0x8493101e chip=0x12161077 rev=0x06 hdr=0x00 : vendor = 'QLogic Corporation' : device = 'ISP12160 Dual Channel Ultra3 SCSI Processor' : class = mass storage : subclass = SCSI : amr0@pci3:0:0: class=0x010400 card=0x04931028 chip=0x1960101e rev=0x20 hdr=0x00 : vendor = 'American Megatrends Inc.' : device = '80960RP i960RP Microprocessor' : class = mass storage : subclass = RAID : : So, by not attaching a driver to pci2:1:0, the pci2:0:0 is disabled. : Although the 'real' amr is assigned to pci3, the pci bridge on : pci2:0:0 gets disabled thus killing the amr. One workaround less intrusive workaround would also be to add mass storage devices to the list of devices that we don't power down by default. That would catch all the cases that have been found to have issues, as far as I can recall. Since these aren't functions in the same slot, it can be very hard to know and recoginze this situation automatically. How do you tell it apart from two devices on the same bus? You can't easily tell this. I have a few ideas here, and will look into them. Warner From owner-freebsd-current@FreeBSD.ORG Sun Sep 11 04:36:27 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B074316A422 for ; Sun, 11 Sep 2005 04:36:27 +0000 (GMT) (envelope-from boris@brooknet.com.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FE1643D45 for ; Sun, 11 Sep 2005 04:36:25 +0000 (GMT) (envelope-from boris@brooknet.com.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86]) by mailout2.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j8B4aO2r018661; Sun, 11 Sep 2005 14:36:24 +1000 Received: from ppp2430.dyn.pacific.net.au (ppp2430.dyn.pacific.net.au [61.8.36.48]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j8B4aHYo013428; Sun, 11 Sep 2005 14:36:22 +1000 From: Sam Lawrance To: Brooks Davis In-Reply-To: <20050910175512.GA9155@odin.ac.hmc.edu> References: <1126360250.828.38.camel@dirk.no.domain> <20050910175512.GA9155@odin.ac.hmc.edu> Content-Type: text/plain Date: Sun, 11 Sep 2005 14:36:42 +1000 Message-Id: <1126413402.56706.4.camel@dirk.no.domain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: wpa_supplicant AP scanning doesn't work after first association X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Sep 2005 04:36:28 -0000 On Sat, 2005-09-10 at 10:55 -0700, Brooks Davis wrote: > On Sat, Sep 10, 2005 at 11:50:50PM +1000, Sam Lawrance wrote: > > Hi, > > > > The station boots up and associates with the AP OK. This works great > > for days. If I power down the AP and power it up again, after > > disassociating, wpa_supplicant fails to locate the access point in its > > scans. > > > > I am using RELENG_6 from 3 September. > > > > The station is a D-Link DWL-G510 (atheros based) > > ath0@pci0:8:0: class=0x020000 card=0x3a161186 chip=0x001a168c rev=0x01 hdr=0x00. > > > > rc.conf entry: > > ifconfig_ath0="WPA inet 192.168.0.1 netmask 255.255.255.0" > > > > wpa_supplicant.conf contains: > > ctrl_interface=/var/run/wpa_supplicant > > ctrl_interface_group=wheel > > network={ > > ssid="sunset" > > scan_ssid=1 > > key_mgmt=WPA-PSK > > psk= ... etc etc ... > > } > > > > The access point is a D-Link DI-524 firmware v2.02, configured for > > WPA-PSK > > > > Output from wpa_supplicant: > > > > Starting AP scan (specific SSID) > > Scan SSID - hexdump_ascii(len=6): > > 73 75 6e 73 65 74 sunset > > Received 0 bytes of scan results (1 BSSes) > > Scan results: 1 > > Selecting BSS from priority group 0 > > 0: 00:0f:3d:29:79:f5 ssid='sunset' wpa_ie_len=24 rsn_ie_len=0 > > selected > > Trying to associate with 00:0f:3d:29:79:f5 (SSID='sunset' freq=2437 MHz) > > Cancelling scan request > > Automatic auth_alg selection: 0x1 > > WPA: using IEEE 802.11i/D3.0 > > WPA: Selected cipher suites: group 8 pairwise 8 key_mgmt 2 > > WPA: using GTK TKIP > > WPA: using PTK TKIP > > WPA: using KEY_MGMT WPA-PSK WPA: Own WPA IE - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 02 01 00 00 50 f2 02 > > No keys have been configured - skip key clearing > > wpa_driver_bsd_set_drop_unencrypted: enabled=1 > > wpa_driver_bsd_associate: ssid 'sunset' wpa ie len 24 pairwise 2 group 2 key mgmt 1 > > wpa_driver_bsd_associate: set PRIVACY 1 > > Setting authentication timeout: 5 sec 0 usec > > Association event - clear replay counter > > Associated to a new BSS: BSSID=00:0f:3d:29:79:f5 > > No keys have been configured - skip key clearing > > Associated with 00:0f:3d:29:79:f5 > > Setting authentication timeout: 10 sec 0 usec > > RX EAPOL from 00:0f:3d:29:79:f5 > > > > ... power down AP, wait a minute, power up AP ... > > > > Starting AP scan (broadcast SSID) > > Received 0 bytes of scan results (0 BSSes) > > Scan results: 0 > > Selecting BSS from priority group 0 > > No suitable AP found. > > Setting scan request: 5 sec 0 usec > > Starting AP scan (specific SSID) > > Scan SSID - hexdump_ascii(len=6): > > 73 75 6e 73 65 74 sunset > > Received 0 bytes of scan results (0 BSSes) > > Scan results: 0 > > Selecting BSS from priority group 0 > > No suitable AP found. > > > > > > Please let me know what other information I can collect to help figure > > this out. I hope it's not pilot error :) > > Running current as of August 23rd an connecting using WPA-PSK to connect > to a DI-524 running firmware 1.11, I reconnect promptly when I power the > AP back on. This DI-524 is a revision B. Anyhow, I'm going to turn on some ath debugging output and see if it lends any clues. From owner-freebsd-current@FreeBSD.ORG Sun Sep 11 04:53:39 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6366616A41F; Sun, 11 Sep 2005 04:53:39 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0563543D46; Sun, 11 Sep 2005 04:53:38 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j8B4rbp3077599; Sun, 11 Sep 2005 00:53:38 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.3/8.13.3) with ESMTP id j8B4rbKI074502; Sun, 11 Sep 2005 00:53:37 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 5402D7302F; Sun, 11 Sep 2005 00:53:36 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050911045336.5402D7302F@freebsd-current.sentex.ca> Date: Sun, 11 Sep 2005 00:53:36 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.86, clamav-milter version 0.86 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on alpha/alpha X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Sep 2005 04:53:39 -0000 TB --- 2005-09-11 03:16:39 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-09-11 03:16:39 - starting HEAD tinderbox run for alpha/alpha TB --- 2005-09-11 03:16:39 - cleaning the object tree TB --- 2005-09-11 03:17:01 - checking out the source tree TB --- 2005-09-11 03:17:01 - cd /tinderbox/HEAD/alpha/alpha TB --- 2005-09-11 03:17:01 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-09-11 03:22:45 - building world (CFLAGS=-O2 -pipe) TB --- 2005-09-11 03:22:45 - cd /src TB --- 2005-09-11 03:22:45 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2005-09-11 04:33:30 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-09-11 04:33:30 - cd /src TB --- 2005-09-11 04:33:30 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Sep 11 04:33:30 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Sun Sep 11 04:51:48 UTC 2005 TB --- 2005-09-11 04:51:48 - generating LINT kernel config TB --- 2005-09-11 04:51:48 - cd /src/sys/alpha/conf TB --- 2005-09-11 04:51:48 - /usr/bin/make -B LINT TB --- 2005-09-11 04:51:48 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-09-11 04:51:48 - cd /src TB --- 2005-09-11 04:51:48 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Sep 11 04:51:49 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] /src/sys/netgraph/atm/uni/ng_uni.c:52:35: netnatm/msg/unistruct.h: No such file or directory /src/sys/netgraph/atm/uni/ng_uni.c:54:35: netnatm/saal/sscopdef.h: No such file or directory /src/sys/netgraph/atm/uni/ng_uni.c:55:35: netnatm/saal/sscfudef.h: No such file or directory /src/sys/netgraph/atm/uni/ng_uni.c:57:29: netnatm/sig/uni.h: No such file or directory /src/sys/netgraph/atm/uni/ng_uni.c:58:32: netnatm/sig/unisig.h: No such file or directory /src/sys/netinet/in_proto.c:92:23: net/pfvar.h: No such file or directory /src/sys/netinet/in_proto.c:93:27: net/if_pfsync.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /obj/alpha/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-09-11 04:53:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-09-11 04:53:36 - ERROR: failed to build lint kernel TB --- 2005-09-11 04:53:36 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sun Sep 11 05:10:02 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C370916A41F; Sun, 11 Sep 2005 05:10:02 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4EC9743D46; Sun, 11 Sep 2005 05:09:55 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j8B59qGJ053976; Sat, 10 Sep 2005 23:09:53 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4323BC24.9020902@samsco.org> Date: Sat, 10 Sep 2005 23:09:56 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M. Warner Losh" References: <70e8236f05090513381584dda0@mail.gmail.com> <70e8236f0509051350e020f76@mail.gmail.com> <70e8236f05091016251510408c@mail.gmail.com> <20050910.210859.133432771.imp@bsdimp.com> In-Reply-To: <20050910.210859.133432771.imp@bsdimp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: joao.barros@gmail.com, freebsd-current@freebsd.org, mike@sentex.net Subject: Re: 6.0-CURRENT SNAP004 hangs on amr (patch) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Sep 2005 05:10:02 -0000 M. Warner Losh wrote: > In message: <70e8236f05091016251510408c@mail.gmail.com> > Joao Barros writes: > : I believe a workaround for this issue would be verifying before > : disabling the device, that no more that one device shares that > : particular pci slot. > : > : Comments? > > No. That's not a fair workaround. There's too many other cases that > this would break. Amrs are farily rare, and having a workaround that > negatively affects other hardware is undesirable. > > The problem is that the AMR device attaches to only one of the PCI > devices, when it should attach a dummy driver to the second one. This > is due to flaws in the amr hardware design, which we've also seen in > the aac cards. > > Warner I don't really care if you think that it's a flaw. What it comes down to is that it's a problem with FreeBSD. Scott From owner-freebsd-current@FreeBSD.ORG Sun Sep 11 05:12:00 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3EEB716A41F; Sun, 11 Sep 2005 05:12:00 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id A5CB443D45; Sun, 11 Sep 2005 05:11:59 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j8B5BvEZ054014; Sat, 10 Sep 2005 23:11:57 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4323BCA1.7000708@samsco.org> Date: Sat, 10 Sep 2005 23:12:01 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M. Warner Losh" References: <70e8236f05090513381584dda0@mail.gmail.com> <70e8236f0509051350e020f76@mail.gmail.com> <70e8236f05091016251510408c@mail.gmail.com> <20050910.212938.106824122.imp@bsdimp.com> In-Reply-To: <20050910.212938.106824122.imp@bsdimp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: joao.barros@gmail.com, freebsd-current@freebsd.org, mike@sentex.net Subject: Re: 6.0-CURRENT SNAP004 hangs on amr (patch) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Sep 2005 05:12:00 -0000 M. Warner Losh wrote: > In message: <70e8236f05091016251510408c@mail.gmail.com> > Joao Barros writes: > : Looking at pciconf -l -v : > : pcib3@pci2:0:0: class=0x060400 card=0x000000dc chip=0xb1548086 rev=0x00 hdr=0x01 > : vendor = 'Intel Corporation' > : device = 'S21152BA,S21154AE/BE PCI to PCI Bridge' > : class = bridge > : subclass = PCI-PCI > : none1@pci2:1:0: class=0x010000 card=0x8493101e chip=0x12161077 rev=0x06 hdr=0x00 > : vendor = 'QLogic Corporation' > : device = 'ISP12160 Dual Channel Ultra3 SCSI Processor' > : class = mass storage > : subclass = SCSI > : amr0@pci3:0:0: class=0x010400 card=0x04931028 chip=0x1960101e rev=0x20 hdr=0x00 > : vendor = 'American Megatrends Inc.' > : device = '80960RP i960RP Microprocessor' > : class = mass storage > : subclass = RAID > : > : So, by not attaching a driver to pci2:1:0, the pci2:0:0 is disabled. > : Although the 'real' amr is assigned to pci3, the pci bridge on > : pci2:0:0 gets disabled thus killing the amr. > > One workaround less intrusive workaround would also be to add mass > storage devices to the list of devices that we don't power down by > default. That would catch all the cases that have been found to have > issues, as far as I can recall. > > Since these aren't functions in the same slot, it can be very hard to > know and recoginze this situation automatically. How do you tell it > apart from two devices on the same bus? You can't easily tell this. > > I have a few ideas here, and will look into them. > > Warner This will likely affect any intelligent I/O controller that is designed in this manner. This would include certain network controllers. Scott From owner-freebsd-current@FreeBSD.ORG Sun Sep 11 05:21:39 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A36F016A41F; Sun, 11 Sep 2005 05:21:39 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id F22C643D46; Sun, 11 Sep 2005 05:21:38 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j8B5LbqS054052; Sat, 10 Sep 2005 23:21:37 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4323BEE5.1090001@samsco.org> Date: Sat, 10 Sep 2005 23:21:41 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: joao.barros@gmail.com References: <70e8236f05070208212e36c375@mail.gmail.com> <200507291318.24428.jhb@FreeBSD.org> <70e8236f050807192628b0405e@mail.gmail.com> <200508081311.51857.jhb@FreeBSD.org> <70e8236f05090321007f621845@mail.gmail.com> <70e8236f05090513381584dda0@mail.gmail.com> <70e8236f0509051350e020f76@mail.gmail.com> <70e8236f05091016251510408c@mail.gmail.com> <43236E04.4020208@samsco.org> <70e8236f05091018192d76725a@mail.gmail.com> In-Reply-To: <70e8236f05091018192d76725a@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: freebsd-current@freebsd.org, Warner Losh , Mike Tancsa Subject: Re: 6.0-CURRENT SNAP004 hangs on amr (patch) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Sep 2005 05:21:39 -0000 Joao Barros wrote: > On 9/11/05, Scott Long wrote: > > >>Thanks for the invesitgative work. I strenously objected to this change >>when it went in, and this kind of problem is precisely the reason why. >>Turning off device power on the PCI bus willy-nilly is such an >>incredibly bad idea, even if the hope with it is to get a few extra >>minutes of battery life on a laptop. >> >>I worked around this problem with the AAC devices, but I don't know if >>the AMR devices can be worked around the same way. I've asked Warner in >>private to back out the change. If he refuses, then I'm afraid that >>you'll need to remember an undocumented workaround, or find another OS. >> >>Scott > > > It took me more than a week and almost 20 kernel (and some > buildworlds) compilations to get the problem identified and be able to > use a workaround. It will take me much more than that to make me walk > from FreeBSD :) > I can't stress enough my respect for this project and the people who > make it what it is: Thank you! > > -- > Joao Barros I appreciate your determination. I'm just pissed that I've been warning Warner for 9 months that there were hidden landmines with his position on the PCI power-down code, and I've been completely brushed off by him. Most other users don't have your determination. Thank you, though, for your work here. Scott From owner-freebsd-current@FreeBSD.ORG Sun Sep 11 05:38:30 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 96E3616A41F; Sun, 11 Sep 2005 05:38:30 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id E356A43D46; Sun, 11 Sep 2005 05:38:29 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j8B5cQhP054120; Sat, 10 Sep 2005 23:38:26 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4323C2D6.9030807@samsco.org> Date: Sat, 10 Sep 2005 23:38:30 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M. Warner Losh" References: <70e8236f0509051350e020f76@mail.gmail.com> <70e8236f05091016251510408c@mail.gmail.com> <43236E04.4020208@samsco.org> <20050910.211400.45157820.imp@bsdimp.com> In-Reply-To: <20050910.211400.45157820.imp@bsdimp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: joao.barros@gmail.com, freebsd-current@freebsd.org, mike@sentex.net Subject: Re: 6.0-CURRENT SNAP004 hangs on amr (patch) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Sep 2005 05:38:30 -0000 M. Warner Losh wrote: > In message: <43236E04.4020208@samsco.org> > Scott Long writes: > : Thanks for the invesitgative work. I strenously objected to this change > : when it went in, and this kind of problem is precisely the reason why. > : Turning off device power on the PCI bus willy-nilly is such an > : incredibly bad idea, even if the hope with it is to get a few extra > : minutes of battery life on a laptop. > > It is *NOT* an incredibly bad idea. It is suggested by the standards, > and is done by other OSes, including Windows. I know you don't like > it, but it is very beneficial in many circumstances. It helps with > heat issues as well as power consumption. > One more question. Where exactly have you measured the effects here? Can you quantify how much the heat and/or power savings are on a particular computer with this strategy in use? > : I worked around this problem with the AAC devices, but I don't know if > : the AMR devices can be worked around the same way. I've asked Warner in > : private to back out the change. If he refuses, then I'm afraid that > : you'll need to remember an undocumented workaround, or find another OS. > > I've said before that the right fix is to fix the device drivers that > have knowledge of these split devices. I still stand by that > assessment. > > So far only two drivers have been affected (amr and aac). I'm > disinclined to change it because of those two devices. And I'm tired of cleaning up after your mess simply because I happen to care about making a working OS. > > However, I'll start thinking about this in detail and reconsider it > after some thought. There may be a better workaround. > > Warner From owner-freebsd-current@FreeBSD.ORG Sun Sep 11 05:49:55 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A481316A41F; Sun, 11 Sep 2005 05:49:55 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48E1843D45; Sun, 11 Sep 2005 05:49:55 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j8B5lSAg065405; Sat, 10 Sep 2005 23:47:28 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 10 Sep 2005 23:47:10 -0600 (MDT) Message-Id: <20050910.234710.17343489.imp@bsdimp.com> To: scottl@samsco.org From: "M. Warner Losh" In-Reply-To: <4323C2D6.9030807@samsco.org> References: <43236E04.4020208@samsco.org> <20050910.211400.45157820.imp@bsdimp.com> <4323C2D6.9030807@samsco.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sat, 10 Sep 2005 23:47:28 -0600 (MDT) Cc: joao.barros@gmail.com, freebsd-current@freebsd.org, mike@sentex.net Subject: Re: 6.0-CURRENT SNAP004 hangs on amr (patch) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Sep 2005 05:49:55 -0000 In message: <4323C2D6.9030807@samsco.org> Scott Long writes: : And I'm tired of cleaning up after your mess simply because I happen : to care about making a working OS. Scott, Please stop overstating the effects. There have been two drivers that have been affected: aac and amr. While these are important, and should work, please do not engage in hyperbole. I'll reply more when yop stop attacking me. Thanks. Warner From owner-freebsd-current@FreeBSD.ORG Sun Sep 11 05:54:47 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BED1C16A41F; Sun, 11 Sep 2005 05:54:47 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FD0643D45; Sun, 11 Sep 2005 05:54:47 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j8B5sii0054178; Sat, 10 Sep 2005 23:54:44 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4323C6A4.6030007@samsco.org> Date: Sat, 10 Sep 2005 23:54:44 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M. Warner Losh" References: <43236E04.4020208@samsco.org> <20050910.211400.45157820.imp@bsdimp.com> <4323C2D6.9030807@samsco.org> <20050910.234710.17343489.imp@bsdimp.com> In-Reply-To: <20050910.234710.17343489.imp@bsdimp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: joao.barros@gmail.com, freebsd-current@freebsd.org, mike@sentex.net Subject: Re: 6.0-CURRENT SNAP004 hangs on amr (patch) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Sep 2005 05:54:47 -0000 M. Warner Losh wrote: > In message: <4323C2D6.9030807@samsco.org> > Scott Long writes: > : And I'm tired of cleaning up after your mess simply because I happen > : to care about making a working OS. > > Scott, > > Please stop overstating the effects. There have been two drivers that > have been affected: aac and amr. While these are important, and > should work, please do not engage in hyperbole. > > I'll reply more when yop stop attacking me. Thanks. > > Warner Ok PHK. Your opinion wins. Scott From owner-freebsd-current@FreeBSD.ORG Sun Sep 11 06:52:20 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8567616A430; Sun, 11 Sep 2005 06:52:18 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 166C943D46; Sun, 11 Sep 2005 06:52:17 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j8B6qGZm082400; Sun, 11 Sep 2005 02:52:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.3/8.13.3) with ESMTP id j8B6qGL2092990; Sun, 11 Sep 2005 02:52:16 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 7A9EA7302F; Sun, 11 Sep 2005 02:52:16 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050911065216.7A9EA7302F@freebsd-current.sentex.ca> Date: Sun, 11 Sep 2005 02:52:16 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.86, clamav-milter version 0.86 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Sep 2005 06:52:20 -0000 TB --- 2005-09-11 04:53:37 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-09-11 04:53:37 - starting HEAD tinderbox run for amd64/amd64 TB --- 2005-09-11 04:53:37 - cleaning the object tree TB --- 2005-09-11 04:54:26 - checking out the source tree TB --- 2005-09-11 04:54:26 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2005-09-11 04:54:26 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-09-11 05:04:46 - building world (CFLAGS=-O2 -pipe) TB --- 2005-09-11 05:04:46 - cd /src TB --- 2005-09-11 05:04:46 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries TB --- 2005-09-11 06:51:08 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-09-11 06:51:08 - cd /src TB --- 2005-09-11 06:51:08 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Sep 11 06:51:08 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] /src/sys/dev/twa/tw_cl_misc.c:42:26: tw_osl_share.h: No such file or directory /src/sys/dev/twa/tw_cl_misc.c:43:25: tw_cl_share.h: No such file or directory /src/sys/dev/twa/tw_cl_misc.c:44:24: tw_cl_fwif.h: No such file or directory /src/sys/dev/twa/tw_cl_misc.c:45:25: tw_cl_ioctl.h: No such file or directory /src/sys/dev/twa/tw_cl_misc.c:46:19: tw_cl.h: No such file or directory /src/sys/dev/twa/tw_cl_misc.c:47:27: tw_cl_externs.h: No such file or directory /src/sys/dev/twa/tw_cl_misc.c:48:26: tw_osl_ioctl.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /obj/amd64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-09-11 06:52:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-09-11 06:52:16 - ERROR: failed to build generic kernel TB --- 2005-09-11 06:52:16 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sun Sep 11 07:51:59 2005 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F19716A41F for ; Sun, 11 Sep 2005 07:51:59 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fileserver.fields.utoronto.ca (fileserver.fields.utoronto.ca [128.100.216.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE37343D45 for ; Sun, 11 Sep 2005 07:51:58 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fields.fields.utoronto.ca (fields.localdomain [192.168.216.11]) by fileserver.fields.utoronto.ca (8.12.8/8.12.8/Fields 6.0) with ESMTP id j8B7pv0r020054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 11 Sep 2005 03:51:58 -0400 Received: from obsecurity.dyndns.org (localhost.localdomain [127.0.0.1]) by fields.fields.utoronto.ca (8.12.8/8.12.8/Fields WS 6.0) with ESMTP id j8B7pv6P006430 for ; Sun, 11 Sep 2005 03:51:57 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 6F90C51206; Sun, 11 Sep 2005 03:51:57 -0400 (EDT) Date: Sun, 11 Sep 2005 03:51:57 -0400 From: Kris Kennaway To: current@FreeBSD.org Message-ID: <20050911075157.GA93947@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bp/iNruPH9dso1Pn" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: 'swap_pager: indefinite wait buffer' with swapfile X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Sep 2005 07:51:59 -0000 --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I configured a vnode-backed md and enabled swapping on it. A few hours later after moderate swap use the console showed: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 889347, size: 8192 [...repeated...] The backing store was a sparse file, but there was ample space: # ls -l /data2/swapfile -rw-r--r-- 1 root wheel 17179869184 Sep 11 16:50 /data2/swapfile # df /data2 Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/stripe/data 51666218 27042730 20490192 57% /data2 # swapinfo Device 1K-blocks Used Avail Capacity /dev/da0b 6297480 949304 6297480 15% /dev/md41 16777216 842544 16777216 5% Total 23074696 1791848 21282848 8% Kris --bp/iNruPH9dso1Pn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDI+IcWry0BWjoQKURAt/wAJ99xKAXdyJC4CqnheWfDQeTlJqGeACg2dC1 2OayDetQrI6vZ5Q2/BcfFAc= =wLbT -----END PGP SIGNATURE----- --bp/iNruPH9dso1Pn-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 11 08:04:14 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7362616A41F for ; Sun, 11 Sep 2005 08:04:14 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4E9D43D45 for ; Sun, 11 Sep 2005 08:04:13 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.4/8.13.3) with ESMTP id j8B849pv046882 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 11 Sep 2005 10:04:09 +0200 (CEST) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.4/8.13.3/Submit) id j8B849VF046881; Sun, 11 Sep 2005 10:04:09 +0200 (CEST) Date: Sun, 11 Sep 2005 10:04:08 +0200 From: Divacky Roman To: Poul-Henning Kamp Message-ID: <20050911080408.GA46725@stud.fit.vutbr.cz> References: <20050910193211.529a7d01.polachok@narod.ru> <14711.1126370367@phk.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <14711.1126370367@phk.freebsd.dk> User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.49 on 147.229.10.14 Cc: current@freebsd.org Subject: Re: comms/ltmdm and COMPAT_43 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Sep 2005 08:04:14 -0000 On Sat, Sep 10, 2005 at 06:39:27PM +0200, Poul-Henning Kamp wrote: > In message <20050910193211.529a7d01.polachok@narod.ru>, Alexander Polakov write > s: > >I was very disappointed about the fact that comms/ltmdm doesn't > >work without COMPAT_43 in kernel. Can it be fixed? Or should I write > >to ports@freebsd.org? > > Most of our tty stuff depends on COMPAT_43 what of the tty stuff depends on COMPAT_43? I found some ioctls and then nothing.. I for one use kernel without COMPAT_43 for more than a year and havent noticed any problems... from my point of view the only serious (=widely used) consumer of COMPAT_43 is linux emulator (kern/85175 addresses this) maybe the tty stuff could be separated into some COMPAT_43_TTY and let the rest of COMPAT_43 die.. roman From owner-freebsd-current@FreeBSD.ORG Sun Sep 11 08:08:07 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3299D16A41F; Sun, 11 Sep 2005 08:08:07 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1BA943D45; Sun, 11 Sep 2005 08:08:06 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j8B885Q0085450; Sun, 11 Sep 2005 04:08:05 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j8B885SU078982; Sun, 11 Sep 2005 04:08:05 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 2B8667302F; Sun, 11 Sep 2005 04:08:05 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050911080805.2B8667302F@freebsd-current.sentex.ca> Date: Sun, 11 Sep 2005 04:08:05 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner5 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Sep 2005 08:08:07 -0000 TB --- 2005-09-11 06:52:16 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-09-11 06:52:16 - starting HEAD tinderbox run for i386/i386 TB --- 2005-09-11 06:52:16 - cleaning the object tree TB --- 2005-09-11 06:52:41 - checking out the source tree TB --- 2005-09-11 06:52:41 - cd /tinderbox/HEAD/i386/i386 TB --- 2005-09-11 06:52:41 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-09-11 06:58:12 - building world (CFLAGS=-O2 -pipe) TB --- 2005-09-11 06:58:12 - cd /src TB --- 2005-09-11 06:58:12 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2005-09-11 08:07:01 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-09-11 08:07:01 - cd /src TB --- 2005-09-11 08:07:01 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Sep 11 08:07:01 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] /src/sys/dev/twa/tw_cl_misc.c:42:26: tw_osl_share.h: No such file or directory /src/sys/dev/twa/tw_cl_misc.c:43:25: tw_cl_share.h: No such file or directory /src/sys/dev/twa/tw_cl_misc.c:44:24: tw_cl_fwif.h: No such file or directory /src/sys/dev/twa/tw_cl_misc.c:45:25: tw_cl_ioctl.h: No such file or directory /src/sys/dev/twa/tw_cl_misc.c:46:19: tw_cl.h: No such file or directory /src/sys/dev/twa/tw_cl_misc.c:47:27: tw_cl_externs.h: No such file or directory /src/sys/dev/twa/tw_cl_misc.c:48:26: tw_osl_ioctl.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /obj/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-09-11 08:08:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-09-11 08:08:05 - ERROR: failed to build generic kernel TB --- 2005-09-11 08:08:05 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sun Sep 11 08:32:33 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C040E16A41F for ; Sun, 11 Sep 2005 08:32:33 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from pfepa.post.tele.dk (pfepa.post.tele.dk [195.41.46.235]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72F2243D45 for ; Sun, 11 Sep 2005 08:32:33 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (0x50a6a4ba.naenxx7.adsl-dhcp.tele.dk [80.166.164.186]) by pfepa.post.tele.dk (Postfix) with ESMTP id C621647FE48; Sun, 11 Sep 2005 10:32:27 +0200 (CEST) To: Divacky Roman From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 11 Sep 2005 10:04:08 +0200." <20050911080408.GA46725@stud.fit.vutbr.cz> Date: Sun, 11 Sep 2005 10:32:27 +0200 Message-ID: <1348.1126427547@phk.freebsd.dk> Sender: phk@phk.freebsd.dk Cc: current@freebsd.org Subject: Re: comms/ltmdm and COMPAT_43 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Sep 2005 08:32:33 -0000 In message <20050911080408.GA46725@stud.fit.vutbr.cz>, Divacky Roman writes: >> Most of our tty stuff depends on COMPAT_43 > >what of the tty stuff depends on COMPAT_43? I found some ioctls and then >nothing.. It is only the ioctls, but there are several hundred ports which break if we don't support then. On my todo list, the tty parts of COMPAT_43 becomes standard (for that reason) and the rest of COMPAT_43 can then become optional. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Sun Sep 11 10:21:32 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5316B16A420; Sun, 11 Sep 2005 10:21:32 +0000 (GMT) (envelope-from chris@haakonia.hitnet.rwth-aachen.de) Received: from ms-dienst.rz.rwth-aachen.de (ms-2.rz.RWTH-Aachen.DE [134.130.3.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3DC6443D58; Sun, 11 Sep 2005 10:21:17 +0000 (GMT) (envelope-from chris@haakonia.hitnet.rwth-aachen.de) Received: from r220-1 (r220-1.rz.RWTH-Aachen.DE [134.130.3.31]) by ms-dienst.rz.rwth-aachen.de (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IMN005JCE3F50@ms-dienst.rz.rwth-aachen.de>; Sun, 11 Sep 2005 12:21:16 +0200 (MEST) Received: from relay.rwth-aachen.de ([134.130.3.1]) by r220-1 (MailMonitor for SMTP v1.2.2 ) ; Sun, 11 Sep 2005 12:21:15 +0200 (MEST) Received: from bigboss.hitnet.rwth-aachen.de (bigspace.hitnet.RWTH-Aachen.DE [137.226.181.2]) by relay.rwth-aachen.de (8.13.3/8.13.3/1) with ESMTP id j8BALEvG025823; Sun, 11 Sep 2005 12:21:14 +0200 (MEST) Received: from lorien.hitnet.rwth-aachen.de ([137.226.181.92] helo=haakonia.hitnet.rwth-aachen.de) by bigboss.hitnet.rwth-aachen.de with esmtp (Exim 3.35 #1 (Debian)) id 1EEOxW-0001ey-00; Sun, 11 Sep 2005 12:21:14 +0200 Received: by haakonia.hitnet.rwth-aachen.de (Postfix, from userid 1001) id 8AB0928477; Sun, 11 Sep 2005 12:20:44 +0200 (CEST) Date: Sun, 11 Sep 2005 12:20:44 +0200 From: Christian Brueffer In-reply-to: <200509110042.31358@harrymail> To: Emanuel Strobl Message-id: <20050911102044.GA1142@unixpages.org> MIME-version: 1.0 Content-type: multipart/signed; boundary=X1bOJ3K7DJ5YkBrT; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-disposition: inline User-Agent: Mutt/1.5.9i X-Operating-System: FreeBSD 6.0-BETA4 X-PGP-Key: http://people.FreeBSD.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D References: <200509110042.31358@harrymail> Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: acpi_sony - no powerd, no man page! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Sep 2005 10:21:32 -0000 --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 11, 2005 at 12:42:17AM +0200, Emanuel Strobl wrote: > Hello, >=20 > I just installed BETA4 on my notebook and was curious about the acpi_sony= =20 > driver, but all I can see is that powerd soesn't work anymoder (if I call= =20 > powerd -a min dev.cpu.0.freq is still 800 wher it was 62 without acpi_son= y=20 > compiled in) and that I can set LCD brightness :) *bright_smile* > But what does ctr, pcr, wdp and cdp mean? > A short man page was wonderful! > And is it known/intended that cpufreq doesn't work with acpi_sony? >=20 I wrote a small manpage some time ago (more of a dummy kind), but haven't committed it yet because it's not that useful... The meanings of ctr, pcr, wdp and cdp are unknown. takawata@, who wrote the driver, got his information solely from the DSDT of the BIOS. So, he doesn't know the meaning either :-) - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --X1bOJ3K7DJ5YkBrT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFDJAT8bHYXjKDtmC0RAuoDAJ9NH1BYafIs2mIfA2y6hjEaVeRkewCgsB78 ru/lzO5Kl1J8RPVjrReQDU8= =EapX -----END PGP SIGNATURE----- --X1bOJ3K7DJ5YkBrT-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 10 23:03:38 2005 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AEB5416A420 for ; Sat, 10 Sep 2005 23:03:38 +0000 (GMT) (envelope-from mi@blue.virtual-estates.net) Received: from mail28.sea5.speakeasy.net (mail28.sea5.speakeasy.net [69.17.117.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC18D43D4C for ; Sat, 10 Sep 2005 23:03:37 +0000 (GMT) (envelope-from mi@blue.virtual-estates.net) Received: (qmail 977 invoked from network); 10 Sep 2005 23:03:37 -0000 Received: from aldan.algebra.com (HELO blue.virtual-estates.net) ([216.254.65.224]) (envelope-sender ) by mail28.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 10 Sep 2005 23:03:37 -0000 Received: from blue.virtual-estates.net (blue [127.0.0.1]) by blue.virtual-estates.net (8.13.3/8.13.3) with ESMTP id j8AN3ZcV073022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 Sep 2005 19:03:35 -0400 (EDT) (envelope-from mi@blue.virtual-estates.net) Received: (from mi@localhost) by blue.virtual-estates.net (8.13.4/8.13.3/Submit) id j8AN3ZO9073021; Sat, 10 Sep 2005 19:03:35 -0400 (EDT) (envelope-from mi) From: "Mikhail T." Message-Id: <200509102303.j8AN3ZO9073021@blue.virtual-estates.net> To: amd64@FreeBSD.org, current@FreeBSD.org Date: Sat, 10 Sep 2005 19:03:35 -0400 (EDT) X-Face: %UW#n0|w>ydeGt/b@1-.UFP=K^~-:0f#O:D7w hJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Sep 2005 23:03:38 -0000 Hello! I built and installed audio/timidity the stock compiler with my usual CFLAGS: -O2 -fno-strict-aliasing -pipe -march=opteron It dies on startup from SIGFPE. I turned on "-Wall -Werror" and patched the port to compile cleanly without any warning. That did not help... Compiling with -O1 or -O0 is fine. I remember having the same issue with Tcl84 compiled with -O2 -- what's wrong with the second level of optimization? Is not it supposed to finally work? I'm using 5.4-stable from July 21 on amd64. Please, advise. Thanks! -mi From owner-freebsd-current@FreeBSD.ORG Sun Sep 11 08:18:36 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8427816A41F for ; Sun, 11 Sep 2005 08:18:36 +0000 (GMT) (envelope-from lulf@samfundet.no) Received: from cassarossa.samfundet.no (cassarossa.samfundet.no [129.241.93.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A84443D45 for ; Sun, 11 Sep 2005 08:18:35 +0000 (GMT) (envelope-from lulf@samfundet.no) Received: from lulf by cassarossa.samfundet.no with local (Exim 4.50) id 1EEN2o-0005Hh-6W for freebsd-current@freebsd.org; Sun, 11 Sep 2005 10:18:34 +0200 Date: Sun, 11 Sep 2005 10:18:34 +0200 To: freebsd-current@freebsd.org Message-ID: <20050911081834.GA20281@samfundet.no> References: <200509101915.32081@harrymail> <43231B50.7010302@gmx.de> <20050911001659.GA62710@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050911001659.GA62710@dragon.NUXI.org> User-Agent: Mutt/1.5.9i From: Ulf Lilleengen X-Mailman-Approved-At: Sun, 11 Sep 2005 11:08:27 +0000 Subject: Re: cvsup stuff in BETA4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Sep 2005 08:18:36 -0000 On 17:16, Sat 10 Sep 05, David O'Brien wrote: > On Sat, Sep 10, 2005 at 07:43:44PM +0200, Philip S. Schulz wrote: > > on 10.09.2005 19:15 Uhr Emanuel Strobl said the following: > > >Hello, > > > > > >I just installed BETA4 on my laptop and saw that the stable-supfile still > > >has RELENG_5 as default tag. Shouldn't this be changed to RELENG_6? > > >Another question: Why are these example files in the base system while > > >cvsup itself isn't? I think they should be located > > >in /usr/local/share/examples, or /usr/local/etc together with the port... > > > > Because you would still need to build ezm3 to build cvsup. And, AFAIK, > > there are platforms where cvsup is not fully supported, amd64 comes to > > mind... > > No. It is that way purely by tradition. We feel that it is easiest to > keep the cvsup example files in the base system so that we can make it > easier for the user to have the right RELENG_X tag, etc... > > CVSup isn't in /usr/src because it is written in Modula-3 and we don't > want to bring a Modula-3 compiler into the base system. It has nothing > to do with architectures. > > -- > -- David (obrien@FreeBSD.org) A rewrite of cvsup in C is in motion, called, csup: http://mu.org/~mux/csup.html I've been helping maxime a bit with it, but more help is appreciated! -- - Ulf Lilleengen From owner-freebsd-current@FreeBSD.ORG Sun Sep 11 12:10:16 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 906BA16A41F for ; Sun, 11 Sep 2005 12:10:16 +0000 (GMT) (envelope-from colazelli@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6C9843D49 for ; Sun, 11 Sep 2005 12:10:14 +0000 (GMT) (envelope-from colazelli@gmail.com) Received: by wproxy.gmail.com with SMTP id i21so1445496wra for ; Sun, 11 Sep 2005 05:10:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=P2i0OEVmneW4lCoUjQvfcoINPtg3zAfMnAE/cJe8EXiMZJxVBZUvBnuALgtJt665J+HgCCz+7uKN/IW1GRutaQ7ELE1alRdixK9gPHMPeWl20/xzD9f/fnNzdsbUuIynBIblfnWTciBo5hM/qLkRmZRX7/ZzPr/rXoD6nP/Q1xA= Received: by 10.54.33.57 with SMTP id g57mr1766723wrg; Sun, 11 Sep 2005 05:10:14 -0700 (PDT) Received: from localhost.localdomain ( [201.27.109.149]) by mx.gmail.com with ESMTP id 64sm450678wra.2005.09.11.05.10.12; Sun, 11 Sep 2005 05:10:14 -0700 (PDT) From: Wesley Gentine To: =?ISO-8859-1?Q?S=F8ren?= Schmidt In-Reply-To: References: <1126047871.687.1.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1 Date: Sun, 11 Sep 2005 09:10:31 -0300 Message-Id: <1126440631.689.5.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: freebsd-current@FreeBSD.org Subject: Re: ATA error on 6.0-BETA4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Sep 2005 12:10:16 -0000 Thanks for your feedback Soren. Enabling some debug features in kernel dont offer more information, unfortunally. But, booting with 5.4 Kernel, this drive is working correctly: atapci0: port 0xa800-0xa80f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 17.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 ad0: 38172MB [77557/16/63] at ata0-master UDMA133 acd0: CDRW at ata1-slave PIO4 Here's the dmesg from 6.0-BETA4: FreeBSD 6.0-BETA4 #0: Sun Sep 11 08:29:43 BRT 2005 wgentine@powerplant:/usr/src/sys/i386/compile/POWERPLANT WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(TM) XP 2400+ (2000.08-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x681 Stepping = 1 Features=0x383fbff AMD Features=0xc0400800 real memory = 268419072 (255 MB) ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard npx0: [FAST] acpi0: on motherboard acpi0: Power Button (fixed) pci_link0: irq 11 on acpi0 pci_link1: irq 0 on acpi0 pci_link2: irq 0 on acpi0 pci_link3: irq 0 on acpi0 pci_link4: irq 3 on acpi0 pci_link5: irq 15 on acpi0 pci_link6: irq 9 on acpi0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xf8000000-0xfbffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) fxp0: port 0xd800-0xd83f mem 0xf1800000-0xf1800fff,0xf1000000-0xf10fffff irq 16 at device 13.0 on pci0 miibus0: on fxp0 inphy0: on miibus0 pci0: at device 14.0 (no driver attached) pci0: mem: Pentium Pro MTRR support enabled npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x80000060 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=71908086) pcibios: BIOS version 2.10 Found $PIR table, 9 entries at 0xc00fbd80 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded 0 7 D 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 1 0 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 1 0 B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 0 3 A 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 0 3 B 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 0 8 A 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 0 16 A 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 0 16 B 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 8 0 A 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 8 1 A 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 0 13 A 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 17 A 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 17 B 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 17 C 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 17 D 0x62 3 4 5 6 7 9 10 11 12 14 15 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 7 func 0 atpic: Programming IRQ9 as level/low ACPI timer: 0/3 0/3 0/3 0/3 0/3 0/3 0/3 0/3 0/3 0/3 -> 0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 acpi_acad0: on acpi0 acpi_cmbat0: on acpi0 acpi_cmbat1: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 ACPI PCI link initial configuration: \\_SB_.PCI0.LNKA irq 0: [ 9 10 11] 11+ low,level,sharable 0.7.0 \\_SB_.PCI0.LNKB irq 0: [ 5 7] 5+ low,level,sharable 0.7.1 \\_SB_.PCI0.LNKC irq 0: [ 9 10 11] 0+ low,level,sharable 0.7.2 \\_SB_.PCI0.LNKD irq 0: [ 5 7 9 10 11] 11+ low,level,sharable 0.7.3 \\_SB_.PCI0.LNKA irq 0: [ 9 10 11] 11+ low,level,sharable 0.1.0 \\_SB_.PCI0.LNKB irq 0: [ 5 7] 5+ low,level,sharable 0.1.1 \\_SB_.PCI0.LNKD irq 0: [ 5 7 9 10 11] 11+ low,level,sharable 0.3.0 \\_SB_.PCI0.LNKD irq 0: [ 5 7 9 10 11] 11+ low,level,sharable 0.3.1 \\_SB_.PCI0.LNKC irq 0: [ 9 10 11] 0+ low,level,sharable 0.13.0 \\_SB_.PCI0.LNKB irq 0: [ 5 7] 5+ low,level,sharable 0.8.0 \\_SB_.PCI0.LNKD irq 0: [ 5 7 9 10 11] 11+ low,level,sharable 0.16.0 \\_SB_.PCI0.LNKC irq 0: [ 9 10 11] 0+ low,level,sharable 0.16.1 pci0: on pcib0 pci0: physical bus=0 map[10]: type 3, range 32, base f4000000, size 26, enabled found-> vendor=0x8086, dev=0x7190, revid=0x03 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x2210, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x7191, revid=0x03 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x011f, statreg=0x0220, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x8c (35000 ns), maxlat=0x00 (0 ns) map[10]: type 1, range 32, base 00000000, size 12, memory disabled found-> vendor=0x104c, dev=0xac51, revid=0x00 bus=0, slot=3, func=0 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0000, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x40 (16000 ns), maxlat=0x07 (1750 ns) intpin=a, irq=255 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 00000000, size 12, memory disabled found-> vendor=0x104c, dev=0xac51, revid=0x00 bus=0, slot=3, func=1 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0000, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x40 (16000 ns), maxlat=0x07 (1750 ns) intpin=a, irq=255 powerspec 1 supports D0 D1 D2 D3 current D0 found-> vendor=0x8086, dev=0x7110, revid=0x02 bus=0, slot=7, func=0 class=06-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x010f, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 00000860, size 4, enabled found-> vendor=0x8086, dev=0x7111, revid=0x01 bus=0, slot=7, func=1 class=01-01-80, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0000dce0, size 5, enabled pcib0: matched entry for 0.7.INTD (src \\_SB_.PCI0.LNKD) pcib0: possible interrupts: 5 7 9 10 11 ACPI PCI link arbitrated settings: \\_SB_.PCI0.LNKB (references 3, priority 7785): interrupts: 5 7 penalty: 120 5070 \\_SB_.PCI0.LNKD (references 4, priority 4440): interrupts: 11 10 5 9 7 penalty: 90 90 120 180 5070 \\_SB_.PCI0.LNKC (references 3, priority 360): interrupts: 11 10 9 penalty: 90 90 180 \\_SB_.PCI0.LNKA (references 2, priority 240): interrupts: 11 10 9 penalty: 90 90 180 pcib0: slot 7 INTD routed to irq 11 via \\_SB_.PCI0.LNKD found-> vendor=0x8086, dev=0x7112, revid=0x01 bus=0, slot=7, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=11 map[90]: type 4, range 32, base 00000840, size 4, enabled found-> vendor=0x8086, dev=0x7113, revid=0x03 bus=0, slot=7, func=3 class=06-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 4, range 32, base 0000d800, size 8, enabled map[14]: type 1, range 32, base f3ffe000, size 13, enabled pcib0: matched entry for 0.8.INTA (src \\_SB_.PCI0.LNKB) pcib0: possible interrupts: 5 7 ACPI PCI link arbitrated settings: \\_SB_.PCI0.LNKB (references 3, priority 7995): interrupts: 5 7 penalty: 190 5140 \\_SB_.PCI0.LNKC (references 3, priority 760): interrupts: 10 11 9 penalty: 180 220 360 \\_SB_.PCI0.LNKA (references 2, priority 506): interrupts: 10 11 9 penalty: 180 220 360 pcib0: slot 8 INTA routed to irq 5 via \\_SB_.PCI0.LNKB found-> vendor=0x125d, dev=0x1998, revid=0x10 bus=0, slot=8, func=0 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x02 (500 ns), maxlat=0x18 (6000 ns) intpin=a, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000d400, size 8, enabled map[14]: type 1, range 32, base f3ffdc00, size 7, enabled map[18]: type 1, range 32, base f3ffd800, size 7, enabled pcib0: matched entry for 0.16.INTA (src \\_SB_.PCI0.LNKD) pcib0: slot 16 INTA is already routed to irq 11 found-> vendor=0x10b7, dev=0x6055, revid=0x10 bus=0, slot=16, func=0 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0117, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x0a (2500 ns), maxlat=0x05 (1250 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000d000, size 8, enabled map[14]: type 1, range 32, base f3ffd400, size 8, enabled map[18]: type 1, range 32, base f3ffd000, size 7, enabled pcib0: matched entry for 0.16.INTA (src \\_SB_.PCI0.LNKD) pcib0: slot 16 INTA is already routed to irq 11 found-> vendor=0x10b7, dev=0x1007, revid=0x10 bus=0, slot=16, func=1 class=07-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x0a (2500 ns), maxlat=0x05 (1250 ns) intpin=a, irq=11 powerspec 2 supports D0 D2 D3 current D0 agp0: mem 0xf4000000-0xf7ffffff at device 0.0 on pci0 agp0: Reserved 0x4000000 bytes for rid 0x10 type 3 at 0xf4000000 agp0: allocating GATT for aperture of size 64M pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xe000-0xefff pcib1: memory decode 0xfd000000-0xfeffffff pcib1: prefetched decode 0xf8000000-0xfbffffff ACPI PCI link initial configuration: \\_SB_.PCI0.LNKA irq 0: [ 9 10 11] 11+ low,level,sharable 1.0.0 pci1: on pcib1 pci1: physical bus=1 map[10]: type 3, range 32, base f8000000, size 26, enabled pcib1: device (null) requested decoded memory range 0xf8000000-0xfbffffff map[14]: type 4, range 32, base 0000ec00, size 8, enabled pcib1: device (null) requested decoded I/O range 0xec00-0xecff map[18]: type 1, range 32, base fdffc000, size 14, enabled pcib1: device (null) requested decoded memory range 0xfdffc000-0xfdffffff pcib1: matched entry for 1.0.INTA (src \\_SB_.PCI0.LNKA) pcib1: possible interrupts: 9 10 11 ACPI PCI link arbitrated settings: \\_SB_.PCI0.LNKC (references 3, priority 820): interrupts: 10 11 9 penalty: 200 240 380 \\_SB_.PCI0.LNKA (references 3, priority 820): interrupts: 10 11 9 penalty: 200 240 380 pcib1: slot 0 INTA routed to irq 11 via \\_SB_.PCI0.LNKA found-> vendor=0x1002, dev=0x4c46, revid=0x02 bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0087, statreg=0x02b0, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 pci1: at device 0.0 (no driver attached) cbb0: at device 3.0 on pci0 cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0x80000000 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 pcib0: matched entry for 0.3.INTA (src \\_SB_.PCI0.LNKD) pcib0: slot 3 INTA is already routed to irq 11 cbb0: [MPSAFE] cbb0: PCI Configuration space: 0x00: 0xac51104c 0x02100007 0x06070000 0x00822008 0x10: 0x80000000 0x020000a0 0x20040400 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc 0x30: 0x00000000 0xfffffffc 0x00000000 0x0740010b 0x40: 0x00b11028 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x2024d025 0x00000000 0x00000000 0x01261222 0x90: 0x6064a6c0 0x00000000 0x00000000 0x00000000 0xa0: 0xfe110001 0x00c00000 0x0000081b 0x00000007 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 cbb1: at device 3.1 on pci0 cbb1: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0x80001000 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 pcib0: matched entry for 0.3.INTA (src \\_SB_.PCI0.LNKD) pcib0: slot 3 INTA is already routed to irq 11 cbb1: [MPSAFE] cbb1: PCI Configuration space: 0x00: 0xac51104c 0x02100007 0x06070000 0x00822008 0x10: 0x80001000 0x020000a0 0x20050500 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc 0x30: 0x00000000 0xfffffffc 0x00000000 0x0740010b 0x40: 0x00b11028 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x2024f025 0x00000000 0x00000000 0x01261222 0x90: 0x6064a6c0 0x00000000 0x00000000 0x00000000 0xa0: 0xfe110001 0x00c00000 0x0000081b 0x00000007 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 PCI-ISA bridge with incorrect subclass 0x80 PCI-ISA bridge with incorrect subclass 0x80 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x860-0x86f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x860 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=0x10 err=0x01 lsb=0x14 msb=0xeb ata1-slave: stat=0x00 err=0x00 lsb=0x00 msb=0x00 ata1: reset tp2 stat0=10 stat1=00 devices=0x4 ata1: [MPSAFE] uhci0: port 0xdce0-0xdcff irq 11 at device 7.2 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xdce0 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 pci0: at device 7.3 (no driver attached) pci0: at device 8.0 (no driver attached) xl0: <3Com 3c556 Fast Etherlink XL> port 0xd400-0xd4ff mem 0xf3ffd800-0xf3ffd87f,0xf3ffdc00-0xf3ffdc7f irq 11 at device 16.0 on pci0 xl0: Reserved 0x80 bytes for rid 0x14 type 3 at 0xf3ffdc00 xl0: using memory mapped I/O xl0: Reserved 0x80 bytes for rid 0x18 type 3 at 0xf3ffd800 xl0: media options word: 40 xl0: found MII/AUTO miibus0: on xl0 tdkphy0: on miibus0 tdkphy0: OUI 0x00c039, model 0x0014, rev. 11 tdkphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: bpf attached xl0: Ethernet address: 00:04:76:48:c7:b2 xl0: [MPSAFE] pci0: at device 16.1 (no driver attached) acpi_tz0: on acpi0 unknown: not probed (disabled) psmcpnp0: irq 12 on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: current command byte:0065 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 fdc0: port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: ic_type 90 part_id 80 fdc0: [MPSAFE] fdc0: [FAST] sio0: irq maps: 0x301 0x311 0x301 0x301 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A unknown: not probed (disabled) ppc0: using extended I/O port range ppc0: ECP SPP ECP+EPP SPP ppc0: port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 plip0: bpf attached lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it fdc: fdc0 already exists; skipping it ppc: ppc0 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 sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it ahc_isa_probe 13: ioport 0xdc00 alloc failed ahc_isa_probe 14: ioport 0xec00 alloc failed isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 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) 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) sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0x301 0x301 0x301 0x301 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff 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 e7 a3 4f 67 8f 6a 5b 24 b3 00 6f 0d 0e 00 00 07 80 49 8f 8f 28 1f 47 6d 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 e7 a3 4f 67 8f 6a 5b 24 b3 00 6f 0d 0e 00 00 07 80 49 8f 8f 28 1f 47 6d 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 751707553 Hz quality 800 Timecounters tick every 10.000 msec lo0: bpf attached acpi_acad0: acline initialization start acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times acpi_cmbat0: battery initialization start acpi_cmbat0: battery initialization done, tried 1 times acpi_cmbat1: battery initialization start fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout ata0-master: pio=0x0c wdma=0x22 udma=0x45 cable=80pin ata0-master: setting PIO4 on Intel PIIX4 chip pccard1: CIS version PC Card Standard 5.0 pccard1: CIS info: SMC, SMC2532W-B EliteConnect Wireless Adapter, , pccard1: Manufacturer code 0xd601, product 0x5 pccard1: function 0: network adapter, ccr addr 3e0 mask 1 pccard1: function 0, config table entry 1: I/O card; irq mask ffff; iomask 6, iospace 0-3f; io16 irqpulse irqlevel wi0: at port 0x100-0x13f irq 11 function 0 config 1 on pccard1 wi0: [MPSAFE] wi0: using RF:PRISM2.5 MAC:ISL3873 wi0: Intersil Firmware: Primary (1.1.0), Station (1.4.9) wi0: bpf attached wi0: Ethernet address: 00:04:e2:80:34:be wi0: bpf attached wi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps wi0: bpf attached fdc0: output ready timeout fdc0: input ready timeout fdc0: input ready timeout fdc0: output ready timeout fdc0: input ready timeout fdc0: input ready timeout fdc0: output ready timeout fdc0: input ready timeout fdc0: input ready timeout fdc0: output ready timeout fdc0: input ready timeout fdc0: input ready timeout ata0-master: setting UDMA33 on Intel PIIX4 chip ad0: ATA-6 disk at ata0-master ad0: 19077MB (39070080 sectors), 38760 C, 16 H, 63 S, 512 B ad0: 16 secs/int, 1 depth queue, UDMA33 GEOM: new disk ad0 ar: FreeBSD check1 failed ata1-master: pio=0x0c wdma=0x22 udma=0xffffffff cable=40pin ata1-master: setting PIO4 on Intel PIIX4 chip acd0: CDRW drive at ata1 as master acd0: read 4134KB/s (4134KB/s) write 1377KB/s (1377KB/s), 2048KB buffer, PIO4 acd0: Reads: CDR, CDRW, CDDA stream, packet acd0: Writes: CDR, CDRW, test write, burnproof acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc [0] f:00 typ:131 s(CHS):0/1/1 e(CHS):1023/15/63 s:63 l:19534977 [1] f:80 typ:165 s(CHS):1023/255/63 e(CHS):1023/15/63 s:19535040 l:19535040 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [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 10001908224 end 10001940479 GEOM: Configure ad0s2, start 10001940480 length 10001940480 end 20003880959 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 GEOM: Configure ad0s2a, start 0 length 268435456 end 268435455 GEOM: Configure ad0s2b, start 268435456 length 1047166976 end 1315602431 GEOM: Configure ad0s2c, start 0 length 10001940480 end 10001940479 GEOM: Configure ad0s2d, start 1315602432 length 268435456 end 1584037887 GEOM: Configure ad0s2e, start 1584037888 length 268435456 end 1852473343 GEOM: Configure ad0s2f, start 1852473344 length 8149467136 end 10001940479 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 Mounting root from ufs:/dev/ad0s2a start_init: trying /sbin/init Linux ELF exec handler installed --------------090504010806030302040901 Content-Type: text/plain; name="dmesg-7.0" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg-7.0" Copyright (c) 1992-2005 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 7.0-CURRENT #0: Mon Sep 12 04:45:28 UTC 2005 pbowen@sg1.sgc.org:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xc0b19000. Preloaded elf module "/boot/kernel/snd_maestro3.ko" at 0xc0b19138. Preloaded elf module "/boot/kernel/sound.ko" at 0xc0b191ec. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0b19298. Calibrating clock(s) ... i8254 clock: 1193297 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 751708637 Hz CPU: Intel Pentium III (751.71-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x68a Stepping = 10 Features=0x383f9ff real memory = 536719360 (511 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c28000 - 0x000000001f6a2fff, 514306048 bytes (125563 pages) avail memory = 515698688 (491 MB) bios32: Found BIOS32 Service Directory header at 0xc00ffe80 bios32: Entry = 0xffe90 (c00ffe90) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xc13e pnpbios: Found PnP BIOS data at 0xc00fe2d0 pnpbios: Entry = f0000:e2f4 Rev = 1.0 pnpbios: Event flag at 4b4 Other BIOS signatures found: wlan: <802.11 Link Layer> random: nfslock: pseudo-device io: mem: Pentium Pro MTRR support enabled null: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x80000060 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=71908086) pcibios: BIOS version 2.10 Found $PIR table, 9 entries at 0xc00fbd80 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded 0 7 D 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 1 0 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 1 0 B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 0 3 A 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 0 3 B 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 0 8 A 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 0 16 A 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 0 16 B 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 8 0 A 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 8 1 A 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 0 13 A 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 17 A 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 17 B 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 17 C 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 17 D 0x62 3 4 5 6 7 9 10 11 12 14 15 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 7 func 0 atpic: Programming IRQ9 as level/low pci_link0: irq 11 on acpi0 pci_link0: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 9 10 11 pci_link0: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 9 10 11 pci_link0: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 9 10 11 pci_link1: irq 5 on acpi0 pci_link1: Links after initial probe: Index IRQ Rtd Ref IRQs 0 5 N 0 5 7 pci_link1: Links after initial validation: Index IRQ Rtd Ref IRQs 0 5 N 0 5 7 pci_link1: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 5 7 pci_link2: on acpi0 pci_link2: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 9 10 11 pci_link2: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 9 10 11 pci_link2: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 9 10 11 pci_link3: irq 11 on acpi0 pci_link3: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 5 7 9 10 11 pci_link3: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 5 7 9 10 11 pci_link3: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 5 7 9 10 11 ACPI timer: 0/4 0/4 0/4 0/4 0/4 0/4 0/4 0/4 0/4 0/4 -> 0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 battery1: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x8086, dev=0x7190, revid=0x03 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x2210, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 3, range 32, base f4000000, size 26, enabled found-> vendor=0x8086, dev=0x7191, revid=0x03 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x011f, statreg=0x0220, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x8c (35000 ns), maxlat=0x00 (0 ns) found-> vendor=0x104c, dev=0xac51, revid=0x00 bus=0, slot=3, func=0 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0000, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x40 (16000 ns), maxlat=0x07 (1750 ns) intpin=a, irq=255 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 00000000, size 12, memory disabled found-> vendor=0x104c, dev=0xac51, revid=0x00 bus=0, slot=3, func=1 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0000, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x40 (16000 ns), maxlat=0x07 (1750 ns) intpin=a, irq=255 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 00000000, size 12, memory disabled found-> vendor=0x8086, dev=0x7110, revid=0x02 bus=0, slot=7, func=0 class=06-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x010f, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x7111, revid=0x01 bus=0, slot=7, func=1 class=01-01-80, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 00000860, size 4, enabled found-> vendor=0x8086, dev=0x7112, revid=0x01 bus=0, slot=7, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=11 map[20]: type 4, range 32, base 0000dce0, size 5, enabled pcib0: matched entry for 0.7.INTD (src \\_SB_.PCI0.LNKD:0) pcib0: slot 7 INTD routed to irq 11 via \\_SB_.PCI0.LNKD found-> vendor=0x8086, dev=0x7113, revid=0x03 bus=0, slot=7, func=3 class=06-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[90]: type 4, range 32, base 00000840, size 4, enabled found-> vendor=0x125d, dev=0x1998, revid=0x10 bus=0, slot=8, func=0 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x02 (500 ns), maxlat=0x18 (6000 ns) intpin=a, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000d800, size 8, enabled map[14]: type 1, range 32, base f3ffe000, size 13, enabled pcib0: matched entry for 0.8.INTA (src \\_SB_.PCI0.LNKB:0) pcib0: slot 8 INTA routed to irq 5 via \\_SB_.PCI0.LNKB found-> vendor=0x10b7, dev=0x6055, revid=0x10 bus=0, slot=16, func=0 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0117, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x0a (2500 ns), maxlat=0x05 (1250 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000d400, size 8, enabled map[14]: type 1, range 32, base f3ffdc00, size 7, enabled map[18]: type 1, range 32, base f3ffd800, size 7, enabled pcib0: matched entry for 0.16.INTA (src \\_SB_.PCI0.LNKD:0) pcib0: slot 16 INTA routed to irq 11 via \\_SB_.PCI0.LNKD found-> vendor=0x10b7, dev=0x1007, revid=0x10 bus=0, slot=16, func=1 class=07-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x0a (2500 ns), maxlat=0x05 (1250 ns) intpin=a, irq=11 powerspec 2 supports D0 D2 D3 current D0 map[10]: type 4, range 32, base 0000d000, size 8, enabled map[14]: type 1, range 32, base f3ffd400, size 8, enabled map[18]: type 1, range 32, base f3ffd000, size 7, enabled pcib0: matched entry for 0.16.INTA (src \\_SB_.PCI0.LNKD:0) pcib0: slot 16 INTA routed to irq 11 via \\_SB_.PCI0.LNKD agp0: mem 0xf4000000-0xf7ffffff at device 0.0 on pci0 agp0: Reserved 0x4000000 bytes for rid 0x10 type 3 at 0xf4000000 agp0: allocating GATT for aperture of size 64M pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xe000-0xefff pcib1: memory decode 0xfd000000-0xfeffffff pcib1: prefetched decode 0xf8000000-0xfbffffff pci1: on pcib1 pci1: physical bus=1 found-> vendor=0x1002, dev=0x4c46, revid=0x02 bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0087, statreg=0x02b0, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 3, range 32, base f8000000, size 26, enabled pcib1: (null) requested memory range 0xf8000000-0xfbffffff: good map[14]: type 4, range 32, base 0000ec00, size 8, enabled pcib1: (null) requested I/O range 0xec00-0xecff: in range map[18]: type 1, range 32, base fdffc000, size 14, enabled pcib1: (null) requested memory range 0xfdffc000-0xfdffffff: good pcib1: matched entry for 1.0.INTA (src \\_SB_.PCI0.LNKA:0) pcib1: slot 0 INTA routed to irq 11 via \\_SB_.PCI0.LNKA pci1: at device 0.0 (no driver attached) cbb0: at device 3.0 on pci0 cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0x80000000 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 pcib0: matched entry for 0.3.INTA (src \\_SB_.PCI0.LNKD:0) pcib0: slot 3 INTA routed to irq 11 via \\_SB_.PCI0.LNKD cbb0: [MPSAFE] cbb0: PCI Configuration space: 0x00: 0xac51104c 0x02100007 0x06070000 0x00822008 0x10: 0x80000000 0x020000a0 0x20040400 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc 0x30: 0x00000000 0xfffffffc 0x00000000 0x0740010b 0x40: 0x00b11028 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x2024d025 0x00000000 0x00000000 0x01261222 0x90: 0x6064a6c0 0x00000000 0x00000000 0x00000000 0xa0: 0xfe110001 0x00c00000 0x0000081b 0x00000007 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 cbb1: at device 3.1 on pci0 cbb1: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0x80001000 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 pcib0: matched entry for 0.3.INTA (src \\_SB_.PCI0.LNKD:0) pcib0: slot 3 INTA routed to irq 11 via \\_SB_.PCI0.LNKD cbb1: [MPSAFE] cbb1: PCI Configuration space: 0x00: 0xac51104c 0x02100007 0x06070000 0x00822008 0x10: 0x80001000 0x020000a0 0x20050500 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc 0x30: 0x00000000 0xfffffffc 0x00000000 0x0740010b 0x40: 0x00b11028 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x2024f025 0x00000000 0x00000000 0x01261222 0x90: 0x6064a6c0 0x00000000 0x00000000 0x00000000 0xa0: 0xfe110001 0x00c00000 0x0000081b 0x00000007 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 PCI-ISA bridge with incorrect subclass 0x80 PCI-ISA bridge with incorrect subclass 0x80 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x860-0x86f at device 7.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x860 ata0: 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: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 ata0: [MPSAFE] ata1: 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: stat0=0x10 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 ata1: reset tp2 stat0=10 stat1=00 devices=0x4 ata1: [MPSAFE] uhci0: port 0xdce0-0xdcff irq 11 at device 7.2 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xdce0 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 pci0: at device 7.3 (no driver attached) pcm0: port 0xd800-0xd8ff mem 0xf3ffe000-0xf3ffffff irq 5 at device 8.0 on pci0 pci0: child pcm0 requested type 3 for rid 0x10, but the BAR says it is an ioport pcm0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xd800 pcm0: [MPSAFE] lock order reversal 1st 0xc1b0b2c0 pcm0 (sound softc) @ /usr/src/sys/modules/sound/driver/maestro3/../../../../dev/sound/pci/maestro3.c:1259 2nd 0xc0926c00 kernel environment (kernel environment) @ /usr/src/sys/kern/subr_hints.c:117 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c0938390,c09390d8,c08c4a0c) at kdb_backtrace+0x29 witness_checkorder(c0926c00,1,c0860052,75) at witness_checkorder+0x52c _sx_slock(c0926c00,c0860052,75,0,0) at _sx_slock+0x50 res_find(c0c20a84,0,c1ab056c,c0c20a98,c0a9683a,0,0,0,0,0,0,c0c20a88) at res_find+0x18f resource_find(c0c20a84,0,c1ab056c,c0c20a98,c0a9683a,0,0,0,0,0,0,c0c20a88) at resource_find+0x3b resource_int_value(c1ab056c,0,c0a9683a,c0c20aa8,c1b0b2c0) at resource_int_value+0x32 m3_config(c1b1b000,1,c1af9200,c1b1b02c,c1b1b000) at m3_config+0x3f m3_init(c1b1b000,c1b1b000,0,c1b0b2c0,0) at m3_init+0xba m3_pci_attach(c1af9200) at m3_pci_attach+0x333 device_attach(c1af9200,c1af9180,c1af9200,c1af3c80,c1af3c80) at device_attach+0x58 device_probe_and_attach(c1af9200) at device_probe_and_attach+0xe0 bus_generic_attach(c1af3c80,6,c1ade1a0,1,c0aeae88) at bus_generic_attach+0x16 acpi_pci_attach(c1af3c80) at acpi_pci_attach+0xec device_attach(c1af3c80,c19ce7b8,c1af3c80,0,c1ac1480) at device_attach+0x58 device_probe_and_attach(c1af3c80) at device_probe_and_attach+0xe0 bus_generic_attach(c1ac1480,c1aebb94,c0aeb144,c1ac1480,c0ae7165) at bus_generic_attach+0x16 acpi_pcib_attach(c1ac1480,c1aebb94,0,c0c20c64,c064c8e8) at acpi_pcib_attach+0x160 acpi_pcib_acpi_attach(c1ac1480) at acpi_pcib_acpi_attach+0x20a device_attach(c1ac1480,0,c1ac1480,c1ac1a00,0) at device_attach+0x58 device_probe_and_attach(c1ac1480) at device_probe_and_attach+0xe0 bus_generic_attach(c1ac1a80,1,c0c20cd8,c0ae6c04,c1ac1a80) at bus_generic_attach+0x16 acpi_probe_children(c1ac1a80,404e418,c1ac1a80,c1ac1a80,0) at acpi_probe_children+0x2f acpi_attach(c1ac1a80) at acpi_attach+0x514 device_attach(c1ac1a80,c0b030a0,c1ac1a80,c1ac2300,0) at device_attach+0x58 device_probe_and_attach(c1ac1a80) at device_probe_and_attach+0xe0 bus_generic_attach(c1ac2300,c1ac2300,c1ac2300,c0c20d40,c0648d24) at bus_generic_attach+0x16 nexus_attach(c1ac2300) at nexus_attach+0x13 device_attach(c1ac2300,c08fe4b0,c1ac2300,c08fe4b0,c28000) at device_attach+0x58 device_probe_and_attach(c1ac2300) at device_probe_and_attach+0xe0 root_bus_configure(c0c20d88,c060d0e6,0,c1ec00,c1e000) at root_bus_configure+0x16 configure(0,c1ec00,c1e000,0,c0445a65) at configure+0x9 mi_startup() at mi_startup+0x96 begin() at begin+0x2c pcm0: pcm0: Codec features 18 bit DAC, 18 bit ADC, 5 bit master volume, SigmaTel 3D Enhancement pcm0: Primary codec extended features AMAP pcm0: ac97 codec dac ready count: 0 pcm0: sndbuf_setmap 7ffe000, 1000; 0xd971f000 -> 7ffe000 pcm0: sndbuf_setmap 7ffd000, 1000; 0xd9720000 -> 7ffd000 pcm0: sndbuf_setmap 7ffc000, 1000; 0xd9721000 -> 7ffc000 pcm0: sndbuf_setmap 7ffb000, 1000; 0xd9722000 -> 7ffb000 pcm0: sndbuf_setmap 7ffa000, 1000; 0xd9723000 -> 7ffa000 xl0: <3Com 3c556 Fast Etherlink XL> port 0xd400-0xd4ff mem 0xf3ffdc00-0xf3ffdc7f,0xf3ffd800-0xf3ffd87f irq 11 at device 16.0 on pci0 xl0: Reserved 0x80 bytes for rid 0x14 type 3 at 0xf3ffdc00 xl0: using memory mapped I/O xl0: Reserved 0x80 bytes for rid 0x18 type 3 at 0xf3ffd800 xl0: media options word: 40 xl0: found MII/AUTO miibus0: on xl0 tdkphy0: on miibus0 tdkphy0: OUI 0x00c039, model 0x0014, rev. 11 tdkphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: bpf attached xl0: Ethernet address: 00:04:76:48:c7:b2 xl0: [MPSAFE] pci0: at device 16.1 (no driver attached) pci0:16:1: Transition from D0 to D3 acpi_tz0: on acpi0 psmcpnp0: irq 12 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: current command byte:0065 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 fdc0: port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: ic_type 90 part_id 80 fdc0: [MPSAFE] fdc0: [FAST] sio0: irq maps: 0x301 0x311 0x301 0x301 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A ppc0: using extended I/O port range ppc0: ECP SPP ECP+EPP SPP ppc0: port 0x378-0x37f,0x778-0x77b irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 plip0: bpf attached lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it fdc: fdc0 already exists; skipping it ppc: ppc0 already exists; skipping it sio: sio0 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete 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 sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it ahc_isa_probe 13: ioport 0xdc00 alloc failed ahc_isa_probe 14: ioport 0xec00 alloc failed isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcffff pnpid ORM0000 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) fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0x301 0x301 0x301 0x301 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff 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 vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. procfs registered Timecounter "TSC" frequency 751708637 Hz quality 800 Timecounters tick every 1.000 msec lo0: bpf attached acpi_acad0: acline initialization start battery0: battery initialization start pccard1: CIS version PC Card Standard 5.0 pccard1: CIS info: SMC, SMC2532W-B EliteConnect Wireless Adapter, , pccard1: Manufacturer code 0xd601, product 0x5 pccard1: function 0: network adapter, ccr addr 3e0 mask 1 pccard1: function 0, config table entry 1: I/O card; irq mask ffff; iomask 6, iospace 0-3f; io16 irqpulse irqlevel wi0: at port 0x100-0x13f irq 11 function 0 config 1 on pccard1 wi0: [MPSAFE] wi0: using RF:PRISM2.5 MAC:ISL3873 wi0: Intersil Firmware: Primary (1.1.0), Station (1.4.9) wi0: bpf attached wi0: Ethernet address: 00:04:e2:80:34:be wi0: bpf attached wi0: bpf attached wi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times battery1: battery initialization start battery0: battery initialization done, tried 1 times ad0: setting PIO4 on Intel PIIX4 chip ad0: setting UDMA33 on Intel PIIX4 chip fdc0: output ready timeout ad0: 19077MB at ata0-master UDMA33 ad0: 39070080 sectors [38760C/16H/63S] 16 sectors/interrupt 1 depth queue ad0: Intel check1 failed ad0: Adaptec check1 failed ad0: LSI (v3) check1 failed ad0: LSI (v2) check1 failed fdc0: output ready timeout ad0: FreeBSD check1 failed unknown: timeout waiting for read DRQunknown: timeout waiting for read DRQATA PseudoRAID loaded fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout GEOM: new disk ad0 Trying to mount root from ufs:/dev/ad0s2a start_init: trying /sbin/init fdc0: output ready timeout fdc0: input ready timeout fdc0: input ready timeout fdc0: output ready timeout fdc0: input ready timeout fdc0: input ready timeout fdc0: output ready timeout fdc0: input ready timeout fdc0: input ready timeout fdc0: output ready timeout fdc0: input ready timeout fdc0: input ready timeout xl0: link state changed to DOWN Linux ELF exec handler installed battery1: battery initialization failed, giving up --------------090504010806030302040901-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 15 03:35:55 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0369116A41F for ; Thu, 15 Sep 2005 03:35:55 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2707A43D6B for ; Thu, 15 Sep 2005 03:35:48 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j8F3YLXY026282; Wed, 14 Sep 2005 21:34:23 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 14 Sep 2005 21:34:29 -0600 (MDT) Message-Id: <20050914.213429.44985299.imp@bsdimp.com> To: Kirk.Davis@epsb.ca From: "M. Warner Losh" In-Reply-To: <04C71268DFDAA8499EC1A248A44B6A2B34C132@Exchange21.EDU.epsb.ca> References: <04C71268DFDAA8499EC1A248A44B6A2B34C132@Exchange21.EDU.epsb.ca> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Wed, 14 Sep 2005 21:34:31 -0600 (MDT) Cc: freebsd-current@freebsd.org Subject: Re: Using devd to automate wireless | wired network connections X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2005 03:35:55 -0000 In message: <04C71268DFDAA8499EC1A248A44B6A2B34C132@Exchange21.EDU.epsb.ca> Kirk Davis writes: : : : > -----Original Message----- : > From: owner-freebsd-current@freebsd.org : > [mailto:owner-freebsd-current@freebsd.org] On Behalf Of Brooks Davis : > Sent: September 14, 2005 9:54 AM : > To: Jochen Gensch : > Cc: freebsd-current@freebsd.org : > Subject: Re: Using devd to automate wireless | wired network : > connections : > : > On Wed, Sep 14, 2005 at 11:54:45AM +0200, Jochen Gensch wrote: : > > Am Mittwoch 14 September 2005 02:41 schrieben Sie: : > > : > > > Have you tried those changes? If so, are your devices : > > > actually generating media events? If not, that has to be : > fixed and : > > > that's a kernel issue. : > > : : Is there any diagnostic tools that can show the messages that get passed : from the kernel to devd? devd republishes everything it gets via /var/run/devd.pipe. : I have though of some other uses for devd where I : would like to run a script on a device up/down or new device insert but I'm : not sure if there is an event sent to devd for that. *ALL* devices that are added to or removed from the system get a devd event. It isn't like other systems where you have to add support to each bus. : It would be nice to : have a tool that would show if devd was getting an even for that device. : This might also help show the devices that do not yet generate media events. Many don't, that's true :-(. Warner From owner-freebsd-current@FreeBSD.ORG Thu Sep 15 03:47:16 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE00C16A41F for ; Thu, 15 Sep 2005 03:47:16 +0000 (GMT) (envelope-from skywizard@MyBSD.org.my) Received: from tomoyo.MyBSD.org.my (tomoyo.mybsd.org.my [202.157.186.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF57C43D45 for ; Thu, 15 Sep 2005 03:47:11 +0000 (GMT) (envelope-from skywizard@MyBSD.org.my) Received: from localhost (localhost [127.0.0.1]) by tomoyo.MyBSD.org.my (Postfix) with ESMTP id 2B1366CC2D; Thu, 15 Sep 2005 11:55:12 +0800 (MYT) Received: from tomoyo.MyBSD.org.my ([127.0.0.1]) by localhost (tomoyo.MyBSD.org.my [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75120-09; Thu, 15 Sep 2005 11:55:10 +0800 (MYT) Received: from kasumi.MyBSD.org.my (unknown [218.111.181.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tomoyo.MyBSD.org.my (Postfix) with ESMTP id 3E2BC6CC3D; Thu, 15 Sep 2005 11:55:09 +0800 (MYT) Date: Thu, 15 Sep 2005 11:46:53 +0800 From: Ariff Abdullah To: pyunyh@gmail.com, minimarmot@gmail.com Message-Id: <20050915114653.431f17c5.skywizard@MyBSD.org.my> In-Reply-To: <20050915014509.GA17602@rndsoft.co.kr> References: <47d0403c05091121047a037946@mail.gmail.com> <20050912044212.GC5182@rndsoft.co.kr> <47d0403c05091122276fd0a231@mail.gmail.com> <20050913070149.GE9481@rndsoft.co.kr> <47d0403c0509131235ed58122@mail.gmail.com> <20050914014830.GA13631@rndsoft.co.kr> <20050915033848.2d87da42.skywizard@MyBSD.org.my> <20050915014509.GA17602@rndsoft.co.kr> Organization: MyBSD X-Mailer: /usr/local/lib/ruby/1.8/net/smtp.rb Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Thu__15_Sep_2005_11_46_53_+0800_M9_q1d0zk/zgEu9E" X-Virus-Scanned: by amavisd-new-antivirus-mail-gateway at TOMOYO.MYBSD.ORG.MY Cc: freebsd-current@freebsd.org Subject: Re: panic upon kldunload snd_ich (lor # 159) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2005 03:47:16 -0000 This is a multi-part message in MIME format. --Multipart=_Thu__15_Sep_2005_11_46_53_+0800_M9_q1d0zk/zgEu9E Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 15 Sep 2005 10:45:09 +0900 Pyun YongHyeon wrote: > > That would be supposed to fix the LOR message. But I'd like to keep > lock ordering between snd_mutex and sndstat_lock. Since sndstat_read() > could be called at any time there is an implicit lock order. > I think switching to sx lock from mutex in sndstat code was to allow > uiomove with lock held. IMO, it would be even better to rewrite > sndstat_read() without using uiomove such that it can also use > standard mutex rather than sx lock. > I tend to agree with you. Since that sndstat_busy() isn't enough, how about we acquire the entire sndstat so nobody can monkey with it (as the proposed / attached diff) and at the same time avoiding this LOR message. It seems much better rather than locking sndstat after sndstat_busy() and much of pcm_unregister() procedures, only to find out that somebody acquire it within that moment. -- Ariff Abdullah MyBSD http://www.MyBSD.org.my (IPv6/IPv4) http://staff.MyBSD.org.my (IPv6/IPv4) http://tomoyo.MyBSD.org.my (IPv6/IPv4) --Multipart=_Thu__15_Sep_2005_11_46_53_+0800_M9_q1d0zk/zgEu9E Content-Type: text/plain; name="nuke_sndstat_lor.diff" Content-Disposition: attachment; filename="nuke_sndstat_lor.diff" Content-Transfer-Encoding: 7bit --- sys/dev/sound/pcm/sound.h.orig Thu Sep 15 11:25:29 2005 +++ sys/dev/sound/pcm/sound.h Thu Sep 15 11:31:19 2005 @@ -238,11 +238,12 @@ int sysctl_hw_snd_vchans(SYSCTL_HANDLER_ARGS); typedef int (*sndstat_handler)(struct sbuf *s, device_t dev, int verbose); +int sndstat_acquire(void); +int sndstat_release(void); int sndstat_register(device_t dev, char *str, sndstat_handler handler); int sndstat_registerfile(char *str); int sndstat_unregister(device_t dev); int sndstat_unregisterfile(char *str); -int sndstat_busy(void); #define SND_DECLARE_FILE(version) \ _SND_DECLARE_FILE(__LINE__, version) --- sys/dev/sound/pcm/sndstat.c.orig Thu Sep 15 11:25:01 2005 +++ sys/dev/sound/pcm/sndstat.c Thu Sep 15 11:31:07 2005 @@ -195,6 +195,42 @@ } int +sndstat_acquire(void) +{ + intrmask_t s; + + s = spltty(); + sx_xlock(&sndstat_lock); + if (sndstat_isopen) { + sx_unlock(&sndstat_lock); + splx(s); + return EBUSY; + } + sndstat_isopen = 1; + sx_unlock(&sndstat_lock); + splx(s); + return 0; +} + +int +sndstat_release(void) +{ + intrmask_t s; + + s = spltty(); + sx_xlock(&sndstat_lock); + if (!sndstat_isopen) { + sx_unlock(&sndstat_lock); + splx(s); + return EBADF; + } + sndstat_isopen = 0; + sx_unlock(&sndstat_lock); + splx(s); + return 0; +} + +int sndstat_register(device_t dev, char *str, sndstat_handler handler) { intrmask_t s; @@ -371,12 +407,6 @@ sx_xunlock(&sndstat_lock); sx_destroy(&sndstat_lock); return 0; -} - -int -sndstat_busy(void) -{ - return (sndstat_isopen); } static void --- sys/dev/sound/pcm/sound.c.orig Thu Sep 15 11:25:05 2005 +++ sys/dev/sound/pcm/sound.c Thu Sep 15 11:31:07 2005 @@ -758,24 +758,25 @@ struct snddev_channel *sce; struct pcm_channel *ch; + if (sndstat_acquire() != 0) { + device_printf(dev, "unregister: sndstat busy\n"); + return EBUSY; + } + snd_mtxlock(d->lock); if (d->inprog) { device_printf(dev, "unregister: operation in progress\n"); snd_mtxunlock(d->lock); + sndstat_release(); return EBUSY; } - if (sndstat_busy() != 0) { - device_printf(dev, "unregister: sndstat busy\n"); - snd_mtxunlock(d->lock); - return EBUSY; - } - SLIST_FOREACH(sce, &d->channels, link) { ch = sce->channel; if (ch->refcount > 0) { device_printf(dev, "unregister: channel %s busy (pid %d)\n", ch->name, ch->pid); snd_mtxunlock(d->lock); + sndstat_release(); return EBUSY; } } @@ -783,6 +784,7 @@ if (mixer_uninit(dev)) { device_printf(dev, "unregister: mixer busy\n"); snd_mtxunlock(d->lock); + sndstat_release(); return EBUSY; } @@ -807,9 +809,10 @@ chn_kill(d->fakechan); fkchan_kill(d->fakechan); - sndstat_unregister(dev); snd_mtxunlock(d->lock); snd_mtxfree(d->lock); + sndstat_unregister(dev); + sndstat_release(); return 0; } --Multipart=_Thu__15_Sep_2005_11_46_53_+0800_M9_q1d0zk/zgEu9E-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 15 04:34:16 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CBEB016A41F for ; Thu, 15 Sep 2005 04:34:16 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E3B043D48 for ; Thu, 15 Sep 2005 04:34:16 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by zproxy.gmail.com with SMTP id j2so22145nzf for ; Wed, 14 Sep 2005 21:34:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=XZOd9zsJfRK53aSXmC14EISYTyQGg6faLH8QlVSRahBqB1AxkLdsvNR1SlGukd4g25oUwmqylbrayYSwEpDcRqOv7kCbgwD0R7O6ckUsob1Wlo00lyTHGb/D5+JvF8rkQX9RyTRzJlRnLhhiRkUU8R5soEfeNtdhqw9PzFpHX8c= Received: by 10.37.13.2 with SMTP id q2mr2923459nzi; Wed, 14 Sep 2005 21:34:15 -0700 (PDT) Received: from michelle.rndsoft.co.kr ( [211.32.202.211]) by mx.gmail.com with ESMTP id 19sm638605nzp.2005.09.14.21.34.13; Wed, 14 Sep 2005 21:34:14 -0700 (PDT) Received: from michelle.rndsoft.co.kr (localhost.rndsoft.co.kr [127.0.0.1]) by michelle.rndsoft.co.kr (8.13.1/8.13.1) with ESMTP id j8F4Ynvm018550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Sep 2005 13:34:49 +0900 (KST) (envelope-from yongari@gmail.com) Received: (from yongari@localhost) by michelle.rndsoft.co.kr (8.13.1/8.13.1/Submit) id j8F4YmkT018549; Thu, 15 Sep 2005 13:34:48 +0900 (KST) (envelope-from yongari@gmail.com) Date: Thu, 15 Sep 2005 13:34:48 +0900 From: Pyun YongHyeon To: Ariff Abdullah Message-ID: <20050915043448.GB18332@rndsoft.co.kr> References: <47d0403c05091121047a037946@mail.gmail.com> <20050912044212.GC5182@rndsoft.co.kr> <47d0403c05091122276fd0a231@mail.gmail.com> <20050913070149.GE9481@rndsoft.co.kr> <47d0403c0509131235ed58122@mail.gmail.com> <20050914014830.GA13631@rndsoft.co.kr> <20050915033848.2d87da42.skywizard@MyBSD.org.my> <20050915014509.GA17602@rndsoft.co.kr> <20050915114653.431f17c5.skywizard@MyBSD.org.my> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050915114653.431f17c5.skywizard@MyBSD.org.my> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org, minimarmot@gmail.com Subject: Re: panic upon kldunload snd_ich (lor # 159) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2005 04:34:16 -0000 On Thu, Sep 15, 2005 at 11:46:53AM +0800, Ariff Abdullah wrote: > On Thu, 15 Sep 2005 10:45:09 +0900 > Pyun YongHyeon wrote: > > > > That would be supposed to fix the LOR message. But I'd like to keep > > lock ordering between snd_mutex and sndstat_lock. Since sndstat_read() > > could be called at any time there is an implicit lock order. > > I think switching to sx lock from mutex in sndstat code was to allow > > uiomove with lock held. IMO, it would be even better to rewrite > > sndstat_read() without using uiomove such that it can also use > > standard mutex rather than sx lock. > > > I tend to agree with you. Since that sndstat_busy() isn't enough, how > about we acquire the entire sndstat so nobody can monkey with it (as the > proposed / attached diff) and at the same time avoiding this LOR > message. It seems much better rather than locking sndstat after > sndstat_busy() and much of pcm_unregister() procedures, only to find out > that somebody acquire it within that moment. > I didn't try the patch but it looks good to me. :-) If you have more time would you please fix race in sndstat_open()? Minor note : I think it is better to use sx_xunlock ranther than sx_unlock as sx_xunlock clearly indicates which type of locks held. -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Thu Sep 15 06:35:54 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 381AF16A41F for ; Thu, 15 Sep 2005 06:35:54 +0000 (GMT) (envelope-from skywizard@MyBSD.org.my) Received: from tomoyo.MyBSD.org.my (tomoyo.mybsd.org.my [202.157.186.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E1A543D53 for ; Thu, 15 Sep 2005 06:35:53 +0000 (GMT) (envelope-from skywizard@MyBSD.org.my) Received: from localhost (localhost [127.0.0.1]) by tomoyo.MyBSD.org.my (Postfix) with ESMTP id 35F626CC3D; Thu, 15 Sep 2005 14:43:53 +0800 (MYT) Received: from tomoyo.MyBSD.org.my ([127.0.0.1]) by localhost (tomoyo.MyBSD.org.my [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75845-08; Thu, 15 Sep 2005 14:43:52 +0800 (MYT) Received: from kasumi.MyBSD.org.my (unknown [218.111.181.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tomoyo.MyBSD.org.my (Postfix) with ESMTP id 434C06CC22; Thu, 15 Sep 2005 14:43:48 +0800 (MYT) Date: Thu, 15 Sep 2005 14:35:40 +0800 From: Ariff Abdullah To: pyunyh@gmail.com, minimarmot@gmail.com Message-Id: <20050915143540.72b66996.skywizard@MyBSD.org.my> In-Reply-To: <20050915043448.GB18332@rndsoft.co.kr> References: <47d0403c05091121047a037946@mail.gmail.com> <20050912044212.GC5182@rndsoft.co.kr> <47d0403c05091122276fd0a231@mail.gmail.com> <20050913070149.GE9481@rndsoft.co.kr> <47d0403c0509131235ed58122@mail.gmail.com> <20050914014830.GA13631@rndsoft.co.kr> <20050915033848.2d87da42.skywizard@MyBSD.org.my> <20050915014509.GA17602@rndsoft.co.kr> <20050915114653.431f17c5.skywizard@MyBSD.org.my> <20050915043448.GB18332@rndsoft.co.kr> Organization: MyBSD X-Mailer: /usr/local/lib/ruby/1.8/net/smtp.rb Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-antivirus-mail-gateway at TOMOYO.MYBSD.ORG.MY Cc: freebsd-current@freebsd.org Subject: Re: panic upon kldunload snd_ich (lor # 159) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2005 06:35:54 -0000 On Thu, 15 Sep 2005 13:34:48 +0900 Pyun YongHyeon wrote: > On Thu, Sep 15, 2005 at 11:46:53AM +0800, Ariff Abdullah wrote: > > On Thu, 15 Sep 2005 10:45:09 +0900 > > Pyun YongHyeon wrote: > > > > > > That would be supposed to fix the LOR message. But I'd like to > > > keep lock ordering between snd_mutex and sndstat_lock. Since > > > sndstat_read() could be called at any time there is an implicit > > > lock order. I think switching to sx lock from mutex in sndstat > > > code was to allow uiomove with lock held. IMO, it would be even > > > better to rewrite sndstat_read() without using uiomove such that > > > it can also use standard mutex rather than sx lock. > > > > > I tend to agree with you. Since that sndstat_busy() isn't enough, > > how about we acquire the entire sndstat so nobody can monkey with > > it (as the proposed / attached diff) and at the same time avoiding > > this LOR message. It seems much better rather than locking sndstat > > after sndstat_busy() and much of pcm_unregister() procedures, only > > to find out that somebody acquire it within that moment. > > > > I didn't try the patch but it looks good to me. :-) > If you have more time would you please fix race in sndstat_open()? > > Minor note : I think it is better to use sx_xunlock ranther than > sx_unlock as sx_xunlock clearly indicates which type of locks held. > o my, that was a mass typo. Will fix it. -- Ariff Abdullah MyBSD http://www.MyBSD.org.my (IPv6/IPv4) http://staff.MyBSD.org.my (IPv6/IPv4) http://tomoyo.MyBSD.org.my (IPv6/IPv4) From owner-freebsd-current@FreeBSD.ORG Thu Sep 15 06:41:04 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E68CC16A41F for ; Thu, 15 Sep 2005 06:41:04 +0000 (GMT) (envelope-from eta@lclark.edu) Received: from leguin.anholt.net (69-30-77-85.dq1sn.easystreet.com [69.30.77.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E3CB43D46 for ; Thu, 15 Sep 2005 06:41:03 +0000 (GMT) (envelope-from eta@lclark.edu) Received: from leguin.anholt.net (localhost [127.0.0.1]) by leguin.anholt.net (8.13.4/8.13.1) with ESMTP id j8F6f2Oq016401; Wed, 14 Sep 2005 23:41:03 -0700 (PDT) (envelope-from eta@lclark.edu) Received: (from anholt@localhost) by leguin.anholt.net (8.13.4/8.13.1/Submit) id j8F6f2C4016400; Wed, 14 Sep 2005 23:41:02 -0700 (PDT) (envelope-from eta@lclark.edu) X-Authentication-Warning: leguin.anholt.net: anholt set sender to eta@lclark.edu using -f From: Eric Anholt To: Nikolay Kalev In-Reply-To: <4327F6FF.5080108@gmail.com> References: <4327F6FF.5080108@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-mkbriOW6Lf/bH7bPgFSO" Date: Wed, 14 Sep 2005 23:41:01 -0700 Message-Id: <1126766461.2312.25.camel@leguin> Mime-Version: 1.0 X-Mailer: Evolution 2.3.8 FreeBSD GNOME Team Port Cc: freebsd-current@freebsd.org Subject: Re: Xorg core dump ! FreeBSD 6.0 Beta4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2005 06:41:05 -0000 --=-mkbriOW6Lf/bH7bPgFSO Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2005-09-14 at 13:10 +0300, Nikolay Kalev wrote: > i get a core dump from X after update to freebsd 6.0 beta4 > here is the backtrace info : [snip] What version of X.Org is this? You didn't provide an Xorg.0.log, which is pretty necessary. Also, xorg-server-snap is really necessary to make a backtrace that's useful at all. --=20 Eric Anholt eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org --=-mkbriOW6Lf/bH7bPgFSO Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBDKRd9HUdvYGzw6vcRAqcZAKCEdE/H+68Xq1pMbNyMWlZMdTQHuQCfQT7u 6y8kgwg+u3xEhLABuOGSRsU= =mAWj -----END PGP SIGNATURE----- --=-mkbriOW6Lf/bH7bPgFSO-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 15 06:59:47 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A85416A41F for ; Thu, 15 Sep 2005 06:59:47 +0000 (GMT) (envelope-from nkalev@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8765543D45 for ; Thu, 15 Sep 2005 06:59:46 +0000 (GMT) (envelope-from nkalev@gmail.com) Received: by zproxy.gmail.com with SMTP id z31so177498nzd for ; Wed, 14 Sep 2005 23:59:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type; b=U/HRBPoPNi+933Ak9MNhhYtrEfsT6Rrq75XCZYpTIVrf0ixpju4HOX6VeGSYmKKr/70oj784ko7e515uL/TEkZDMbssR++to8/NMKou8YHPce0okSRsxwEM5WuoLfb2KQgTehMq0S5J1i7xqf0jqgUd8bVN6+TdPpsbs+RphQxs= Received: by 10.54.134.9 with SMTP id h9mr206931wrd; Wed, 14 Sep 2005 23:59:45 -0700 (PDT) Received: from ?172.16.101.106? ( [212.36.7.117]) by mx.gmail.com with ESMTP id g9sm535720wra.2005.09.14.23.59.34; Wed, 14 Sep 2005 23:59:45 -0700 (PDT) Message-ID: <43291D98.9080002@gmail.com> Date: Thu, 15 Sep 2005 10:07:04 +0300 From: Nikolay Kalev User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050722) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Anholt , freebsd-current@freebsd.org References: <4327F6FF.5080108@gmail.com> <1126766461.2312.25.camel@leguin> In-Reply-To: <1126766461.2312.25.camel@leguin> Content-Type: multipart/mixed; boundary="------------050504000909050902070705" Cc: Subject: Re: Xorg core dump ! FreeBSD 6.0 Beta4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2005 06:59:47 -0000 This is a multi-part message in MIME format. --------------050504000909050902070705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Eric Anholt wrote: >On Wed, 2005-09-14 at 13:10 +0300, Nikolay Kalev wrote: > > >>i get a core dump from X after update to freebsd 6.0 beta4 >>here is the backtrace info : >> >> > >[snip] > >What version of X.Org is this? You didn't provide an Xorg.0.log, which >is pretty necessary. Also, xorg-server-snap is really necessary to make >a backtrace that's useful at all. > > The version of my Xorg server is : xorg-server-6.8.2_3, but i think i don't have a log file because after i work few days the x server just coredumps. I'm realy not sure from where this problem is. I have a log from 9sep. but i;m not sure there is something important in it. --------------050504000909050902070705 Content-Type: text/plain; name="Xorg.0.log.old" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Xorg.0.log.old" X Window System Version 6.8.2 Release Date: 9 February 2005 X Protocol Version 11, Revision 0, Release 6.8.2 Build Operating System: FreeBSD 6.0 i386 [ELF] Current Operating System: FreeBSD lapi 6.0-BETA4 FreeBSD 6.0-BETA4 #0: Fri Sep 9 00:37:37 EEST 2005 root@lapi:/usr/obj/usr/src/sys/LAPI i386 Build Date: 17 July 2005 Before reporting problems, check http://wiki.X.Org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Wed Sep 14 20:50:01 2005 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "Simple Layout" (**) |-->Screen "Screen 1" (0) (**) | |-->Monitor "My Monitor" (**) | |-->Device "** Intel i810 (generic) [i810]" (**) |-->Input Device "Mouse1" (**) |-->Input Device "Keyboard1" (WW) `fonts.dir' not found (or not valid) in "/usr/X11R6/lib/X11/fonts/CID/". Entry deleted from font path. (Run 'mkfontdir' on "/usr/X11R6/lib/X11/fonts/CID/"). (WW) `fonts.dir' not found (or not valid) in "/usr/X11R6/lib/X11/fonts/local/". Entry deleted from font path. (Run 'mkfontdir' on "/usr/X11R6/lib/X11/fonts/local/"). (WW) `fonts.dir' not found (or not valid) in "/usr/X11R6/lib/X11/fonts/Speedo/". Entry deleted from font path. (Run 'mkfontdir' on "/usr/X11R6/lib/X11/fonts/Speedo/"). (WW) The directory "/usr/X11R6/lib/X11/fonts/TrueType/" does not exist. Entry deleted from font path. (WW) The directory "/usr/X11R6/lib/X11/fonts/freefont/" does not exist. Entry deleted from font path. (**) FontPath set to "/usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/TTF/,/usr/X11R6/lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/75dpi/,/usr/X11R6/lib/X11/fonts/100dpi/" (**) RgbPath set to "/usr/X11R6/lib/X11/rgb" (==) ModulePath set to "/usr/X11R6/lib/modules" (**) Extension "Composite" is enabled (II) Module ABI versions: X.Org ANSI C Emulation: 0.2 X.Org Video Driver: 0.7 X.Org XInput driver : 0.4 X.Org Server Extension : 0.2 X.Org Font Renderer : 0.4 (II) Loader running on freebsd (II) LoadModule: "bitmap" (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor="X.Org Foundation" compiled for 6.8.2, module version = 1.0.0 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.4 (II) Loading font Bitmap (II) LoadModule: "pcidata" (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor="X.Org Foundation" compiled for 6.8.2, module version = 1.0.0 ABI class: X.Org Video Driver, version 0.7 (--) Using syscons driver with X support (version 2.0) (--) using VT number 9 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x00000000, mode1Res1 = 0x80000000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,2560 card 144d,c008 rev 03 class 06,00,00 hdr 00 (II) PCI: 00:02:0: chip 8086,2562 card 144d,c008 rev 03 class 03,00,00 hdr 00 (II) PCI: 00:1d:0: chip 8086,24c2 card 144d,c008 rev 02 class 0c,03,00 hdr 80 (II) PCI: 00:1d:1: chip 8086,24c4 card 144d,c008 rev 02 class 0c,03,00 hdr 00 (II) PCI: 00:1d:2: chip 8086,24c7 card 144d,c008 rev 02 class 0c,03,00 hdr 00 (II) PCI: 00:1d:7: chip 8086,24cd card 144d,c008 rev 02 class 0c,03,20 hdr 00 (II) PCI: 00:1e:0: chip 8086,244e card 0000,0000 rev 82 class 06,04,00 hdr 01 (II) PCI: 00:1f:0: chip 8086,24c0 card 0000,0000 rev 02 class 06,01,00 hdr 80 (II) PCI: 00:1f:1: chip 8086,24cb card 144d,c008 rev 02 class 01,01,8a hdr 00 (II) PCI: 00:1f:3: chip 8086,24c3 card 144d,c008 rev 02 class 0c,05,00 hdr 00 (II) PCI: 00:1f:5: chip 8086,24c5 card 144d,c008 rev 02 class 04,01,00 hdr 00 (II) PCI: 00:1f:6: chip 8086,24c6 card 144d,2115 rev 02 class 07,03,00 hdr 00 (II) PCI: 02:03:0: chip 1180,0475 card fffc,ffff rev 80 class 06,07,00 hdr 02 (II) PCI: 02:08:0: chip 8086,1039 card 144d,c008 rev 82 class 02,00,00 hdr 00 (II) PCI: 02:0d:0: chip 104c,8023 card 144d,c008 rev 00 class 0c,00,10 hdr 00 (II) PCI: End of PCI scan (II) Host-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (0,0,3), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] (II) PCI-to-PCI bridge: (II) Bus 2: bridge is at (0:30:0), (0,2,3), BCTRL: 0x0004 (VGA_EN is cleared) (II) Bus 2 I/O range: [0] -1 0 0x00003000 - 0x000030ff (0x100) IX[B] [1] -1 0 0x00003400 - 0x000034ff (0x100) IX[B] [2] -1 0 0x00003800 - 0x000038ff (0x100) IX[B] [3] -1 0 0x00003c00 - 0x00003cff (0x100) IX[B] (II) Bus 2 non-prefetchable memory range: [0] -1 0 0xd0100000 - 0xd01fffff (0x100000) MX[B] (II) PCI-to-ISA bridge: (II) Bus -1: bridge is at (0:31:0), (0,-1,-1), BCTRL: 0x0008 (VGA_EN is set) (II) PCI-to-CardBus bridge: (II) Bus 3: bridge is at (2:3:0), (2,3,3), BCTRL: 0x0700 (VGA_EN is cleared) (--) PCI:*(0:2:0) Intel Corp. 82845G/GL [Brookdale-G] Chipset Integrated Graphics Device rev 3, Mem @ 0x88000000/27, 0x80000000/19 (II) Addressable bus resource ranges are [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] [1] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B] (II) OS-reported resource ranges: [0] -1 0 0xffe00000 - 0xffffffff (0x200000) MX[B](B) [1] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [5] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [6] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) PCI Memory resource overlap reduced 0xe0000000 from 0xffffffff to 0xdfffffff (II) Active PCI resource ranges: [0] -1 0 0xd0100000 - 0xd01fffff (0x100000) MX[B]E [1] -1 0 0xd0105000 - 0xd0105fff (0x1000) MX[B]E [2] -1 0 0xd0104000 - 0xd0107fff (0x4000) MX[B]E [3] -1 0 0xd0080800 - 0xd0080fff (0x800) MX[B]E [4] -1 0 0xd0080c00 - 0xd0080fff (0x400) MX[B]E [5] -1 0 0xd0080000 - 0xd00fffff (0x80000) MX[B]E [6] -1 0 0xe0000000 - 0xdfffffff (0x0) MX[B]EO [7] -1 0 0x80000000 - 0x8007ffff (0x80000) MX[B](B) [8] -1 0 0x88000000 - 0x8fffffff (0x8000000) MX[B](B) [9] -1 0 0x00003000 - 0x000030ff (0x100) IX[B]E [10] -1 0 0x00002000 - 0x000020ff (0x100) IX[B]E [11] -1 0 0x00002400 - 0x000024ff (0x100) IX[B]E [12] -1 0 0x000018c0 - 0x000018ff (0x40) IX[B]E [13] -1 0 0x00001c00 - 0x00001cff (0x100) IX[B]E [14] -1 0 0x00001100 - 0x000011ff (0x100) IX[B]E [15] -1 0 0x00001860 - 0x0000187f (0x20) IX[B]E [16] -1 0 0x00001840 - 0x0000187f (0x40) IX[B]E [17] -1 0 0x00001820 - 0x0000183f (0x20) IX[B]E [18] -1 0 0x00001800 - 0x000018ff (0x100) IX[B]E (II) PCI Memory resource overlap reduced 0xd0100000 from 0xd01fffff to 0xd0103fff (II) PCI Memory resource overlap reduced 0xd0104000 from 0xd0107fff to 0xd0104fff (II) PCI Memory resource overlap reduced 0xd0080800 from 0xd0080fff to 0xd0080bff (II) PCI Memory resource overlap reduced 0xd0080000 from 0xd00fffff to 0xd00807ff (II) PCI I/O resource overlap reduced 0x00001840 from 0x0000187f to 0x0000185f (II) PCI I/O resource overlap reduced 0x00001800 from 0x000018ff to 0x0000181f (II) Active PCI resource ranges after removing overlaps: [0] -1 0 0xd0100000 - 0xd0103fff (0x4000) MX[B]E [1] -1 0 0xd0105000 - 0xd0105fff (0x1000) MX[B]E [2] -1 0 0xd0104000 - 0xd0104fff (0x1000) MX[B]E [3] -1 0 0xd0080800 - 0xd0080bff (0x400) MX[B]E [4] -1 0 0xd0080c00 - 0xd0080fff (0x400) MX[B]E [5] -1 0 0xd0080000 - 0xd00807ff (0x800) MX[B]E [6] -1 0 0xe0000000 - 0xdfffffff (0x0) MX[B]EO [7] -1 0 0x80000000 - 0x8007ffff (0x80000) MX[B](B) [8] -1 0 0x88000000 - 0x8fffffff (0x8000000) MX[B](B) [9] -1 0 0x00003000 - 0x000030ff (0x100) IX[B]E [10] -1 0 0x00002000 - 0x000020ff (0x100) IX[B]E [11] -1 0 0x00002400 - 0x000024ff (0x100) IX[B]E [12] -1 0 0x000018c0 - 0x000018ff (0x40) IX[B]E [13] -1 0 0x00001c00 - 0x00001cff (0x100) IX[B]E [14] -1 0 0x00001100 - 0x000011ff (0x100) IX[B]E [15] -1 0 0x00001860 - 0x0000187f (0x20) IX[B]E [16] -1 0 0x00001840 - 0x0000185f (0x20) IX[B]E [17] -1 0 0x00001820 - 0x0000183f (0x20) IX[B]E [18] -1 0 0x00001800 - 0x0000181f (0x20) IX[B]E (II) OS-reported resource ranges after removing overlaps with PCI: [0] -1 0 0xffe00000 - 0xffffffff (0x200000) MX[B](B) [1] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [5] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [6] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) All system resource ranges: [0] -1 0 0xffe00000 - 0xffffffff (0x200000) MX[B](B) [1] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [5] -1 0 0xd0100000 - 0xd0103fff (0x4000) MX[B]E [6] -1 0 0xd0105000 - 0xd0105fff (0x1000) MX[B]E [7] -1 0 0xd0104000 - 0xd0104fff (0x1000) MX[B]E [8] -1 0 0xd0080800 - 0xd0080bff (0x400) MX[B]E [9] -1 0 0xd0080c00 - 0xd0080fff (0x400) MX[B]E [10] -1 0 0xd0080000 - 0xd00807ff (0x800) MX[B]E [11] -1 0 0xe0000000 - 0xdfffffff (0x0) MX[B]EO [12] -1 0 0x80000000 - 0x8007ffff (0x80000) MX[B](B) [13] -1 0 0x88000000 - 0x8fffffff (0x8000000) MX[B](B) [14] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [15] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [16] -1 0 0x00003000 - 0x000030ff (0x100) IX[B]E [17] -1 0 0x00002000 - 0x000020ff (0x100) IX[B]E [18] -1 0 0x00002400 - 0x000024ff (0x100) IX[B]E [19] -1 0 0x000018c0 - 0x000018ff (0x40) IX[B]E [20] -1 0 0x00001c00 - 0x00001cff (0x100) IX[B]E [21] -1 0 0x00001100 - 0x000011ff (0x100) IX[B]E [22] -1 0 0x00001860 - 0x0000187f (0x20) IX[B]E [23] -1 0 0x00001840 - 0x0000185f (0x20) IX[B]E [24] -1 0 0x00001820 - 0x0000183f (0x20) IX[B]E [25] -1 0 0x00001800 - 0x0000181f (0x20) IX[B]E (II) LoadModule: "dbe" (II) Loading /usr/X11R6/lib/modules/extensions/libdbe.a (II) Module dbe: vendor="X.Org Foundation" compiled for 6.8.2, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.2 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: "extmod" (II) Loading /usr/X11R6/lib/modules/extensions/libextmod.a (II) Module extmod: vendor="X.Org Foundation" compiled for 6.8.2, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.2 (II) Loading extension SHAPE (II) Loading extension MIT-SUNDRY-NONSTANDARD (II) Loading extension BIG-REQUESTS (II) Loading extension SYNC (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XC-MISC (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-Misc (II) Loading extension DPMS (II) Loading extension TOG-CUP (II) Loading extension Extended-Visual-Information (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: "type1" (II) Loading /usr/X11R6/lib/modules/fonts/libtype1.a (II) Module type1: vendor="X.Org Foundation" compiled for 6.8.2, module version = 1.0.2 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.4 (II) Loading font Type1 (II) Loading font CID (II) LoadModule: "freetype" (II) Loading /usr/X11R6/lib/modules/fonts/libfreetype.so (II) Module freetype: vendor="X.Org Foundation & the After X-TT Project" compiled for 6.8.2, module version = 2.1.0 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.4 (II) Loading font FreeType (II) LoadModule: "glx" (II) Loading /usr/X11R6/lib/modules/extensions/libglx.a (II) Module glx: vendor="X.Org Foundation" compiled for 6.8.2, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.2 (II) Loading sub module "GLcore" (II) LoadModule: "GLcore" (II) Loading /usr/X11R6/lib/modules/extensions/libGLcore.a (II) Module GLcore: vendor="X.Org Foundation" compiled for 6.8.2, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.2 (II) Loading extension GLX (II) LoadModule: "dri" (II) Loading /usr/X11R6/lib/modules/extensions/libdri.a (II) Module dri: vendor="X.Org Foundation" compiled for 6.8.2, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.2 (II) Loading sub module "drm" (II) LoadModule: "drm" (II) Loading /usr/X11R6/lib/modules/freebsd/libdrm.a (II) Module drm: vendor="X.Org Foundation" compiled for 6.8.2, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.2 (II) Loading extension XFree86-DRI (II) LoadModule: "i810" (II) Loading /usr/X11R6/lib/modules/drivers/i810_drv.o (II) Module i810: vendor="X.Org Foundation" compiled for 6.8.2, module version = 1.3.0 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 0.7 (II) LoadModule: "mouse" (II) Loading /usr/X11R6/lib/modules/input/mouse_drv.o (II) Module mouse: vendor="X.Org Foundation" compiled for 6.8.2, module version = 1.0.0 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 0.4 (II) LoadModule: "kbd" (II) Loading /usr/X11R6/lib/modules/input/kbd_drv.o (II) Module kbd: vendor="X.Org Foundation" compiled for 6.8.2, module version = 1.0.0 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 0.4 (II) I810: Driver for Intel Integrated Graphics Chipsets: i810, i810-dc100, i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G (II) Primary Device is: PCI 00:02:0 (--) Assigning device section with no busID to primary device (--) Chipset 845G found (II) resource ranges after xf86ClaimFixedResources() call: [0] -1 0 0xffe00000 - 0xffffffff (0x200000) MX[B](B) [1] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [5] -1 0 0xd0100000 - 0xd0103fff (0x4000) MX[B]E [6] -1 0 0xd0105000 - 0xd0105fff (0x1000) MX[B]E [7] -1 0 0xd0104000 - 0xd0104fff (0x1000) MX[B]E [8] -1 0 0xd0080800 - 0xd0080bff (0x400) MX[B]E [9] -1 0 0xd0080c00 - 0xd0080fff (0x400) MX[B]E [10] -1 0 0xd0080000 - 0xd00807ff (0x800) MX[B]E [11] -1 0 0xe0000000 - 0xdfffffff (0x0) MX[B]EO [12] -1 0 0x80000000 - 0x8007ffff (0x80000) MX[B](B) [13] -1 0 0x88000000 - 0x8fffffff (0x8000000) MX[B](B) [14] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [15] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [16] -1 0 0x00003000 - 0x000030ff (0x100) IX[B]E [17] -1 0 0x00002000 - 0x000020ff (0x100) IX[B]E [18] -1 0 0x00002400 - 0x000024ff (0x100) IX[B]E [19] -1 0 0x000018c0 - 0x000018ff (0x40) IX[B]E [20] -1 0 0x00001c00 - 0x00001cff (0x100) IX[B]E [21] -1 0 0x00001100 - 0x000011ff (0x100) IX[B]E [22] -1 0 0x00001860 - 0x0000187f (0x20) IX[B]E [23] -1 0 0x00001840 - 0x0000185f (0x20) IX[B]E [24] -1 0 0x00001820 - 0x0000183f (0x20) IX[B]E [25] -1 0 0x00001800 - 0x0000181f (0x20) IX[B]E (II) resource ranges after probing: [0] -1 0 0xffe00000 - 0xffffffff (0x200000) MX[B](B) [1] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [5] -1 0 0xd0100000 - 0xd0103fff (0x4000) MX[B]E [6] -1 0 0xd0105000 - 0xd0105fff (0x1000) MX[B]E [7] -1 0 0xd0104000 - 0xd0104fff (0x1000) MX[B]E [8] -1 0 0xd0080800 - 0xd0080bff (0x400) MX[B]E [9] -1 0 0xd0080c00 - 0xd0080fff (0x400) MX[B]E [10] -1 0 0xd0080000 - 0xd00807ff (0x800) MX[B]E [11] -1 0 0xe0000000 - 0xdfffffff (0x0) MX[B]EO [12] -1 0 0x80000000 - 0x8007ffff (0x80000) MX[B](B) [13] -1 0 0x88000000 - 0x8fffffff (0x8000000) MX[B](B) [14] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B] [15] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] [16] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B] [17] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [18] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [19] -1 0 0x00003000 - 0x000030ff (0x100) IX[B]E [20] -1 0 0x00002000 - 0x000020ff (0x100) IX[B]E [21] -1 0 0x00002400 - 0x000024ff (0x100) IX[B]E [22] -1 0 0x000018c0 - 0x000018ff (0x40) IX[B]E [23] -1 0 0x00001c00 - 0x00001cff (0x100) IX[B]E [24] -1 0 0x00001100 - 0x000011ff (0x100) IX[B]E [25] -1 0 0x00001860 - 0x0000187f (0x20) IX[B]E [26] -1 0 0x00001840 - 0x0000185f (0x20) IX[B]E [27] -1 0 0x00001820 - 0x0000183f (0x20) IX[B]E [28] -1 0 0x00001800 - 0x0000181f (0x20) IX[B]E [29] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B] [30] 0 0 0x000003c0 - 0x000003df (0x20) IS[B] (II) Setting vga for screen 0. (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Loading /usr/X11R6/lib/modules/libint10.a (II) Module int10: vendor="X.Org Foundation" compiled for 6.8.2, module version = 1.0.0 ABI class: X.Org Video Driver, version 0.7 (II) Loading sub module "vbe" (II) LoadModule: "vbe" (II) Loading /usr/X11R6/lib/modules/libvbe.a (II) Module vbe: vendor="X.Org Foundation" compiled for 6.8.2, module version = 1.1.0 ABI class: X.Org Video Driver, version 0.7 (II) Loading sub module "vgahw" (II) LoadModule: "vgahw" (II) Loading /usr/X11R6/lib/modules/libvgahw.a (II) Module vgahw: vendor="X.Org Foundation" compiled for 6.8.2, module version = 0.1.0 ABI class: X.Org Video Driver, version 0.7 (**) I810(0): Depth 24, (--) framebuffer bpp 32 (==) I810(0): RGB weight 888 (==) I810(0): Default visual is TrueColor (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Reloading /usr/X11R6/lib/modules/libint10.a (II) I810(0): initializing int10 (==) I810(0): Write-combining range (0xa0000,0x20000) was already clear (==) I810(0): Write-combining range (0xc0000,0x40000) was already clear (II) I810(0): Primary V_BIOS segment is: 0xc000 (==) I810(0): Write-combining range (0x0,0x1000) was already clear (II) I810(0): VESA BIOS detected (II) I810(0): VESA VBE Version 3.0 (II) I810(0): VESA VBE Total Mem: 8000 kB (II) I810(0): VESA VBE OEM: Intel(r)845G/845GL/845GE/845GV Graphics Chip Accelerated VGA BIOS (II) I810(0): VESA VBE OEM Software Rev: 1.0 (II) I810(0): VESA VBE OEM Vendor: Intel Corporation (II) I810(0): VESA VBE OEM Product: Intel(r)845G/845GL/845GE/845GV Graphics Controller (II) I810(0): VESA VBE OEM Product Rev: Hardware Version 0.0 (II) I810(0): Integrated Graphics Chipset: Intel(R) 845G (--) I810(0): Chipset: "845G" (--) I810(0): Linear framebuffer at 0x88000000 (--) I810(0): IO registers at addr 0x80000000 (==) I810(0): Write-combining range (0x80000000,0x80000) was already clear (II) I810(0): 1 display pipe available. (II) I810(0): detected 8060 kB stolen memory. (EE) GARTInit: Unable to open /dev/agpgart (No such file or directory) (WW) I810(0): /dev/agpgart is either not available, or no memory is available for allocation. Using pre-allocated memory only. (WW) I810(0): VideoRAM reduced to 8060 kByte (limited to available sysmem) (--) I810(0): Pre-allocated VideoRAM: 8060 kByte (--) I810(0): VideoRAM: 8060 kByte (==) I810(0): video overlay key set to 0x101fe (**) I810(0): page flipping disabled (==) I810(0): Using gamma correction (1.0, 1.0, 1.0) (II) I810(0): BIOS Build: 2882 (==) I810(0): Device Presence: disabled. (==) I810(0): Display Info: enabled. (II) I810(0): Broken BIOSes cause the system to hang here. If you encounter this problem please add Option "DisplayInfo" "FALSE" to the Device section of your XF86Config file. (II) I810(0): Display Info: CRT: attached: FALSE, present: FALSE, size: (0,0) (II) I810(0): Display Info: TV: attached: FALSE, present: FALSE, size: (0,0) (II) I810(0): Display Info: DFP (digital flat panel): attached: FALSE, present: FALSE, size: (0,0) (II) I810(0): Display Info: LFP (local flat panel): attached: FALSE, present: FALSE, size: (0,0) (II) I810(0): Display Info: CRT2 (second CRT): attached: FALSE, present: FALSE, size: (0,0) (II) I810(0): Display Info: TV2 (second TV): attached: FALSE, present: FALSE, size: (0,0) (II) I810(0): Currently active displays on Pipe A: (II) I810(0): LFP (local flat panel) (II) I810(0): No display size information available for pipe A. (==) I810(0): Display is using Pipe A (--) I810(0): Maximum frambuffer space: 7892 kByte (II) Loading sub module "ddc" (II) LoadModule: "ddc" (II) Loading /usr/X11R6/lib/modules/libddc.a (II) Module ddc: vendor="X.Org Foundation" compiled for 6.8.2, module version = 1.0.0 ABI class: X.Org Video Driver, version 0.7 (II) I810(0): VESA VBE DDC supported (II) I810(0): VESA VBE DDC Level none (II) I810(0): VESA VBE DDC transfer in appr. 0 sec. (II) I810(0): VESA VBE DDC read failed (--) I810(0): A non-CRT device is attached to pipe A. No refresh rate overrides will be attempted. (--) I810(0): Maximum space available for video modes: 7892 kByte Mode: 20 (132x25) ModeAttributes: 0xf WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005c81 BytesPerScanline: 594 XResolution: 132 YResolution: 25 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 4 NumberOfBanks: 1 MemoryModel: 0 BankSize: 0 NumberOfImages: 0 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0x0 LinBytesPerScanLine: 0 BnkNumberOfImagePages: 0 LinNumberOfImagePages: 0 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 0 Mode: 21 (132x43) ModeAttributes: 0xf WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005c81 BytesPerScanline: 594 XResolution: 132 YResolution: 43 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 4 NumberOfBanks: 1 MemoryModel: 0 BankSize: 0 NumberOfImages: 0 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0x0 LinBytesPerScanLine: 0 BnkNumberOfImagePages: 0 LinNumberOfImagePages: 0 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 0 Mode: 22 (132x50) ModeAttributes: 0xf WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005c81 BytesPerScanline: 594 XResolution: 132 YResolution: 50 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 4 NumberOfBanks: 1 MemoryModel: 0 BankSize: 0 NumberOfImages: 0 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0x0 LinBytesPerScanLine: 0 BnkNumberOfImagePages: 0 LinNumberOfImagePages: 0 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 0 Mode: 23 (132x60) ModeAttributes: 0xf WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005c81 BytesPerScanline: 594 XResolution: 132 YResolution: 60 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 4 NumberOfBanks: 1 MemoryModel: 0 BankSize: 0 NumberOfImages: 0 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0x0 LinBytesPerScanLine: 0 BnkNumberOfImagePages: 0 LinNumberOfImagePages: 0 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 0 Mode: 30 (640x480) ModeAttributes: 0x9b WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005c81 BytesPerScanline: 640 XResolution: 640 YResolution: 480 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 24 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0x88000000 LinBytesPerScanLine: 640 BnkNumberOfImagePages: 24 LinNumberOfImagePages: 24 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 230000000 Mode: 32 (800x600) ModeAttributes: 0x9b WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005c81 BytesPerScanline: 800 XResolution: 800 YResolution: 600 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 16 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0x88000000 LinBytesPerScanLine: 800 BnkNumberOfImagePages: 16 LinNumberOfImagePages: 16 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 230000000 Mode: 34 (1024x768) ModeAttributes: 0x9b WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005c81 BytesPerScanline: 1024 XResolution: 1024 YResolution: 768 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 9 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0x88000000 LinBytesPerScanLine: 1024 BnkNumberOfImagePages: 9 LinNumberOfImagePages: 9 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 230000000 Mode: 38 (1280x1024) ModeAttributes: 0x9a WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005c81 BytesPerScanline: 1280 XResolution: 1280 YResolution: 1024 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 5 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0x88000000 LinBytesPerScanLine: 1280 BnkNumberOfImagePages: 5 LinNumberOfImagePages: 5 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 230000000 Mode: 3a (1600x1200) ModeAttributes: 0x9a WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005c81 BytesPerScanline: 1600 XResolution: 1600 YResolution: 1200 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 3 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0x88000000 LinBytesPerScanLine: 1600 BnkNumberOfImagePages: 3 LinNumberOfImagePages: 3 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 230000000 Mode: 3c (1920x1440) ModeAttributes: 0x9a WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005c81 BytesPerScanline: 1920 XResolution: 1920 YResolution: 1440 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 1 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0x88000000 LinBytesPerScanLine: 1920 BnkNumberOfImagePages: 1 LinNumberOfImagePages: 1 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 230000000 Mode: 41 (640x480) ModeAttributes: 0x9b WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005c81 BytesPerScanline: 1280 XResolution: 640 YResolution: 480 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 12 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0x88000000 LinBytesPerScanLine: 1280 BnkNumberOfImagePages: 12 LinNumberOfImagePages: 12 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 230000000 Mode: 43 (800x600) ModeAttributes: 0x9b WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005c81 BytesPerScanline: 1600 XResolution: 800 YResolution: 600 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 7 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0x88000000 LinBytesPerScanLine: 1600 BnkNumberOfImagePages: 7 LinNumberOfImagePages: 7 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 230000000 Mode: 45 (1024x768) ModeAttributes: 0x9b WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005c81 BytesPerScanline: 2048 XResolution: 1024 YResolution: 768 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 4 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0x88000000 LinBytesPerScanLine: 2048 BnkNumberOfImagePages: 4 LinNumberOfImagePages: 4 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 230000000 Mode: 49 (1280x1024) ModeAttributes: 0x9a WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005c81 BytesPerScanline: 2560 XResolution: 1280 YResolution: 1024 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 2 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0x88000000 LinBytesPerScanLine: 2560 BnkNumberOfImagePages: 2 LinNumberOfImagePages: 2 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 230000000 Mode: 4b (1600x1200) ModeAttributes: 0x9a WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005c81 BytesPerScanline: 3200 XResolution: 1600 YResolution: 1200 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 1 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0x88000000 LinBytesPerScanLine: 3200 BnkNumberOfImagePages: 1 LinNumberOfImagePages: 1 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 230000000 Mode: 4d (1920x1440) ModeAttributes: 0x9a WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005c81 BytesPerScanline: 3840 XResolution: 1920 YResolution: 1440 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 0 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0x88000000 LinBytesPerScanLine: 3840 BnkNumberOfImagePages: 0 LinNumberOfImagePages: 0 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 230000000 *Mode: 50 (640x480) ModeAttributes: 0x9b WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005c81 BytesPerScanline: 2560 XResolution: 640 YResolution: 480 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 5 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 8 RsvdFieldPosition: 24 DirectColorModeInfo: 0 PhysBasePtr: 0x88000000 LinBytesPerScanLine: 2560 BnkNumberOfImagePages: 5 LinNumberOfImagePages: 5 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 8 LinRsvdFieldPosition: 24 MaxPixelClock: 230000000 *Mode: 52 (800x600) ModeAttributes: 0x9b WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005c81 BytesPerScanline: 3200 XResolution: 800 YResolution: 600 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 3 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 8 RsvdFieldPosition: 24 DirectColorModeInfo: 0 PhysBasePtr: 0x88000000 LinBytesPerScanLine: 3200 BnkNumberOfImagePages: 3 LinNumberOfImagePages: 3 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 8 LinRsvdFieldPosition: 24 MaxPixelClock: 230000000 *Mode: 54 (1024x768) ModeAttributes: 0x9b WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005c81 BytesPerScanline: 4096 XResolution: 1024 YResolution: 768 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 1 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 8 RsvdFieldPosition: 24 DirectColorModeInfo: 0 PhysBasePtr: 0x88000000 LinBytesPerScanLine: 4096 BnkNumberOfImagePages: 1 LinNumberOfImagePages: 1 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 8 LinRsvdFieldPosition: 24 MaxPixelClock: 230000000 Mode: 58 (1280x1024) ModeAttributes: 0x9a WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005c81 BytesPerScanline: 5120 XResolution: 1280 YResolution: 1024 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 0 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 8 RsvdFieldPosition: 24 DirectColorModeInfo: 0 PhysBasePtr: 0x88000000 LinBytesPerScanLine: 5120 BnkNumberOfImagePages: 0 LinNumberOfImagePages: 0 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 8 LinRsvdFieldPosition: 24 MaxPixelClock: 230000000 Mode: 5a (1600x1200) ModeAttributes: 0x9a WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005c81 BytesPerScanline: 6400 XResolution: 1600 YResolution: 1200 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 0 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 8 RsvdFieldPosition: 24 DirectColorModeInfo: 0 PhysBasePtr: 0x88000000 LinBytesPerScanLine: 6400 BnkNumberOfImagePages: 0 LinNumberOfImagePages: 0 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 8 LinRsvdFieldPosition: 24 MaxPixelClock: 230000000 Mode: 5c (1920x1440) ModeAttributes: 0x9a WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005c81 BytesPerScanline: 7680 XResolution: 1920 YResolution: 1440 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 0 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 8 RsvdFieldPosition: 24 DirectColorModeInfo: 0 PhysBasePtr: 0x88000000 LinBytesPerScanLine: 7680 BnkNumberOfImagePages: 0 LinNumberOfImagePages: 0 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 8 LinRsvdFieldPosition: 24 MaxPixelClock: 230000000 (II) I810(0): My Monitor: Using hsync range of 31.00-95.00 kHz (II) I810(0): My Monitor: Using vrefresh range of 40.00-150.00 Hz (II) I810(0): Not using mode "1280x1024" (no mode of this name) (II) I810(0): 11556 kBytes additional video memory is required to enable tiling mode for DRI. (II) I810(0): 4476 kBytes additional video memory is required to enable DRI. (II) I810(0): Disabling DRI. (--) I810(0): Virtual size is 1024x768 (pitch 1024) (**) I810(0): Built-in mode "1024x768" (**) I810(0): Built-in mode "800x600" (**) I810(0): Built-in mode "640x480" (==) I810(0): DPI set to (75, 75) (II) Loading sub module "fb" (II) LoadModule: "fb" (II) Loading /usr/X11R6/lib/modules/libfb.a (II) Module fb: vendor="X.Org Foundation" compiled for 6.8.2, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.2 (II) Loading sub module "xaa" (II) LoadModule: "xaa" (II) Loading /usr/X11R6/lib/modules/libxaa.a (II) Module xaa: vendor="X.Org Foundation" compiled for 6.8.2, module version = 1.2.0 ABI class: X.Org Video Driver, version 0.7 (II) Loading sub module "ramdac" (II) LoadModule: "ramdac" (II) Loading /usr/X11R6/lib/modules/libramdac.a (II) Module ramdac: vendor="X.Org Foundation" compiled for 6.8.2, module version = 0.1.0 ABI class: X.Org Video Driver, version 0.7 (==) I810(0): Write-combining range (0x0,0x1000) was already clear (==) I810(0): VBE Restore workaround: enabled. (==) Depth 24 pixmap format is 32 bpp (II) do I need RAC? No, I don't. (II) resource ranges after preInit: [0] 0 0 0x80000000 - 0x8007ffff (0x80000) MS[B] [1] 0 0 0x88000000 - 0x8fffffff (0x8000000) MS[B] [2] -1 0 0xffe00000 - 0xffffffff (0x200000) MX[B](B) [3] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [4] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [5] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [6] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [7] -1 0 0xd0100000 - 0xd0103fff (0x4000) MX[B]E [8] -1 0 0xd0105000 - 0xd0105fff (0x1000) MX[B]E [9] -1 0 0xd0104000 - 0xd0104fff (0x1000) MX[B]E [10] -1 0 0xd0080800 - 0xd0080bff (0x400) MX[B]E [11] -1 0 0xd0080c00 - 0xd0080fff (0x400) MX[B]E [12] -1 0 0xd0080000 - 0xd00807ff (0x800) MX[B]E [13] -1 0 0xe0000000 - 0xdfffffff (0x0) MX[B]EO [14] -1 0 0x80000000 - 0x8007ffff (0x80000) MX[B](B) [15] -1 0 0x88000000 - 0x8fffffff (0x8000000) MX[B](B) [16] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B](OprD) [17] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B](OprD) [18] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B](OprD) [19] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [20] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [21] -1 0 0x00003000 - 0x000030ff (0x100) IX[B]E [22] -1 0 0x00002000 - 0x000020ff (0x100) IX[B]E [23] -1 0 0x00002400 - 0x000024ff (0x100) IX[B]E [24] -1 0 0x000018c0 - 0x000018ff (0x40) IX[B]E [25] -1 0 0x00001c00 - 0x00001cff (0x100) IX[B]E [26] -1 0 0x00001100 - 0x000011ff (0x100) IX[B]E [27] -1 0 0x00001860 - 0x0000187f (0x20) IX[B]E [28] -1 0 0x00001840 - 0x0000185f (0x20) IX[B]E [29] -1 0 0x00001820 - 0x0000183f (0x20) IX[B]E [30] -1 0 0x00001800 - 0x0000181f (0x20) IX[B]E [31] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B](OprU) [32] 0 0 0x000003c0 - 0x000003df (0x20) IS[B](OprU) (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Reloading /usr/X11R6/lib/modules/libint10.a (II) I810(0): initializing int10 (==) I810(0): Write-combining range (0xa0000,0x20000) was already clear (II) I810(0): Primary V_BIOS segment is: 0xc000 (==) I810(0): Write-combining range (0x0,0x1000) was already clear (II) I810(0): VESA BIOS detected (II) I810(0): VESA VBE Version 3.0 (II) I810(0): VESA VBE Total Mem: 8000 kB (II) I810(0): VESA VBE OEM: Intel(r)845G/845GL/845GE/845GV Graphics Chip Accelerated VGA BIOS (II) I810(0): VESA VBE OEM Software Rev: 1.0 (II) I810(0): VESA VBE OEM Vendor: Intel Corporation (II) I810(0): VESA VBE OEM Product: Intel(r)845G/845GL/845GE/845GV Graphics Controller (II) I810(0): VESA VBE OEM Product Rev: Hardware Version 0.0 (==) I810(0): Default visual is TrueColor (--) I810(0): Xv is disabled because it needs 2D accel and AGPGART. (II) I810(0): Allocated 128 kB for the ring buffer at 0x0 (II) I810(0): Allocating at least 512 scanlines for pixmap cache (II) I810(0): Initial framebuffer allocation size: 5120 kByte (II) I810(0): Allocated 4 kB for HW cursor at 0xfffff000 (II) I810(0): Allocated 16 kB for HW (ARGB) cursor at 0xffffb000 (II) I810(0): Allocated 64 kB for the scratch buffer at 0xfffeb000 (II) I810(0): Updated framebuffer allocation size from 5120 to 7848 kByte (II) I810(0): Updated pixmap cache from 512 scanlines to 1194 scanlines (II) I810(0): 0x8736920: Memory at offset 0x00020000, size 7848 kBytes (II) I810(0): 0x872fb60: Memory at offset 0x007de000, size 4 kBytes (II) I810(0): 0x872fb80: Memory at offset 0x007da000, size 16 kBytes (II) I810(0): 0x8828384: Memory at offset 0x00000000, size 128 kBytes (II) I810(0): 0x8736960: Memory at offset 0x007ca000, size 64 kBytes (==) I810(0): Write-combining range (0x80000000,0x80000) was already clear (==) I810(0): Write-combining range (0x88000000,0x8000000) (II) I810(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000 (==) I810(0): Write-combining range (0xa0000,0x10000) was already clear (II) I810(0): Display plane A is enabled and connected to Pipe A. (II) I810(0): Enabling plane A. (II) I810(0): Display plane A is now enabled and connected to Pipe A. (II) I810(0): PIPEACONF is 0x80000000 (II) I810(0): Mode bandwidth is 47 Mpixel/s (II) I810(0): maxBandwidth is 1152 Mbyte/s, pipe bandwidths are 252 Mbyte/s, 0 Mbyte/s (WW) I810(0): Extended BIOS function 0x5f61 not supported. (II) I810(0): Using XFree86 Acceleration Architecture (XAA) Screen to screen bit blits Solid filled rectangles 8x8 mono pattern filled rectangles Indirect CPU to Screen color expansion Solid Horizontal and Vertical Lines Offscreen Pixmaps Setting up tile and stipple cache: 32 128x128 slots 10 256x256 slots (==) I810(0): Backing store disabled (==) I810(0): Silken mouse enabled (II) I810(0): Initializing HW Cursor (II) I810(0): direct rendering: Disabled (==) RandR enabled (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension XC-APPGROUP (II) Initializing built-in extension SECURITY (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFIXES (II) Initializing built-in extension XFree86-Bigfont (II) Initializing built-in extension RENDER (II) Initializing built-in extension RANDR (II) Initializing built-in extension COMPOSITE (II) Initializing built-in extension DAMAGE (II) Initializing built-in extension XEVIE (**) Option "Protocol" "SysMouse" (**) Mouse1: Device: "/dev/sysmouse" (**) Mouse1: Protocol: "SysMouse" (**) Option "CorePointer" (**) Mouse1: Core Pointer (**) Option "Device" "/dev/sysmouse" (**) Option "BaudRate" "1200" (**) Option "StopBits" "2" (**) Option "DataBits" "8" (**) Option "Parity" "None" (**) Option "Vmin" "1" (**) Option "Vtime" "0" (**) Option "FlowControl" "None" (==) Mouse1: Emulate3Buttons, Emulate3Timeout: 50 (**) Option "ZAxisMapping" "4 5" (**) Mouse1: ZAxisMapping: buttons 4 and 5 (**) Mouse1: Buttons: 5 (**) Mouse1: BaudRate: 1200 (**) Option "CoreKeyboard" (**) Keyboard1: Core Keyboard (**) Option "Protocol" "standard" (**) Keyboard1: Protocol: standard (**) Option "AutoRepeat" "500 30" (**) Option "XkbRules" "xorg" (**) Keyboard1: XkbRules: "xorg" (**) Option "XkbModel" "pc105" (**) Keyboard1: XkbModel: "pc105" (**) Option "XkbLayout" "us,bg" (**) Keyboard1: XkbLayout: "us,bg" (**) Option "XkbVariant" ",phonetic" (**) Keyboard1: XkbVariant: ",phonetic" (**) Option "XkbOptions" "grp:alt_shift_toggle,grp_led:scroll" (**) Keyboard1: XkbOptions: "grp:alt_shift_toggle,grp_led:scroll" (**) Option "CustomKeycodes" "off" (**) Keyboard1: CustomKeycodes disabled (II) XINPUT: Adding extended input device "Keyboard1" (type: KEYBOARD) (II) XINPUT: Adding extended input device "Mouse1" (type: MOUSE) (II) 3rd Button detected: disabling emulate3Button (WW) I810(0): Setting the original video mode instead of restoring the saved state (WW) I810(0): Successfully set original devices --------------050504000909050902070705-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 15 07:15:56 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6CF6716A41F for ; Thu, 15 Sep 2005 07:15:56 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB54643D45 for ; Thu, 15 Sep 2005 07:15:55 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by xproxy.gmail.com with SMTP id i31so18103wxd for ; Thu, 15 Sep 2005 00:15:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZbxQhVDMSc1k7ipgZ89oAig+qNds7xYuS5tbkfEnofV5DGDJGkojVSMS/wE8Qy+J7SMg2a1teLU7OKzKYM/nM/tZwyprgtBs3FNJ+iU2aaStdrdlWig2aLI1whID7PKKXYyKd/MFPY2te8997kDozdYhg8Ry4XrsbDXvb4TrNog= Received: by 10.70.28.2 with SMTP id b2mr187847wxb; Thu, 15 Sep 2005 00:15:55 -0700 (PDT) Received: by 10.70.115.15 with HTTP; Thu, 15 Sep 2005 00:15:55 -0700 (PDT) Message-ID: <84dead7205091500152a7c25d1@mail.gmail.com> Date: Thu, 15 Sep 2005 12:45:55 +0530 From: Joseph Koshy To: Oliver Lehmann In-Reply-To: <20050915000053.448f251b.lehmann@ans-netz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050914194612.15692485.lehmann@ans-netz.de> <43286E37.40203@samsco.org> <20050914222013.178dc4dc.lehmann@ans-netz.de> <84dead72050914135239514c49@mail.gmail.com> <20050915000053.448f251b.lehmann@ans-netz.de> Cc: current@freebsd.org Subject: Re: low(er) disk performance with sched_4bsd then with sched_ule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: joseph.koshy@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2005 07:15:56 -0000 ol> I did this now for bs=3D64k count=3D32000. The results are here:=20 ol> http://pofo.de/tmp/gprof.ule ol> http://pofo.de/tmp/gprof.4bsd The top consumer for the 4BSD kernel appears to be is: 70.8 187656.00 187656.00 _mtx_lock_sleep [1] The low rank of the turnstile_* functions in the profile makes me suspect that the spinning is happening in the following part of the code: "src/sys/kern/kern_mutex.c": 512 /* 513 * If the current owner of the lock is executing on another 514 * CPU, spin instead of blocking. 515 */ 516 owner =3D (struct thread *)(v & MTX_FLAGMASK); 517 #ifdef ADAPTIVE_GIANT 518 if (TD_IS_RUNNING(owner)) { 519 #else 520 if (m !=3D &Giant && TD_IS_RUNNING(owner)) { 521 #endif 522 turnstile_release(&m->mtx_object); 523 while (mtx_owner(m) =3D=3D owner && \ TD_IS_RUNNING(owner)){ 524 cpu_spinwait(); 525 } 526 continue; So the next question would be: do you have ADAPTIVE_GIANT turned on in your kernel config? What happens if you use a kernel with 'options NO_ADAPTIVE_MUTEXES' ? [Could you please post your kernel config, and the output of a dmesg after a boot]. --=20 FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-current@FreeBSD.ORG Thu Sep 15 07:40:40 2005 Return-Path: X-Original-To: Freebsd-current@FreeBSD.org Delivered-To: Freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E91F16A41F for ; Thu, 15 Sep 2005 07:40:40 +0000 (GMT) (envelope-from sos@FreeBSD.org) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3DF0543D72 for ; Thu, 15 Sep 2005 07:40:29 +0000 (GMT) (envelope-from sos@FreeBSD.org) Received: from [194.192.25.136] (mac.deepcore.dk [194.192.25.136]) by spider.deepcore.dk (8.13.4/8.13.3) with ESMTP id j8F7f4Sm001097; Thu, 15 Sep 2005 09:41:04 +0200 (CEST) (envelope-from sos@FreeBSD.org) In-Reply-To: <4328D0F7.2090501@fastmail.fm> References: <1126047871.687.1.camel@localhost> <4328D0F7.2090501@fastmail.fm> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <2B22BF98-3FF4-4BE5-B8FF-56BB07CDB4D9@FreeBSD.org> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= Date: Thu, 15 Sep 2005 09:40:21 +0200 To: Patrick Bowen X-Mailer: Apple Mail (2.734) X-mail-scanned: by DeepCore Virus & Spam killer v1.12 Cc: Freebsd-current@FreeBSD.org Subject: Re: ATA error on 6.0-BETA4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2005 07:40:40 -0000 On 15/09/2005, at 3:40, Patrick Bowen wrote: > I've notice the same behaviour on my Dell C600. I've attached =20 > verbose dmesg's for -current and 5.4. When I boot 5.4 the CD-RW is =20 > found and I have no problems using it for either reading or =20 > writing. I hope they're useful for you. OK, please try the below patch and let me know if that helps any. > I'd like to say that I have the greatest respect for *all* of you =20 > that work at making FreeBSD the great OS that it is. I just wonder =20 > where you find the time to work on it, what with your day jobs, =20 > family responsibilities and all... I guess we have understanding environments and need for less sleep =20 than usual :) Index: ata-lowlevel.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/sys/dev/ata/ata-lowlevel.c,v retrieving revision 1.71 diff -u -r1.71 ata-lowlevel.c --- ata-lowlevel.c 14 Sep 2005 12:45:06 -0000 1.71 +++ ata-lowlevel.c 15 Sep 2005 07:35:41 -0000 @@ -278,7 +278,7 @@ /* if read data get it */ if (request->flags & ATA_R_READ) { - if (ata_wait(ch, atadev, (ATA_S_READY | ATA_S_DRQ)) < =20= 0) { + if (ata_wait(ch, atadev, ATA_S_DRQ) < 0) { device_printf(request->dev, "timeout waiting for read DRQ\n"); request->result =3D EIO; S=F8ren Schmidt sos@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Sep 15 07:58:31 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 79C5316A420 for ; Thu, 15 Sep 2005 07:58:31 +0000 (GMT) (envelope-from MH@kernel32.de) Received: from crivens.unixoid.de (crivens.unixoid.de [81.169.171.191]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5C4943D48 for ; Thu, 15 Sep 2005 07:58:30 +0000 (GMT) (envelope-from MH@kernel32.de) Received: from localhost (localhost [127.0.0.1]) by crivens.unixoid.de (Postfix) with ESMTP id 3968A3FD4; Thu, 15 Sep 2005 09:58:29 +0200 (CEST) Received: from crivens.unixoid.de ([127.0.0.1]) by localhost (crivens.unixoid.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87656-18; Thu, 15 Sep 2005 09:58:23 +0200 (CEST) Received: from [10.38.0.8] (unknown [212.12.51.89]) by crivens.unixoid.de (Postfix) with ESMTP id CAF073FD0; Thu, 15 Sep 2005 09:58:23 +0200 (CEST) Message-ID: <432929A4.5020607@kernel32.de> Date: Thu, 15 Sep 2005 09:58:28 +0200 From: Marian Hettwer User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nikolay Kalev References: <4327F6FF.5080108@gmail.com> In-Reply-To: <4327F6FF.5080108@gmail.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at unixoid.de Cc: freebsd-current@freebsd.org Subject: Re: Xorg core dump ! FreeBSD 6.0 Beta4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2005 07:58:31 -0000 Hi, Nikolay Kalev wrote: > i get a core dump from X after update to freebsd 6.0 beta4 > here is the backtrace info : Just a quick guess, since you updated to 6.0-BETA4... did you recompiled your ports ? Somewhere around BETA3 (or was it BETA2) it was necessary to recompile all ports, due to a update of shared libraries of the base system... snip from /usr/ports/UPDATING 20050722: AFFECTS: All RELENG_6 and HEAD users of ports/packages, maintainers of ports that interact with the compat libraries. AUTHOR: kensmith@FreeBSD.org The shared library version number of all shared libraries built as part of the baseline system has been incremented in both RELENG_6 and HEAD. The overall goal is to make handling of the compat library infrastructure easier. Each new release branch will have different version numbers for all of the shared libraries and the compat ports can simply include all of the shared libraries from the previous release. If you update your system using normal cvsup/rebuild/reinstall mechanisms the old versions of the libraries will still be on your system so your old ports executables will continue to work. But you definitely should plan on recompiling and reinstalling all of your installed ports so they get relinked against the new libraries. If you don't take this step as time goes on "normal" updates and installs run the risk of having executables relying on both the new and old versions of the libraries which would cause big problems. It will take some time for the pre-built packages available on the FTP mirror sites to be rebuilt against the new libraries. If you want to update your ports using the pre-built packages watch the mailing lists for when the rebuilt packages become available. Dunno wether you've done it :) HTH, Marian From owner-freebsd-current@FreeBSD.ORG Thu Sep 15 08:12:04 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF63616A41F for ; Thu, 15 Sep 2005 08:12:04 +0000 (GMT) (envelope-from nkalev@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 509F843D45 for ; Thu, 15 Sep 2005 08:12:04 +0000 (GMT) (envelope-from nkalev@gmail.com) Received: by zproxy.gmail.com with SMTP id 40so183161nzk for ; Thu, 15 Sep 2005 01:12:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=jeK4RYgVP2sbXX5cLctfOKYF4nrv0IObGd1M0ob81cVrAXcuE1w6ntxlTMNH0czzxlkzKBAA2I9yccurQXAdBm14Kpo4Hb+Tu/i+7XWaxgSmG766oqNejZtewMG5EoumIUTprWSesXcot9+YxNr06No5Yfr3LUnG703IVRe6OJY= Received: by 10.54.50.78 with SMTP id x78mr105604wrx; Thu, 15 Sep 2005 01:12:03 -0700 (PDT) Received: from ?172.16.101.106? ( [212.36.7.117]) by mx.gmail.com with ESMTP id 16sm613974wrl.2005.09.15.01.11.59; Thu, 15 Sep 2005 01:12:03 -0700 (PDT) Message-ID: <43292E95.9070606@gmail.com> Date: Thu, 15 Sep 2005 11:19:33 +0300 From: Nikolay Kalev User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050722) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marian Hettwer , freebsd-current@freebsd.org References: <4327F6FF.5080108@gmail.com> <432929A4.5020607@kernel32.de> In-Reply-To: <432929A4.5020607@kernel32.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Xorg core dump ! FreeBSD 6.0 Beta4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2005 08:12:04 -0000 Marian Hettwer wrote: > Hi, > > Nikolay Kalev wrote: > >> i get a core dump from X after update to freebsd 6.0 beta4 >> here is the backtrace info : > > > Just a quick guess, since you updated to 6.0-BETA4... did you > recompiled your ports ? Somewhere around BETA3 (or was it BETA2) it > was necessary to recompile all ports, due to a update of shared > libraries of the base system... > > snip from /usr/ports/UPDATING > 20050722: > AFFECTS: All RELENG_6 and HEAD users of ports/packages, maintainers > of ports that interact with the compat libraries. > AUTHOR: kensmith@FreeBSD.org > > The shared library version number of all shared libraries built as > part of the baseline system has been incremented in both RELENG_6 > and HEAD. The overall goal is to make handling of the compat library > infrastructure easier. Each new release branch will have different > version numbers for all of the shared libraries and the compat ports > can simply include all of the shared libraries from the previous > release. > > If you update your system using normal cvsup/rebuild/reinstall > mechanisms the old versions of the libraries will still be on your > system so your old ports executables will continue to work. > But you definitely should plan on recompiling and reinstalling all > of your installed ports so they get relinked against the new libraries. > If you don't take this step as time goes on "normal" updates and > installs run the risk of having executables relying on both the new > and old versions of the libraries which would cause big problems. > > It will take some time for the pre-built packages available on the > FTP mirror sites to be rebuilt against the new libraries. If you > want to update your ports using the pre-built packages watch the > mailing lists for when the rebuilt packages become available. > > Dunno wether you've done it :) > > HTH, > Marian > This could be the problem i didn;t do a recompilation of Xorg when moving from beta3 to beta4. Thanks for the advice ! From owner-freebsd-current@FreeBSD.ORG Thu Sep 15 09:16:29 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D4BD16A41F for ; Thu, 15 Sep 2005 09:16:29 +0000 (GMT) (envelope-from corwin@pleiades.aeternal.net) Received: from amber.aeternal.net (amber.in.markiza.sk [62.168.76.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83C5543D48 for ; Thu, 15 Sep 2005 09:16:27 +0000 (GMT) (envelope-from corwin@pleiades.aeternal.net) Received: from localhost (localhost.aeternal.net [127.0.0.1]) by amber.aeternal.net (Postfix) with ESMTP id 249F8B890 for ; Thu, 15 Sep 2005 11:17:17 +0200 (CEST) Received: from amber.aeternal.net ([127.0.0.1]) by localhost (amber.aeternal.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81062-06 for ; Thu, 15 Sep 2005 11:17:10 +0200 (CEST) Received: from pleiades.aeternal.net (pleiades.aeternal.net [192.168.0.44]) by amber.aeternal.net (Postfix) with ESMTP id AE5A0B88E for ; Thu, 15 Sep 2005 11:17:10 +0200 (CEST) Received: by pleiades.aeternal.net (Postfix, from userid 1001) id B075611438; Thu, 15 Sep 2005 11:16:25 +0200 (CEST) Date: Thu, 15 Sep 2005 11:16:25 +0200 From: martin hudec To: freebsd-current@freebsd.org Message-ID: <20050915091625.GB44389@pleiades.aeternal.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="iFRdW5/EC4oqxDHL" Content-Disposition: inline X-Copyright: (C) 2005 Martin Hudec X-Operating-System: FreeBSD pleiades.aeternal.net 7.0-CURRENT i386 X-PGP-Key: http://www.aeternal.net/corwin_aeternal.asc User-Agent: mutt-ng/devel-r445 (FreeBSD) X-Virus-Scanned: by amavisd-new at aeternal.net Subject: LOR during bootup on 6.0-BETA4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin hudec List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2005 09:16:29 -0000 --iFRdW5/EC4oqxDHL Content-Type: multipart/mixed; boundary="KFztAG8eRSV9hGtP" Content-Disposition: inline --KFztAG8eRSV9hGtP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, I am getting lock order reversal during bootup on one of my servers after mounting from root: lock order reversal 1st 0xc073b5e0 UMA lock (UMA lock) @ /usr/src/sys/vm/uma_core.c:1494 2nd 0xc1060144 system map (system map) @ /usr/src/sys/vm/vm_kern.c:295 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c06f0780,c06f08c0,c06b69e4) at kdb_backtrace+0x29 witness_checkorder(c1060144,9,c069443e,127) at witness_checkorder+0x564 _mtx_lock_flags(c1060144,0,c069443e,127) at _mtx_lock_flags+0x5b _vm_map_lock(c10600c0,c069443e,127) at _vm_map_lock+0x26 kmem_malloc(c10600c0,1000,1,e6b4bba4,c05fcd59) at kmem_malloc+0x32 page_alloc(c104a960,1000,e6b4bb97,1,c05118e4) at page_alloc+0x1a slab_zalloc(c104a960,1,0,c3ba2980,c104917c) at slab_zalloc+0xa1 uma_zone_slab(c104a960,1,1,10,168f) at uma_zone_slab+0xe8 uma_zalloc_bucket(c104a960,1) at uma_zalloc_bucket+0x12c uma_zalloc_arg(c104a960,0,1) at uma_zalloc_arg+0x2dc malloc(800,c06c9480,1,1a4,c1044460) at malloc+0xae hash_alloc(e6b4bc74,c1044468,0,c06936f7,1ab) at hash_alloc+0x29 zone_timeout(c1042b40) at zone_timeout+0x7e zone_foreach(c05fc590,e6b4bce8,c04fb6df,0,c05fc55c) at zone_foreach+0x37 uma_timeout(0) at uma_timeout+0x12 softclock(0) at softclock+0x1e7 ithread_loop(c3567480,e6b4bd38,c3567480,c04ddcc8,0) at ithread_loop+0x11c fork_exit(c04ddcc8,c3567480,e6b4bd38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip =3D 0, esp =3D 0xe6b4bd6c, ebp =3D 0 --- If I could be of any assistance, let me know. I am attaching dmesg. --=20 martin hudec * 421 907 303 393 * corwin@aeternal.net * http://www.aeternal.net "Nothing travels faster than the speed of light with the possible=20 exception of bad news, which obeys its own special laws." Douglas Adams, "The Hitchhiker's Guide to the Galaxy" --KFztAG8eRSV9hGtP Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg.plech.txt" Content-Transfer-Encoding: quoted-printable Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.0-BETA4 #0: Tue Sep 13 21:23:27 CEST 2005 hudec@plech.markiza.sk:/usr/obj/usr/src/sys/PLECH WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.40GHz (3400.14-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0xf41 Stepping =3D 1 Features=3D0xbfebfbff Features2=3D0x649d> AMD Features=3D0x20000000 Hyperthreading: 2 logical CPUs real memory =3D 2147430400 (2047 MB) avail memory =3D 2096496640 (1999 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP): APIC ID: 7 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard ioapic2 irqs 48-71 on motherboard ioapic3 irqs 72-95 on motherboard ioapic4 irqs 96-119 on motherboard npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) pci_link0: irq 5 on acpi0 pci_link1: irq 5 on acpi0 pci_link2: irq 5 on acpi0 pci_link3: irq 5 on acpi0 pci_link4: irq 0 on acpi0 pci_link5: irq 5 on acpi0 pci_link6: irq 5 on acpi0 pci_link7: irq 5 on acpi0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x908-0x90b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pcib0: on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci2: on pcib1 pcib2: at device 0.0 on pci2 pci3: on pcib2 bge0: mem 0xfde= f0000-0xfdefffff irq 25 at device 1.0 on pci3 miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000b= aseTX-FDX, auto bge0: Ethernet address: 00:13:21:6b:8d:19 bge1: mem 0xfde= e0000-0xfdeeffff irq 26 at device 1.1 on pci3 miibus1: on bge1 brgphy1: on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000b= aseTX-FDX, auto bge1: Ethernet address: 00:13:21:6b:8d:18 pcib3: at device 0.2 on pci2 pci4: on pcib3 ciss0: port 0x4000-0x40ff mem 0xfdff0000-0xfdff1fff,0xf= df80000-0xfdfbffff irq 51 at device 3.0 on pci4 ciss0: [GIANT-LOCKED] pcib4: at device 6.0 on pci0 pci5: on pcib4 pcib5: at device 0.0 on pci5 pci6: on pcib5 pcib6: at device 0.2 on pci5 pci10: on pcib6 uhci0: port 0x2000-0x201f irq 1= 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 0x2020-0x203f irq 1= 9 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 0x2040-0x205f irq 1= 8 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 uhci3: port 0x2060-0x207f irq 1= 6 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xfbef0000-0xfbef03ff irq 23= at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered pcib7: at device 30.0 on pci0 pci1: on pcib7 pci1: at device 3.0 (no driver attached) pci1: at device 4.0 (no driver attached) pci1: at device 4.2 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177= ,0x376,0x500-0x50f at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] sio0: port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A fdc0: port 0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: [FAST] pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xcbfff,0xcc000-0x= cd7ff,0xee000-0xeffff on isa0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec acd0: CDROM at ata0-master PIO4 da0 at ciss0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-0 device=20 da0: 135.168MB/s transfers da0: 34727MB (71122560 512 byte sectors: 255H 32S/T 8716C) SMP: AP CPU #2 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! Trying to mount root from ufs:/dev/da0s1a lock order reversal 1st 0xc073b5e0 UMA lock (UMA lock) @ /usr/src/sys/vm/uma_core.c:1494 2nd 0xc1060144 system map (system map) @ /usr/src/sys/vm/vm_kern.c:295 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c06f0780,c06f08c0,c06b69e4) at kdb_backtrace+0x29 witness_checkorder(c1060144,9,c069443e,127) at witness_checkorder+0x564 _mtx_lock_flags(c1060144,0,c069443e,127) at _mtx_lock_flags+0x5b _vm_map_lock(c10600c0,c069443e,127) at _vm_map_lock+0x26 kmem_malloc(c10600c0,1000,1,e6b4bba4,c05fcd59) at kmem_malloc+0x32 page_alloc(c104a960,1000,e6b4bb97,1,c05118e4) at page_alloc+0x1a slab_zalloc(c104a960,1,0,c3ba2980,c104917c) at slab_zalloc+0xa1 uma_zone_slab(c104a960,1,1,10,168f) at uma_zone_slab+0xe8 uma_zalloc_bucket(c104a960,1) at uma_zalloc_bucket+0x12c uma_zalloc_arg(c104a960,0,1) at uma_zalloc_arg+0x2dc malloc(800,c06c9480,1,1a4,c1044460) at malloc+0xae hash_alloc(e6b4bc74,c1044468,0,c06936f7,1ab) at hash_alloc+0x29 zone_timeout(c1042b40) at zone_timeout+0x7e zone_foreach(c05fc590,e6b4bce8,c04fb6df,0,c05fc55c) at zone_foreach+0x37 uma_timeout(0) at uma_timeout+0x12 softclock(0) at softclock+0x1e7 ithread_loop(c3567480,e6b4bd38,c3567480,c04ddcc8,0) at ithread_loop+0x11c fork_exit(c04ddcc8,c3567480,e6b4bd38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip =3D 0, esp =3D 0xe6b4bd6c, ebp =3D 0 --- --KFztAG8eRSV9hGtP-- --iFRdW5/EC4oqxDHL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDKTvpZYEZIv+rgggRAkP/AJ47euxzHAYZF1Juo7DFmShycES1bQCcCL9m 3MtZAtnXQ4pb4v6jpFUdIkA= =8+Oc -----END PGP SIGNATURE----- --iFRdW5/EC4oqxDHL-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 15 09:30:11 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FCA216A41F for ; Thu, 15 Sep 2005 09:30:11 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id D997943D45 for ; Thu, 15 Sep 2005 09:30:10 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 04B3A1FF9A7; Thu, 15 Sep 2005 11:30:08 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id 6B17D1FF9A6; Thu, 15 Sep 2005 11:30:05 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id 1BEE0157B9; Thu, 15 Sep 2005 09:28:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id 117731577D; Thu, 15 Sep 2005 09:28:44 +0000 (UTC) Date: Thu, 15 Sep 2005 09:28:43 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: martin hudec In-Reply-To: <20050915091625.GB44389@pleiades.aeternal.net> Message-ID: References: <20050915091625.GB44389@pleiades.aeternal.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Cc: freebsd-current@freebsd.org Subject: Re: LOR during bootup on 6.0-BETA4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2005 09:30:11 -0000 On Thu, 15 Sep 2005, martin hudec wrote: Hello, > I am getting lock order reversal during bootup on one of my servers > after mounting from root: > > lock order reversal > 1st 0xc073b5e0 UMA lock (UMA lock) @ /usr/src/sys/vm/uma_core.c:1494 > 2nd 0xc1060144 system map (system map) @ > /usr/src/sys/vm/vm_kern.c:295 [ use browser + favorite search engine ] "lock order reversal" [ you are feeling lucky ] scroll down a bit and find this LOR ;) http://sources.zabbadoz.net/freebsd/lor.html#110 -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-current@FreeBSD.ORG Thu Sep 15 09:35:06 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6652616A41F for ; Thu, 15 Sep 2005 09:35:06 +0000 (GMT) (envelope-from corwin@pleiades.aeternal.net) Received: from amber.aeternal.net (amber.in.markiza.sk [62.168.76.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id CEA1443D49 for ; Thu, 15 Sep 2005 09:35:05 +0000 (GMT) (envelope-from corwin@pleiades.aeternal.net) Received: from localhost (localhost.aeternal.net [127.0.0.1]) by amber.aeternal.net (Postfix) with ESMTP id 17A35B888; Thu, 15 Sep 2005 11:35:56 +0200 (CEST) Received: from amber.aeternal.net ([127.0.0.1]) by localhost (amber.aeternal.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84620-07; Thu, 15 Sep 2005 11:35:54 +0200 (CEST) Received: from pleiades.aeternal.net (pleiades.aeternal.net [192.168.0.44]) by amber.aeternal.net (Postfix) with ESMTP id C5457B88F; Thu, 15 Sep 2005 11:35:54 +0200 (CEST) Received: by pleiades.aeternal.net (Postfix, from userid 1001) id C193A11438; Thu, 15 Sep 2005 11:35:09 +0200 (CEST) Date: Thu, 15 Sep 2005 11:35:09 +0200 From: martin hudec To: "Bjoern A. Zeeb" Message-ID: <20050915093509.GC44389@pleiades.aeternal.net> References: <20050915091625.GB44389@pleiades.aeternal.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hoZxPH4CaxYzWscb" Content-Disposition: inline In-Reply-To: X-Copyright: (C) 2005 Martin Hudec X-Operating-System: FreeBSD pleiades.aeternal.net 7.0-CURRENT i386 X-PGP-Key: http://www.aeternal.net/corwin_aeternal.asc User-Agent: mutt-ng/devel-r445 (FreeBSD) X-Virus-Scanned: by amavisd-new at aeternal.net Cc: freebsd-current@freebsd.org Subject: Re: LOR during bootup on 6.0-BETA4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin hudec List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2005 09:35:06 -0000 --hoZxPH4CaxYzWscb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, On Thu, Sep 15, 2005 at 09:28:43AM +0000 or thereabouts, Bjoern A. Zeeb wro= te: > [ use browser + favorite search engine ] > "lock order reversal" > [ you are feeling lucky ] >=20 > scroll down a bit and find this LOR ;) >=20 > http://sources.zabbadoz.net/freebsd/lor.html#110 :) thanks.. I will put your site to bookmarks :). --=20 martin hudec * 421 907 303 393 * corwin@aeternal.net * http://www.aeternal.net "Nothing travels faster than the speed of light with the possible=20 exception of bad news, which obeys its own special laws." Douglas Adams, "The Hitchhiker's Guide to the Galaxy" --hoZxPH4CaxYzWscb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDKUBNZYEZIv+rgggRAiWwAJ956D2ePU6Gs0cCvKaIPsG0FrvKeQCghFSz 6BF9Vg6q877OUMTe28mjPdM= =vsCr -----END PGP SIGNATURE----- --hoZxPH4CaxYzWscb-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 15 09:35:10 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F88C16A41F for ; Thu, 15 Sep 2005 09:35:10 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7308643D4C for ; Thu, 15 Sep 2005 09:35:08 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from Andro-Beta.Leidinger.net (p54A5CF6E.dip.t-dialin.net [84.165.207.110]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.1/8.13.1) with ESMTP id j8F9MkHU087797; Thu, 15 Sep 2005 11:23:10 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from localhost (localhost [127.0.0.1]) by Andro-Beta.Leidinger.net (8.13.3/8.13.3) with ESMTP id j8F9XtMn007647; Thu, 15 Sep 2005 11:33:55 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by netchild.homeip.net (Horde MIME library) with HTTP; Thu, 15 Sep 2005 11:33:54 +0200 Message-ID: <20050915113354.iv5u8ycfksscw4wk@netchild.homeip.net> X-Priority: 3 (Normal) Date: Thu, 15 Sep 2005 11:33:54 +0200 From: Alexander Leidinger To: pyunyh@gmail.com References: <47d0403c05091121047a037946@mail.gmail.com> <20050912044212.GC5182@rndsoft.co.kr> <47d0403c05091122276fd0a231@mail.gmail.com> <20050913070149.GE9481@rndsoft.co.kr> <47d0403c0509131235ed58122@mail.gmail.com> <20050914014830.GA13631@rndsoft.co.kr> <20050915033848.2d87da42.skywizard@MyBSD.org.my> <20050915014509.GA17602@rndsoft.co.kr> <20050915114653.431f17c5.skywizard@MyBSD.org.my> <20050915043448.GB18332@rndsoft.co.kr> In-Reply-To: <20050915043448.GB18332@rndsoft.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) / FreeBSD-4.11 X-Virus-Scanned: by amavisd-new Cc: freebsd-current@freebsd.org, Ariff Abdullah Subject: documenting the locking requirements? (was: Re: panic upon kldunload snd_ich (lor # 159)) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2005 09:35:10 -0000 Pyun YongHyeon wrote: > > I tend to agree with you. Since that sndstat_busy() isn't enough, how > > about we acquire the entire sndstat so nobody can monkey with it (as the > > proposed / attached diff) and at the same time avoiding this LOR > > message. It seems much better rather than locking sndstat after > > sndstat_busy() and much of pcm_unregister() procedures, only to find out > > that somebody acquire it within that moment. > > > > I didn't try the patch but it looks good to me. :-) > If you have more time would you please fix race in sndstat_open()? > > Minor note : I think it is better to use sx_xunlock ranther than > sx_unlock as sx_xunlock clearly indicates which type of locks held. Are the locking requirements (what needs to be locked and why/when, in which order) in the sound code documented somewhere? If yes: where? If no: can I convince you (either one or both of "you") to write something up (plain text would be enough for a start)? Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 Overheard: "How do I feel? Great! And I kiss pretty good, too!" From owner-freebsd-current@FreeBSD.ORG Thu Sep 15 10:33:55 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 13A2716A41F for ; Thu, 15 Sep 2005 10:33:55 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AACA43D46 for ; Thu, 15 Sep 2005 10:33:54 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 569B76155; Thu, 15 Sep 2005 12:33:36 +0200 (CEST) Received: from xps.des.no (des.no [80.203.228.37]) by tim.des.no (Postfix) with ESMTP id 452736152; Thu, 15 Sep 2005 12:33:36 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id F1D2233DA1; Thu, 15 Sep 2005 12:33:45 +0200 (CEST) To: Benjamin Close References: <43276D91.5000109@cs.unisa.edu.au> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Thu, 15 Sep 2005 12:33:45 +0200 In-Reply-To: <43276D91.5000109@cs.unisa.edu.au> (Benjamin Close's message of "Wed, 14 Sep 2005 09:53:45 +0930") Message-ID: <86u0gmfwmu.fsf@xps.des.no> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Tests: ALL_TRUSTED,AWL,BAYES_00 X-Spam-Learn: ham X-Spam-Score: -5.2/3.0 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on tim.des.no Cc: freebsd-current@freebsd.org Subject: Re: State Of Raid 5 in RELENG_6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2005 10:33:55 -0000 Benjamin Close writes: > With FreeBSD 6 getting closer, I was curious about what was > happening with raid 5 support on ata-raid. I offered sos@ to take care of it for him a while back. I have hardware to test on and a pretty good idea of what needs doing; I just haven't had the time to do it yet. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Sep 15 10:35:18 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 54AF816A420 for ; Thu, 15 Sep 2005 10:35:18 +0000 (GMT) (envelope-from root@solink.ru) Received: from ns.itam.nsc.ru (ns.itam.nsc.ru [194.226.179.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FFDC43D69 for ; Thu, 15 Sep 2005 10:35:14 +0000 (GMT) (envelope-from root@solink.ru) Received: from site.lan (itut.itam.nsc.ru [194.226.179.2]) by ns.itam.nsc.ru (8.13.1/8.12.8) with ESMTP id j8FAZAU4018015 for ; Thu, 15 Sep 2005 17:35:10 +0700 Received: from bocha.solink.office ([192.168.66.166]) (authenticated bits=0) by site.lan (8.12.11/8.12.11) with ESMTP id j8FAZ4dl023880 for ; Thu, 15 Sep 2005 17:35:04 +0700 From: Bachilo Dmitry Organization: SoLink To: freebsd-current@freebsd.org Date: Thu, 15 Sep 2005 17:35:06 +0700 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509151735.06711.root@solink.ru> Subject: 3com wireless pccard X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2005 10:35:18 -0000 Hello I am having a problem with my 3com card. On my 5.4 i had to compile NDIS drivers using original Windows XP drivers presented on drivers disk included in this 3Com wirless device box. And it worked fine. Now the system still compiles with device ndis and options NDISAPI but it writes cardbus0: at device 0.0 (no driver attached) instead of creating ndis0 device. By the way device ath and device ath_hal do not compile since 5.4, but that's other story, because this driver actually does not suppord my NIC. Did I miss something about ndis in 6.0-CURRENT or do i do something wrong? Best regards, Bachilo Dmitry. From owner-freebsd-current@FreeBSD.ORG Wed Sep 14 14:28:10 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A50216A420 for ; Wed, 14 Sep 2005 14:28:10 +0000 (GMT) (envelope-from dandee@volny.cz) Received: from pipa.profix.cz (ruprt.hosting4u.cz [82.208.25.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4EDA543D5A for ; Wed, 14 Sep 2005 14:28:07 +0000 (GMT) (envelope-from dandee@volny.cz) Received: from localhost (localhost [127.0.0.1]) by pipa.profix.cz (Postfix) with ESMTP id C2ACA4E705 for ; Wed, 14 Sep 2005 16:28:09 +0200 (CEST) Received: from pipa.profix.cz ([127.0.0.1]) by localhost (pipa [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04456-05 for ; Wed, 14 Sep 2005 16:28:09 +0200 (CEST) Received: from gandalf (unknown [80.95.121.105]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by pipa.profix.cz (Postfix) with ESMTP id 4525C4E704 for ; Wed, 14 Sep 2005 16:28:08 +0200 (CEST) From: "Stay d" To: Date: Wed, 14 Sep 2005 16:28:00 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcW5OIIHwt72CEjsT6CwX5Qshns6Ew== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Message-Id: <20050914142808.4525C4E704@pipa.profix.cz> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at profix.cz X-Mailman-Approved-At: Thu, 15 Sep 2005 13:15:57 +0000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: (no subject) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dandee@volny.cz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2005 14:28:10 -0000 Hi all, Few minutes ago, I found out that if I use ath_rate_amrr in adhoc mode, tcpdump does not show any beacon packets and olny what I can see on both sides is arp-lookus simultaneously with icmp echo requests on both sides. I switched adhoc mode to hostap on one side and client mode on the second side and voila. TCPDUMP showed me many packets. :) It simple works. ICMP okay. Deos somebody know about this issue ? Amrr rate and adhoc mode together do not work at all. We want to test onoe rate tomorrow. In sample rate adhoc mode is okay. Dan _____ avast! Antivirus : Odchozi zprava cista. Virova databaze (VPS): 0537-1, 14.09.2005 Testovano: 14.9.2005 16:28:00 avast! - copyright (c) 1988-2005 ALWIL Software. From owner-freebsd-current@FreeBSD.ORG Thu Sep 15 15:19:52 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A2FE216A41F for ; Thu, 15 Sep 2005 15:19:52 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id C145043D45 for ; Thu, 15 Sep 2005 15:19:51 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: (qmail 37422 invoked by uid 89); 15 Sep 2005 15:18:29 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 15 Sep 2005 15:18:29 -0000 Date: Thu, 15 Sep 2005 17:20:05 +0200 From: Oliver Lehmann To: joseph.koshy@gmail.com Message-Id: <20050915172005.072f4bdf.lehmann@ans-netz.de> In-Reply-To: <84dead7205091500152a7c25d1@mail.gmail.com> References: <20050914194612.15692485.lehmann@ans-netz.de> <43286E37.40203@samsco.org> <20050914222013.178dc4dc.lehmann@ans-netz.de> <84dead72050914135239514c49@mail.gmail.com> <20050915000053.448f251b.lehmann@ans-netz.de> <84dead7205091500152a7c25d1@mail.gmail.com> X-Mailer: Sylpheed version 2.0.1 (GTK+ 2.6.10; amd64-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: low(er) disk performance with sched_4bsd then with sched_ule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2005 15:19:52 -0000 Joseph Koshy wrote: > What happens if you use a kernel with 'options NO_ADAPTIVE_MUTEXES' ? I'll try this and respond back > [Could you please post your kernel config, and the output of a dmesg after > a boot]. http://pofo.de/tmp/NUDEL http://pofo.de/tmp/dmesg.nudel -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-current@FreeBSD.ORG Thu Sep 15 16:12:25 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A513816A420 for ; Thu, 15 Sep 2005 16:12:25 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65B2C43D45 for ; Thu, 15 Sep 2005 16:12:24 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: (qmail 82006 invoked by uid 89); 15 Sep 2005 16:11:02 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 15 Sep 2005 16:11:02 -0000 Date: Thu, 15 Sep 2005 18:12:38 +0200 From: Oliver Lehmann To: joseph.koshy@gmail.com Message-Id: <20050915181238.54b16b4b.lehmann@ans-netz.de> In-Reply-To: <20050915172005.072f4bdf.lehmann@ans-netz.de> References: <20050914194612.15692485.lehmann@ans-netz.de> <43286E37.40203@samsco.org> <20050914222013.178dc4dc.lehmann@ans-netz.de> <84dead72050914135239514c49@mail.gmail.com> <20050915000053.448f251b.lehmann@ans-netz.de> <84dead7205091500152a7c25d1@mail.gmail.com> <20050915172005.072f4bdf.lehmann@ans-netz.de> X-Mailer: Sylpheed version 2.0.1 (GTK+ 2.6.10; amd64-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: low(er) disk performance with sched_4bsd then with sched_ule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2005 16:12:25 -0000 Oliver Lehmann wrote: > Joseph Koshy wrote: > > > What happens if you use a kernel with 'options NO_ADAPTIVE_MUTEXES' ? > > I'll try this and respond back > Hmm, that made it more worse root@nudel olivleh1> pmcstat -S instructions -c 1 -S instructions -O /tmp/4bsd.2.out dd if=/dev/zero of=/mnt/files/test.dd bs=64k count=32000 32000+0 records in 32000+0 records out 2097152000 bytes transferred in 94.441797 secs (22205761 bytes/sec) root@nudel olivleh1> pmcstat -R /tmp/4bsd.2.out -g root@nudel olivleh1> gprof -l /boot/kernel/kernel ./p6-inst-retired/kernel.gmon > gprof.4bsd.2 time is in ticks, not seconds root@nudel olivleh1> http://pofo.de/tmp/gprof.4bsd.2 -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-current@FreeBSD.ORG Thu Sep 15 16:59:41 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0864B16A41F for ; Thu, 15 Sep 2005 16:59:41 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from rwcrmhc12.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C0DE43D5E for ; Thu, 15 Sep 2005 16:59:34 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from c-66-30-115-133.hsd1.ma.comcast.net (c-66-30-112-193.hsd1.ma.comcast.net[66.30.112.193](misconfigured sender)) by comcast.net (rwcrmhc13) with ESMTP id <2005091516593201500382abe>; Thu, 15 Sep 2005 16:59:32 +0000 Received: from c-66-30-112-193.hsd1.ma.comcast.net (localhost.127.in-addr.arpa [127.0.0.1]) by c-66-30-115-133.hsd1.ma.comcast.net (8.13.4/8.13.1) with ESMTP id j8FGxVIY013899 for ; Thu, 15 Sep 2005 12:59:31 -0400 (EDT) (envelope-from rodrigc@c-66-30-112-193.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-66-30-112-193.hsd1.ma.comcast.net (8.13.4/8.13.1/Submit) id j8FGxV9H013898 for freebsd-current@freebsd.org; Thu, 15 Sep 2005 12:59:31 -0400 (EDT) (envelope-from rodrigc) Date: Thu, 15 Sep 2005 12:59:31 -0400 From: Craig Rodrigues To: freebsd-current@freebsd.org Message-ID: <20050915165931.GA13872@crodrigues.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="jI8keyz6grp/JLjh" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: [RFC] Patch to add GEOM support to libdisk and sysinstall X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2005 16:59:41 -0000 --jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I have been working on a patch to add GEOM support to libdisk and sysinstall. These fixes allow you to label a disk which you currently have a partition mounted on. This is one of the "Desired features" for the 6.0-RELEASE. I copied a lot of code from boot0cfg and bsdlabel into libdisk. My code is available in Perforce on the "rodrigc_libdisk_geom" branch. Also attached are patches against CURRENT CVS. Note: my code is not in CVS yet. Since I am new to GEOM and disk partitioning issues, I would appreciate any feedback. -- Craig Rodrigues rodrigc@crodrigues.org --jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch1.txt" Index: Makefile =================================================================== RCS file: /home/ncvs/src/lib/libdisk/Makefile,v retrieving revision 1.44 diff -u -u -r1.44 Makefile --- Makefile 21 Dec 2004 09:33:46 -0000 1.44 +++ Makefile 15 Sep 2005 16:52:55 -0000 @@ -1,5 +1,7 @@ # $FreeBSD: src/lib/libdisk/Makefile,v 1.44 2004/12/21 09:33:46 ru Exp $ +.PATH: ${.CURDIR}/../../sys/geom + .if ${MACHINE_ARCH} == "ia64" _open_disk= open_ia64_disk.c .else @@ -9,12 +11,13 @@ LIB= disk SRCS= blocks.c ${_change} chunk.c create_chunk.c disk.c ${_open_disk} \ - rules.c write_disk.c write_${MACHINE}_disk.c + rules.c write_disk.c write_${MACHINE}_disk.c geom_bsd_enc.c \ + bsdlabel.c boot0cfg.c INCS= libdisk.h WARNS?= 2 -CFLAGS+= -I${.CURDIR}/../../sys/geom +CFLAGS+= -I${.CURDIR}/../../sys/geom -I${.CURDIR}/../../sbin/bsdlabel .if ${MACHINE} == "pc98" CFLAGS+= -DPC98 @@ -29,7 +32,7 @@ .include tst01: tst01.o libdisk.a - cc ${CFLAGS} -static tst01.o -o tst01 libdisk.a + cc ${CFLAGS} -static tst01.o -o tst01 libdisk.a -lgeom ad0: all install tst01 ./tst01 ad0 Index: boot0cfg.c =================================================================== RCS file: boot0cfg.c diff -N boot0cfg.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ boot0cfg.c 15 Sep 2005 16:52:55 -0000 @@ -0,0 +1,204 @@ +/* + * Copyright (c) 1999 Robert Nordier + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR + * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS + * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, + * OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT + * OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR + * BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, + * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE + * OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, + * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ +#ifdef _STDIO_H_ +#error "BLAH" +#endif + +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "boot0cfg.h" + +/* + * Read in the MBR of the disk. If it is boot0, then use the version to + * read in all of it if necessary. Use pointers to return a malloc'd + * buffer containing the MBR and then return its size. + */ +int +read_mbr(const char *disk, u_int8_t **mbr, int check_version) +{ + u_int8_t buf[MBRSIZE]; + int mbr_size, fd; + ssize_t n; + + if ((fd = open(disk, O_RDONLY)) == -1) + err(1, "open %s", disk); + if ((n = read(fd, buf, MBRSIZE)) == -1) { + warn("read %s", disk); + return -1; + } + if (n != MBRSIZE) { + warnx("%s: short read", disk); + return -1; + } + if (cv2(buf + OFF_MAGIC) != 0xaa55) + warnx("%s: bad magic", disk); + + if (!boot0bs(buf)) { + if (check_version) + warnx("%s: unknown or incompatible boot code", disk); + } else if (boot0version(buf) == 0x101) { + mbr_size = 1024; + if ((*mbr = malloc(mbr_size)) == NULL) + errx(1, "%s: unable to allocate read buffer", disk); + if (lseek(fd, 0, SEEK_SET) == -1 || + (n = read(fd, *mbr, mbr_size)) == -1) + err(1, "%s", disk); + if (n != mbr_size) + errx(1, "%s: short read", disk); + return (mbr_size); + } + *mbr = malloc(sizeof(buf)); + memcpy(*mbr, buf, sizeof(buf)); + + return sizeof(buf); +} + +extern FILE *libdisk_debug; +/* + * Write out the mbr to the specified file. + */ +int +write_mbr(const char *fname, int flags, u_int8_t *mbr, int mbr_size) +{ + int fd, p; + ssize_t n; + char *s; + const char *q; + struct gctl_req *grq; + + fd = open(fname, O_WRONLY | flags, 0666); + if (fd != -1) { + n = write(fd, mbr, mbr_size); + close(fd); + if (n != mbr_size) { + warn("%s:%d %s: short write", __FILE__, __LINE__, fname); + return (-1); + } + return (0); + } + + if (flags != 0) { + warn("%s:%d %s", __FILE__, __LINE__, fname); + return (-1); + } + grq = gctl_get_handle(); + gctl_ro_param(grq, "verb", -1, "write MBR"); + gctl_ro_param(grq, "class", -1, "MBR"); + q = strrchr(fname, '/'); + if (q == NULL) + q = fname; + else + q++; + gctl_ro_param(grq, "geom", -1, q); + gctl_ro_param(grq, "data", mbr_size, mbr); + q = gctl_issue(grq); + gctl_dump(grq, libdisk_debug); + if (q == NULL) { + warnx("%s:%d Succeeded", __FILE__, __LINE__); + gctl_free(grq); + return (0); + } + + warnx("FAILED: %s:%d %s: %s", __FILE__, __LINE__, fname, q); + gctl_free(grq); + +#ifdef DIOCSMBR + for (p = 1; p < 5; p++) { + asprintf(&s, "%ss%d", fname, p); + fd = open(s, O_RDONLY); + if (fd < 0) { + free(s); + continue; + } + n = ioctl(fd, DIOCSMBR, (mbr)); + if (n != 0) { + warn("%s: ioctl DIOCSMBR", fname); + return (-1); + } + close(fd); + free(s); + return (0); + } +#endif + warn("write_mbr: %s", fname); + return (-1); +} + +/* + * Return the boot0 version with the minor revision in the low byte, and + * the major revision in the next higher byte. + */ +int +boot0version(const u_int8_t *bs) +{ + static u_int8_t idold[] = {0xfe, 0x45, 0xf2, 0xe9, 0x00, 0x8a}; + + /* Check for old version, and return 0x100 if found. */ + if (memcmp(bs + 0x1c, idold, sizeof(idold)) == 0) + return 0x100; + + /* We have a newer boot0, so extract the version number and return it. */ + return *(const int *)(bs + OFF_VERSION) & 0xffff; +} + +/* + * Decide if we have valid boot0 boot code by looking for + * characteristic byte sequences at fixed offsets. + */ +int +boot0bs(const u_int8_t *bs) +{ + static u_int8_t id0[] = {0xfc, 0x31, 0xc0, 0x8e, 0xc0, 0x8e, 0xd8, + 0x8e, 0xd0, 0xbc, 0x00, 0x7c }; + static u_int8_t id1[] = {'D', 'r', 'i', 'v', 'e', ' '}; + static struct { + unsigned off; + unsigned len; + u_int8_t *key; + } ident[2] = { + {0x0, sizeof(id0), id0}, + {0x1b2, sizeof(id1), id1} + }; + unsigned int i; + + for (i = 0; i < sizeof(ident) / sizeof(ident[0]); i++) + if (memcmp(bs + ident[i].off, ident[i].key, ident[i].len)) + return 0; + return 1; +} Index: boot0cfg.h =================================================================== RCS file: boot0cfg.h diff -N boot0cfg.h --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ boot0cfg.h 15 Sep 2005 16:52:55 -0000 @@ -0,0 +1,55 @@ +/* + * Copyright (c) 1999 Robert Nordier + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR + * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS + * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, + * OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT + * OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR + * BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, + * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE + * OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, + * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#ifndef _BOOT0CFG_H_ +#define _BOOT0CFG_H_ + +#define MBRSIZE 512 /* master boot record size */ + +#define OFF_VERSION 0x1b0 /* offset: version number */ +#define OFF_OPT 0x1b9 /* offset: default boot option */ +#define OFF_DRIVE 0x1ba /* offset: setdrv drive */ +#define OFF_FLAGS 0x1bb /* offset: option flags */ +#define OFF_TICKS 0x1bc /* offset: clock ticks */ +#define OFF_PTBL 0x1be /* offset: partition table */ +#define OFF_MAGIC 0x1fe /* offset: magic number */ + +#define cv2(p) ((p)[0] | (p)[1] << 010) + +#define mk2(p, x) \ + (p)[0] = (u_int8_t)(x), \ + (p)[1] = (u_int8_t)((x) >> 010) + +__BEGIN_DECLS +int read_mbr(const char *, u_int8_t **, int); +int write_mbr(const char *, int, u_int8_t *, int); +int boot0version(const u_int8_t *); +int boot0bs(const u_int8_t *); +__END_DECLS + +#endif /* ! _BOOT0CFG_H_ */ Index: bsdlabel.c =================================================================== RCS file: bsdlabel.c diff -N bsdlabel.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ bsdlabel.c 15 Sep 2005 16:52:55 -0000 @@ -0,0 +1,1313 @@ +/* + * Copyright (c) 1994, 1995 Gordon W. Ross + * Copyright (c) 1994 Theo de Raadt + * All rights reserved. + * Copyright (c) 1987, 1993 + * The Regents of the University of California. All rights reserved. + * + * This code is derived from software contributed to Berkeley by + * Symmetric Computer Systems. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. All advertising materials mentioning features or use of this software + * must display the following acknowledgement: + * This product includes software developed by the University of + * California, Berkeley and its contributors. + * This product includes software developed by Theo de Raadt. + * 4. Neither the name of the University nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * from: $NetBSD: disksubr.c,v 1.13 2000/12/17 22:39:18 pk $ + */ + +#if 0 +#ifndef lint +static const char copyright[] = +"@(#) Copyright (c) 1987, 1993\n\ + The Regents of the University of California. All rights reserved.\n"; +#endif /* not lint */ + +#ifndef lint +static char sccsid[] = "@(#)disklabel.c 8.2 (Berkeley) 1/7/94"; +/* from static char sccsid[] = "@(#)disklabel.c 1.2 (Symmetric) 11/28/85"; */ +#endif /* not lint */ +#endif +#include +__FBSDID("$FreeBSD: src/sbin/bsdlabel/bsdlabel.c,v 1.111 2005/08/14 22:46:50 iedowse Exp $"); + +#include +#include +#include +#include +#include +#include +#define DKTYPENAMES +#define FSTYPENAMES +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include "bsdlabel.h" +#include "pathnames.h" + +static char *skip(char *); +static char *word(char *); +static int editit(void); +static int getasciilabel(const char *, FILE *, struct disklabel *, int, int); +static int getasciipartspec(char *, struct disklabel *, int, int); +static struct disklabel *getvirginlabel(const char *specname, int); + +#define DEFEDITOR _PATH_VI + +static char tmpfil[] = PATH_TMPFILE; + +//static struct disklabel lab; +static off_t mediasize; +static u_int secsize; +//static char blank[] = ""; +//static char unknown[] = "unknown"; + +#define MAX_PART ('z') +#define MAX_NUM_PARTS (1 + MAX_PART - 'a') +static char part_size_type[MAX_NUM_PARTS]; +static char part_offset_type[MAX_NUM_PARTS]; +static int part_set[MAX_NUM_PARTS]; + +//static int allfields; /* present all fields in edit */ +//static char const *xxboot; /* primary boot */ + +static off_t mbroffset; +#ifndef LABELSECTOR +#define LABELSECTOR -1 +#endif +#ifndef LABELOFFSET +#define LABELOFFSET -1 +#endif +static int labelsoffset = LABELSECTOR; +static int labeloffset = LABELOFFSET; +static int bbsize = BBSIZE; +static int alphacksum = +#if defined(__alpha__) + 1; +#else + 0; +#endif + +enum { + UNSPEC, EDIT, READ, RESTORE, WRITE, WRITEBOOT +} op = UNSPEC; + + +void +fixlabel(struct disklabel *lp) +{ + struct partition *dp; + int i; + + for (i = 0; i < MAXPARTITIONS; i++) { + if (i == RAW_PART) + continue; + if (lp->d_partitions[i].p_size) + return; + } + + dp = &lp->d_partitions[0]; + dp->p_offset = BBSIZE / secsize; + dp->p_size = lp->d_secperunit - dp->p_offset; +} + +/* + * Construct a prototype disklabel from /etc/disktab. + */ +void +makelabel(const char *specname, const char *type, struct disklabel *lp, int is_file) +{ + struct disklabel *dp; + + if (strcmp(type, "auto") == 0) + dp = getvirginlabel(specname, is_file); + else + dp = getdiskbyname(type); + if (dp == NULL) + errx(1, "%s: unknown disk type", type); + *lp = *dp; + bzero(lp->d_packname, sizeof(lp->d_packname)); +} + +static void +readboot(const char *xxboot, u_char *bootarea) +{ + int fd, i; + struct stat st; + uint64_t *p; + + if (xxboot == NULL) + xxboot = "/boot/boot"; + fd = open(xxboot, O_RDONLY); + if (fd < 0) + err(1, "cannot open %s", xxboot); + fstat(fd, &st); + if (alphacksum && st.st_size <= BBSIZE - 512) { + i = read(fd, bootarea + 512, st.st_size); + if (i != st.st_size) + err(1, "read error %s", xxboot); + + /* + * Set the location and length so SRM can find the + * boot blocks. + */ + p = (uint64_t *)bootarea; + p[60] = (st.st_size + secsize - 1) / secsize; + p[61] = 1; + p[62] = 0; + return; + } else if ((!alphacksum) && st.st_size <= BBSIZE) { + i = read(fd, bootarea, st.st_size); + if (i != st.st_size) + err(1, "read error %s", xxboot); + return; + } + errx(1, "boot code %s is wrong size", xxboot); +} + +int +writelabel(struct disklabel *lp, const char *specname, const char *dkname, const char *xxboot, + int disable_write, int is_file, int installboot, int allfields) +{ + uint64_t *p, sum; + int i, fd; + struct gctl_req *grq; + char const *errstr; + static u_char bootarea[BBSIZE]; + + if (disable_write) { + warnx("write to disk label supressed - label was as follows:"); + display(specname, stdout, NULL, allfields); + return (0); + } + + lp->d_magic = DISKMAGIC; + lp->d_magic2 = DISKMAGIC; + lp->d_checksum = 0; + lp->d_checksum = dkcksum(lp); + if (installboot) + readboot(xxboot, bootarea); + for (i = 0; i < lp->d_npartitions; i++) + if (lp->d_partitions[i].p_size) + lp->d_partitions[i].p_offset += mbroffset; + bsd_disklabel_le_enc(bootarea + labeloffset + labelsoffset * secsize, + lp); + if (alphacksum) { + /* Generate the bootblock checksum for the SRM console. */ + for (p = (uint64_t *)bootarea, i = 0, sum = 0; i < 63; i++) + sum += p[i]; + p[63] = sum; + } + + fd = open(specname, O_RDWR); + if (fd < 0) { + if (is_file) { + warn("cannot open file %s for writing label", specname); + return(1); + } + grq = gctl_get_handle(); + gctl_ro_param(grq, "verb", -1, "write label"); + gctl_ro_param(grq, "class", -1, "BSD"); + gctl_ro_param(grq, "geom", -1, dkname); + gctl_ro_param(grq, "label", 148+16*8, + bootarea + labeloffset + labelsoffset * secsize); + errstr = gctl_issue(grq); + if (errstr != NULL) { + warnx("%s", errstr); + gctl_free(grq); + return(1); + } + gctl_free(grq); + if (installboot) { + grq = gctl_get_handle(); + gctl_ro_param(grq, "verb", -1, "write bootcode"); + gctl_ro_param(grq, "class", -1, "BSD"); + gctl_ro_param(grq, "geom", -1, dkname); + gctl_ro_param(grq, "bootcode", BBSIZE, bootarea); + errstr = gctl_issue(grq); + if (errstr != NULL) { + warnx("%s", errstr); + gctl_free(grq); + return (1); + } + gctl_free(grq); + } + } else { + if (write(fd, bootarea, bbsize) != bbsize) { + warn("write %s", specname); + close (fd); + return (1); + } + close (fd); + } + return (0); +} + +static void +get_file_parms(const char *specname, int f) +{ + int i; + struct stat sb; + + if (fstat(f, &sb) != 0) + err(4, "fstat failed"); + i = sb.st_mode & S_IFMT; + if (i != S_IFREG && i != S_IFLNK) + errx(4, "%s is not a valid file or link", specname); + secsize = DEV_BSIZE; + mediasize = sb.st_size; +} + +/* + * Fetch disklabel for disk. + * Use ioctl to get label unless -r flag is given. + */ +int +readlabel(struct disklabel *lp, const char *specname, const char *dkname, u_char *bootarea, + int flag, int is_file) +{ + int f, i; + int error; + struct gctl_req *grq; + char const *errstr; + + f = open(specname, O_RDONLY); + if (f < 0) + err(1, specname); + if (is_file) + get_file_parms(specname, f); + else if ((ioctl(f, DIOCGMEDIASIZE, &mediasize) != 0) || + (ioctl(f, DIOCGSECTORSIZE, &secsize) != 0)) { + err(4, "cannot get disk geometry"); + } + if (mediasize > (off_t)0xffffffff * secsize) + errx(1, + "disks with more than 2^32-1 sectors are not supported"); + (void)lseek(f, (off_t)0, SEEK_SET); + if (read(f, bootarea, BBSIZE) != BBSIZE) + err(4, "%s read", specname); + close (f); + error = bsd_disklabel_le_dec( + bootarea + (labeloffset + labelsoffset * secsize), + lp, MAXPARTITIONS); + if (flag && error) + errx(1, "%s: no valid label found", specname); + + grq = gctl_get_handle(); + gctl_ro_param(grq, "verb", -1, "read mbroffset"); + gctl_ro_param(grq, "class", -1, "BSD"); + gctl_ro_param(grq, "geom", -1, dkname); + gctl_rw_param(grq, "mbroffset", sizeof(mbroffset), &mbroffset); + errstr = gctl_issue(grq); + if (errstr != NULL) { + mbroffset = 0; + gctl_free(grq); + return (error); + } + if (secsize != 0) + mbroffset /= secsize; + + if (lp->d_partitions[RAW_PART].p_offset == mbroffset) + for (i = 0; i < lp->d_npartitions; i++) + if (lp->d_partitions[i].p_size) + lp->d_partitions[i].p_offset -= mbroffset; + return (error); +} + + +void +display(const char *specname, FILE *f, const struct disklabel *lp, int allfields) +{ + int i, j; + const struct partition *pp; + + if (lp == NULL) + return; + + fprintf(f, "# %s:\n", specname); + if (allfields) { + if (lp->d_type < DKMAXTYPES) + fprintf(f, "type: %s\n", dktypenames[lp->d_type]); + else + fprintf(f, "type: %u\n", lp->d_type); + fprintf(f, "disk: %.*s\n", (int)sizeof(lp->d_typename), + lp->d_typename); + fprintf(f, "label: %.*s\n", (int)sizeof(lp->d_packname), + lp->d_packname); + fprintf(f, "flags:"); + if (lp->d_flags & D_REMOVABLE) + fprintf(f, " removeable"); + if (lp->d_flags & D_ECC) + fprintf(f, " ecc"); + if (lp->d_flags & D_BADSECT) + fprintf(f, " badsect"); + fprintf(f, "\n"); + fprintf(f, "bytes/sector: %lu\n", (u_long)lp->d_secsize); + fprintf(f, "sectors/track: %lu\n", (u_long)lp->d_nsectors); + fprintf(f, "tracks/cylinder: %lu\n", (u_long)lp->d_ntracks); + fprintf(f, "sectors/cylinder: %lu\n", (u_long)lp->d_secpercyl); + fprintf(f, "cylinders: %lu\n", (u_long)lp->d_ncylinders); + fprintf(f, "sectors/unit: %lu\n", (u_long)lp->d_secperunit); + fprintf(f, "rpm: %u\n", lp->d_rpm); + fprintf(f, "interleave: %u\n", lp->d_interleave); + fprintf(f, "trackskew: %u\n", lp->d_trackskew); + fprintf(f, "cylinderskew: %u\n", lp->d_cylskew); + fprintf(f, "headswitch: %lu\t\t# milliseconds\n", + (u_long)lp->d_headswitch); + fprintf(f, "track-to-track seek: %ld\t# milliseconds\n", + (u_long)lp->d_trkseek); + fprintf(f, "drivedata: "); + for (i = NDDATA - 1; i >= 0; i--) + if (lp->d_drivedata[i]) + break; + if (i < 0) + i = 0; + for (j = 0; j <= i; j++) + fprintf(f, "%lu ", (u_long)lp->d_drivedata[j]); + fprintf(f, "\n\n"); + } + fprintf(f, "%u partitions:\n", lp->d_npartitions); + fprintf(f, + "# size offset fstype [fsize bsize bps/cpg]\n"); + pp = lp->d_partitions; + for (i = 0; i < lp->d_npartitions; i++, pp++) { + if (pp->p_size) { + fprintf(f, " %c: %8lu %8lu ", 'a' + i, + (u_long)pp->p_size, (u_long)pp->p_offset); + if (pp->p_fstype < FSMAXTYPES) + fprintf(f, "%8.8s", fstypenames[pp->p_fstype]); + else + fprintf(f, "%8d", pp->p_fstype); + switch (pp->p_fstype) { + + case FS_UNUSED: /* XXX */ + fprintf(f, " %5lu %5lu %5.5s ", + (u_long)pp->p_fsize, + (u_long)(pp->p_fsize * pp->p_frag), ""); + break; + + case FS_BSDFFS: + fprintf(f, " %5lu %5lu %5u ", + (u_long)pp->p_fsize, + (u_long)(pp->p_fsize * pp->p_frag), + pp->p_cpg); + break; + + case FS_BSDLFS: + fprintf(f, " %5lu %5lu %5d", + (u_long)pp->p_fsize, + (u_long)(pp->p_fsize * pp->p_frag), + pp->p_cpg); + break; + + default: + fprintf(f, "%20.20s", ""); + break; + } + if (i == RAW_PART) { + fprintf(f, " # \"raw\" part, don't edit"); + } + fprintf(f, "\n"); + } + } + fflush(f); +} + +int +edit(const char *specname, const char *dkname, int disable_write, int is_file, int installboot, int allfields) +{ + int c, fd; + struct disklabel label; + FILE *fp; + struct disklabel lab; + + if ((fd = mkstemp(tmpfil)) == -1 || + (fp = fdopen(fd, "w")) == NULL) { + warnx("can't create %s", tmpfil); + return (1); + } + display(specname, fp, NULL, allfields); + fclose(fp); + for (;;) { + if (!editit()) + break; + fp = fopen(tmpfil, "r"); + if (fp == NULL) { + warnx("can't reopen %s for reading", tmpfil); + break; + } + bzero((char *)&label, sizeof(label)); + c = getasciilabel(specname, fp, &label, is_file, allfields); + fclose(fp); + if (c) { + lab = label; + if (writelabel(&lab, specname, dkname, NULL, disable_write, + is_file, installboot, allfields) == 0) { + (void) unlink(tmpfil); + return (0); + } + } + printf("re-edit the label? [y]: "); + fflush(stdout); + c = getchar(); + if (c != EOF && c != (int)'\n') + while (getchar() != (int)'\n') + ; + if (c == (int)'n') + break; + } + (void) unlink(tmpfil); + return (1); +} + +static int +editit(void) +{ + int pid, xpid; + int locstat, omask; + const char *ed; + + omask = sigblock(sigmask(SIGINT)|sigmask(SIGQUIT)|sigmask(SIGHUP)); + while ((pid = fork()) < 0) { + if (errno == EPROCLIM) { + warnx("you have too many processes"); + return(0); + } + if (errno != EAGAIN) { + warn("fork"); + return(0); + } + sleep(1); + } + if (pid == 0) { + sigsetmask(omask); + setgid(getgid()); + setuid(getuid()); + if ((ed = getenv("EDITOR")) == (char *)0) + ed = DEFEDITOR; + execlp(ed, ed, tmpfil, (char *)0); + err(1, "%s", ed); + } + while ((xpid = wait(&locstat)) >= 0) + if (xpid == pid) + break; + sigsetmask(omask); + return(!locstat); +} + +static char * +skip(char *cp) +{ + + while (*cp != '\0' && isspace(*cp)) + cp++; + if (*cp == '\0' || *cp == '#') + return (NULL); + return (cp); +} + +static char * +word(char *cp) +{ + char c; + + while (*cp != '\0' && !isspace(*cp) && *cp != '#') + cp++; + if ((c = *cp) != '\0') { + *cp++ = '\0'; + if (c != '#') + return (skip(cp)); + } + return (NULL); +} + +/* + * Read an ascii label in from fd f, + * in the same format as that put out by display(), + * and fill in lp. + */ +static int +getasciilabel(const char *specname, FILE *f, struct disklabel *lp, int is_file, int allfields) +{ + char *cp; + const char **cpp; + u_int part; + char *tp, line[BUFSIZ]; + u_long v; + int lineno = 0, errors = 0; + int i; + char blank[] = ""; + char unknown[] = "unknown"; + + makelabel(specname, "auto", lp, is_file); + bzero(&part_set, sizeof(part_set)); + bzero(&part_size_type, sizeof(part_size_type)); + bzero(&part_offset_type, sizeof(part_offset_type)); + lp->d_bbsize = BBSIZE; /* XXX */ + lp->d_sbsize = 0; /* XXX */ + while (fgets(line, sizeof(line) - 1, f)) { + lineno++; + if ((cp = index(line,'\n')) != 0) + *cp = '\0'; + cp = skip(line); + if (cp == NULL) + continue; + tp = index(cp, ':'); + if (tp == NULL) { + fprintf(stderr, "line %d: syntax error\n", lineno); + errors++; + continue; + } + *tp++ = '\0', tp = skip(tp); + if (!strcmp(cp, "type")) { + if (tp == NULL) + tp = unknown; + cpp = dktypenames; + for (; cpp < &dktypenames[DKMAXTYPES]; cpp++) + if (*cpp && !strcmp(*cpp, tp)) { + lp->d_type = cpp - dktypenames; + break; + } + if (cpp < &dktypenames[DKMAXTYPES]) + continue; + v = strtoul(tp, NULL, 10); + if (v >= DKMAXTYPES) + fprintf(stderr, "line %d:%s %lu\n", lineno, + "Warning, unknown disk type", v); + lp->d_type = v; + continue; + } + if (!strcmp(cp, "flags")) { + for (v = 0; (cp = tp) && *cp != '\0';) { + tp = word(cp); + if (!strcmp(cp, "removeable")) + v |= D_REMOVABLE; + else if (!strcmp(cp, "ecc")) + v |= D_ECC; + else if (!strcmp(cp, "badsect")) + v |= D_BADSECT; + else { + fprintf(stderr, + "line %d: %s: bad flag\n", + lineno, cp); + errors++; + } + } + lp->d_flags = v; + continue; + } + if (!strcmp(cp, "drivedata")) { + for (i = 0; (cp = tp) && *cp != '\0' && i < NDDATA;) { + lp->d_drivedata[i++] = strtoul(cp, NULL, 10); + tp = word(cp); + } + continue; + } + if (sscanf(cp, "%lu partitions", &v) == 1) { + if (v == 0 || v > MAXPARTITIONS) { + fprintf(stderr, + "line %d: bad # of partitions\n", lineno); + lp->d_npartitions = MAXPARTITIONS; + errors++; + } else + lp->d_npartitions = v; + continue; + } + if (tp == NULL) + tp = blank; + if (!strcmp(cp, "disk")) { + strncpy(lp->d_typename, tp, sizeof (lp->d_typename)); + continue; + } + if (!strcmp(cp, "label")) { + strncpy(lp->d_packname, tp, sizeof (lp->d_packname)); + continue; + } + if (!strcmp(cp, "bytes/sector")) { + v = strtoul(tp, NULL, 10); + if (v == 0 || (v % DEV_BSIZE) != 0) { + fprintf(stderr, + "line %d: %s: bad sector size\n", + lineno, tp); + errors++; + } else + lp->d_secsize = v; + continue; + } + if (!strcmp(cp, "sectors/track")) { + v = strtoul(tp, NULL, 10); +#if (ULONG_MAX != 0xffffffffUL) + if (v == 0 || v > 0xffffffff) +#else + if (v == 0) +#endif + { + fprintf(stderr, "line %d: %s: bad %s\n", + lineno, tp, cp); + errors++; + } else + lp->d_nsectors = v; + continue; + } + if (!strcmp(cp, "sectors/cylinder")) { + v = strtoul(tp, NULL, 10); + if (v == 0) { + fprintf(stderr, "line %d: %s: bad %s\n", + lineno, tp, cp); + errors++; + } else + lp->d_secpercyl = v; + continue; + } + if (!strcmp(cp, "tracks/cylinder")) { + v = strtoul(tp, NULL, 10); + if (v == 0) { + fprintf(stderr, "line %d: %s: bad %s\n", + lineno, tp, cp); + errors++; + } else + lp->d_ntracks = v; + continue; + } + if (!strcmp(cp, "cylinders")) { + v = strtoul(tp, NULL, 10); + if (v == 0) { + fprintf(stderr, "line %d: %s: bad %s\n", + lineno, tp, cp); + errors++; + } else + lp->d_ncylinders = v; + continue; + } + if (!strcmp(cp, "sectors/unit")) { + v = strtoul(tp, NULL, 10); + if (v == 0) { + fprintf(stderr, "line %d: %s: bad %s\n", + lineno, tp, cp); + errors++; + } else + lp->d_secperunit = v; + continue; + } + if (!strcmp(cp, "rpm")) { + v = strtoul(tp, NULL, 10); + if (v == 0 || v > USHRT_MAX) { + fprintf(stderr, "line %d: %s: bad %s\n", + lineno, tp, cp); + errors++; + } else + lp->d_rpm = v; + continue; + } + if (!strcmp(cp, "interleave")) { + v = strtoul(tp, NULL, 10); + if (v == 0 || v > USHRT_MAX) { + fprintf(stderr, "line %d: %s: bad %s\n", + lineno, tp, cp); + errors++; + } else + lp->d_interleave = v; + continue; + } + if (!strcmp(cp, "trackskew")) { + v = strtoul(tp, NULL, 10); + if (v > USHRT_MAX) { + fprintf(stderr, "line %d: %s: bad %s\n", + lineno, tp, cp); + errors++; + } else + lp->d_trackskew = v; + continue; + } + if (!strcmp(cp, "cylinderskew")) { + v = strtoul(tp, NULL, 10); + if (v > USHRT_MAX) { + fprintf(stderr, "line %d: %s: bad %s\n", + lineno, tp, cp); + errors++; + } else + lp->d_cylskew = v; + continue; + } + if (!strcmp(cp, "headswitch")) { + v = strtoul(tp, NULL, 10); + lp->d_headswitch = v; + continue; + } + if (!strcmp(cp, "track-to-track seek")) { + v = strtoul(tp, NULL, 10); + lp->d_trkseek = v; + continue; + } + /* the ':' was removed above */ + if (*cp < 'a' || *cp > MAX_PART || cp[1] != '\0') { + fprintf(stderr, + "line %d: %s: Unknown disklabel field\n", lineno, + cp); + errors++; + continue; + } + + /* Process a partition specification line. */ + part = *cp - 'a'; + if (part >= lp->d_npartitions) { + fprintf(stderr, + "line %d: partition name out of range a-%c: %s\n", + lineno, 'a' + lp->d_npartitions - 1, cp); + errors++; + continue; + } + part_set[part] = 1; + + if (getasciipartspec(tp, lp, part, lineno) != 0) { + errors++; + break; + } + } + errors += checklabel(specname, lp, is_file, allfields); + return (errors == 0); +} + +#define NXTNUM(n) do { \ + if (tp == NULL) { \ + fprintf(stderr, "line %d: too few numeric fields\n", lineno); \ + return (1); \ + } else { \ + cp = tp, tp = word(cp); \ + (n) = strtoul(cp, NULL, 10); \ + } \ +} while (0) + +/* retain 1 character following number */ +#define NXTWORD(w,n) do { \ + if (tp == NULL) { \ + fprintf(stderr, "line %d: too few numeric fields\n", lineno); \ + return (1); \ + } else { \ + char *tmp; \ + cp = tp, tp = word(cp); \ + (n) = strtoul(cp, &tmp, 10); \ + if (tmp) (w) = *tmp; \ + } \ +} while (0) + +/* + * Read a partition line into partition `part' in the specified disklabel. + * Return 0 on success, 1 on failure. + */ +static int +getasciipartspec(char *tp, struct disklabel *lp, int part, int lineno) +{ + struct partition *pp; + char *cp; + const char **cpp; + u_long v; + + pp = &lp->d_partitions[part]; + cp = NULL; + + v = 0; + NXTWORD(part_size_type[part],v); + if (v == 0 && part_size_type[part] != '*') { + fprintf(stderr, + "line %d: %s: bad partition size\n", lineno, cp); + return (1); + } + pp->p_size = v; + + v = 0; + NXTWORD(part_offset_type[part],v); + if (v == 0 && part_offset_type[part] != '*' && + part_offset_type[part] != '\0') { + fprintf(stderr, + "line %d: %s: bad partition offset\n", lineno, cp); + return (1); + } + pp->p_offset = v; + if (tp == NULL) { + fprintf(stderr, "line %d: missing file system type\n", lineno); + return (1); + } + cp = tp, tp = word(cp); + for (cpp = fstypenames; cpp < &fstypenames[FSMAXTYPES]; cpp++) + if (*cpp && !strcmp(*cpp, cp)) + break; + if (*cpp != NULL) { + pp->p_fstype = cpp - fstypenames; + } else { + if (isdigit(*cp)) + v = strtoul(cp, NULL, 10); + else + v = FSMAXTYPES; + if (v >= FSMAXTYPES) { + fprintf(stderr, + "line %d: Warning, unknown file system type %s\n", + lineno, cp); + v = FS_UNUSED; + } + pp->p_fstype = v; + } + + switch (pp->p_fstype) { + case FS_UNUSED: + case FS_BSDFFS: + case FS_BSDLFS: + /* accept defaults for fsize/frag/cpg */ + if (tp) { + NXTNUM(pp->p_fsize); + if (pp->p_fsize == 0) + break; + NXTNUM(v); + pp->p_frag = v / pp->p_fsize; + if (tp != NULL) + NXTNUM(pp->p_cpg); + } + /* else default to 0's */ + break; + default: + break; + } + return (0); +} + +/* + * Check disklabel for errors and fill in + * derived fields according to supplied values. + */ +int +checklabel(const char *specname, struct disklabel *lp, int is_file, int allfields) +{ + struct partition *pp; + int i, errors = 0; + char part; + u_long base_offset, needed, total_size, total_percent, current_offset; + long free_space; + int seen_default_offset; + int hog_part; + int j; + struct partition *pp2; + + if (lp == NULL) + return(-1); + + if (allfields) { + + if (lp->d_secsize == 0) { + fprintf(stderr, "sector size 0\n"); + return (1); + } + if (lp->d_nsectors == 0) { + fprintf(stderr, "sectors/track 0\n"); + return (1); + } + if (lp->d_ntracks == 0) { + fprintf(stderr, "tracks/cylinder 0\n"); + return (1); + } + if (lp->d_ncylinders == 0) { + fprintf(stderr, "cylinders/unit 0\n"); + errors++; + } + if (lp->d_rpm == 0) + warnx("revolutions/minute 0"); + if (lp->d_secpercyl == 0) + lp->d_secpercyl = lp->d_nsectors * lp->d_ntracks; + if (lp->d_secperunit == 0) + lp->d_secperunit = lp->d_secpercyl * lp->d_ncylinders; + if (lp->d_bbsize == 0) { + fprintf(stderr, "boot block size 0\n"); + errors++; + } else if (lp->d_bbsize % lp->d_secsize) + warnx("boot block size %% sector-size != 0"); + if (lp->d_npartitions > MAXPARTITIONS) + warnx("number of partitions (%lu) > MAXPARTITIONS (%d)", + (u_long)lp->d_npartitions, MAXPARTITIONS); + } else { + struct disklabel *vl; + + vl = getvirginlabel(specname, is_file); + lp->d_secsize = vl->d_secsize; + lp->d_nsectors = vl->d_nsectors; + lp->d_ntracks = vl->d_ntracks; + lp->d_ncylinders = vl->d_ncylinders; + lp->d_rpm = vl->d_rpm; + lp->d_interleave = vl->d_interleave; + lp->d_secpercyl = vl->d_secpercyl; + lp->d_secperunit = vl->d_secperunit; + lp->d_bbsize = vl->d_bbsize; + lp->d_npartitions = vl->d_npartitions; + } + + + /* first allocate space to the partitions, then offsets */ + total_size = 0; /* in sectors */ + total_percent = 0; /* in percent */ + hog_part = -1; + /* find all fixed partitions */ + for (i = 0; i < lp->d_npartitions; i++) { + pp = &lp->d_partitions[i]; + if (part_set[i]) { + if (part_size_type[i] == '*') { + if (i == RAW_PART) { + pp->p_size = lp->d_secperunit; + } else { + if (hog_part != -1) + warnx("Too many '*' partitions (%c and %c)", + hog_part + 'a',i + 'a'); + else + hog_part = i; + } + } else { + off_t size; + + size = pp->p_size; + switch (part_size_type[i]) { + case '%': + total_percent += size; + break; + case 't': + case 'T': + size *= 1024ULL; + /* FALLTHROUGH */ + case 'g': + case 'G': + size *= 1024ULL; + /* FALLTHROUGH */ + case 'm': + case 'M': + size *= 1024ULL; + /* FALLTHROUGH */ + case 'k': + case 'K': + size *= 1024ULL; + break; + case '\0': + break; + default: + warnx("unknown multiplier suffix '%c' for partition %c (should be K, M, G or T)", + part_size_type[i], i + 'a'); + break; + } + /* don't count %'s yet */ + if (part_size_type[i] != '%') { + /* + * for all not in sectors, convert to + * sectors + */ + if (part_size_type[i] != '\0') { + if (size % lp->d_secsize != 0) + warnx("partition %c not an integer number of sectors", + i + 'a'); + size /= lp->d_secsize; + pp->p_size = size; + } + /* else already in sectors */ + if (i != RAW_PART) + total_size += size; + } + } + } + } + + /* Find out the total free space, excluding the boot block area. */ + base_offset = BBSIZE / secsize; + free_space = 0; + for (i = 0; i < lp->d_npartitions; i++) { + pp = &lp->d_partitions[i]; + if (!part_set[i] || i == RAW_PART || + part_size_type[i] == '%' || part_size_type[i] == '*') + continue; + if (pp->p_offset > base_offset) + free_space += pp->p_offset - base_offset; + if (pp->p_offset + pp->p_size > base_offset) + base_offset = pp->p_offset + pp->p_size; + } + if (base_offset < lp->d_secperunit) + free_space += lp->d_secperunit - base_offset; + + /* handle % partitions - note %'s don't need to add up to 100! */ + if (total_percent != 0) { + if (total_percent > 100) { + fprintf(stderr,"total percentage %lu is greater than 100\n", + total_percent); + errors++; + } + + if (free_space > 0) { + for (i = 0; i < lp->d_npartitions; i++) { + pp = &lp->d_partitions[i]; + if (part_set[i] && part_size_type[i] == '%') { + /* careful of overflows! and integer roundoff */ + pp->p_size = ((double)pp->p_size/100) * free_space; + total_size += pp->p_size; + + /* FIX we can lose a sector or so due to roundoff per + partition. A more complex algorithm could avoid that */ + } + } + } else { + fprintf(stderr, + "%ld sectors available to give to '*' and '%%' partitions\n", + free_space); + errors++; + /* fix? set all % partitions to size 0? */ + } + } + /* give anything remaining to the hog partition */ + if (hog_part != -1) { + /* + * Find the range of offsets usable by '*' partitions around + * the hog partition and how much space they need. + */ + needed = 0; + base_offset = BBSIZE / secsize; + for (i = hog_part - 1; i >= 0; i--) { + pp = &lp->d_partitions[i]; + if (!part_set[i] || i == RAW_PART) + continue; + if (part_offset_type[i] == '*') { + needed += pp->p_size; + continue; + } + base_offset = pp->p_offset + pp->p_size; + break; + } + current_offset = lp->d_secperunit; + for (i = lp->d_npartitions - 1; i > hog_part; i--) { + pp = &lp->d_partitions[i]; + if (!part_set[i] || i == RAW_PART) + continue; + if (part_offset_type[i] == '*') { + needed += pp->p_size; + continue; + } + current_offset = pp->p_offset; + } + + if (current_offset - base_offset <= needed) { + fprintf(stderr, "Cannot find space for partition %c\n", + hog_part + 'a'); + fprintf(stderr, + "Need more than %lu sectors between %lu and %lu\n", + needed, base_offset, current_offset); + errors++; + lp->d_partitions[hog_part].p_size = 0; + } else { + lp->d_partitions[hog_part].p_size = current_offset - + base_offset - needed; + total_size += lp->d_partitions[hog_part].p_size; + } + } + + /* Now set the offsets for each partition */ + current_offset = BBSIZE / secsize; /* in sectors */ + seen_default_offset = 0; + for (i = 0; i < lp->d_npartitions; i++) { + part = 'a' + i; + pp = &lp->d_partitions[i]; + if (part_set[i]) { + if (part_offset_type[i] == '*') { + if (i == RAW_PART) { + pp->p_offset = 0; + } else { + pp->p_offset = current_offset; + seen_default_offset = 1; + } + } else { + /* allow them to be out of order for old-style tables */ + if (pp->p_offset < current_offset && + seen_default_offset && i != RAW_PART && + pp->p_fstype != FS_VINUM) { + fprintf(stderr, +"Offset %ld for partition %c overlaps previous partition which ends at %lu\n", + (long)pp->p_offset,i+'a',current_offset); + fprintf(stderr, +"Labels with any *'s for offset must be in ascending order by sector\n"); + errors++; + } else if (pp->p_offset != current_offset && + i != RAW_PART && seen_default_offset) { + /* + * this may give unneeded warnings if + * partitions are out-of-order + */ + warnx( +"Offset %ld for partition %c doesn't match expected value %ld", + (long)pp->p_offset, i + 'a', current_offset); + } + } + if (i != RAW_PART) + current_offset = pp->p_offset + pp->p_size; + } + } + + for (i = 0; i < lp->d_npartitions; i++) { + part = 'a' + i; + pp = &lp->d_partitions[i]; + if (pp->p_size == 0 && pp->p_offset != 0) + warnx("partition %c: size 0, but offset %lu", + part, (u_long)pp->p_offset); +#ifdef notdef + if (pp->p_size % lp->d_secpercyl) + warnx("partition %c: size %% cylinder-size != 0", + part); + if (pp->p_offset % lp->d_secpercyl) + warnx("partition %c: offset %% cylinder-size != 0", + part); +#endif + if (pp->p_offset > lp->d_secperunit) { + fprintf(stderr, + "partition %c: offset past end of unit\n", part); + errors++; + } + if (pp->p_offset + pp->p_size > lp->d_secperunit) { + fprintf(stderr, + "partition %c: partition extends past end of unit\n", + part); + errors++; + } + if (i == RAW_PART) { + if (pp->p_fstype != FS_UNUSED) + warnx("partition %c is not marked as unused!",part); + if (pp->p_offset != 0) + warnx("partition %c doesn't start at 0!",part); + if (pp->p_size != lp->d_secperunit) + warnx("partition %c doesn't cover the whole unit!",part); + + if ((pp->p_fstype != FS_UNUSED) || (pp->p_offset != 0) || + (pp->p_size != lp->d_secperunit)) { + warnx("An incorrect partition %c may cause problems for " + "standard system utilities",part); + } + } + + /* check for overlaps */ + /* this will check for all possible overlaps once and only once */ + for (j = 0; j < i; j++) { + pp2 = &lp->d_partitions[j]; + if (j != RAW_PART && i != RAW_PART && + pp->p_fstype != FS_VINUM && + pp2->p_fstype != FS_VINUM && + part_set[i] && part_set[j]) { + if (pp2->p_offset < pp->p_offset + pp->p_size && + (pp2->p_offset + pp2->p_size > pp->p_offset || + pp2->p_offset >= pp->p_offset)) { + fprintf(stderr,"partitions %c and %c overlap!\n", + j + 'a', i + 'a'); + errors++; + } + } + } + } + for (; i < MAXPARTITIONS; i++) { + part = 'a' + i; + pp = &lp->d_partitions[i]; + if (pp->p_size || pp->p_offset) + warnx("unused partition %c: size %d offset %lu", + 'a' + i, pp->p_size, (u_long)pp->p_offset); + } + return (errors); +} + +/* + * When operating on a "virgin" disk, try getting an initial label + * from the associated device driver. This might work for all device + * drivers that are able to fetch some initial device parameters + * without even having access to a (BSD) disklabel, like SCSI disks, + * most IDE drives, or vn devices. + * + * The device name must be given in its "canonical" form. + */ +static struct disklabel * +getvirginlabel(const char *specname, int is_file) +{ + static struct disklabel loclab; + struct partition *dp; + int f; + u_int u; + + if ((f = open(specname, O_RDONLY)) == -1) { + warn("cannot open %s", specname); + return (NULL); + } + + if (is_file) + get_file_parms(specname, f); + else if ((ioctl(f, DIOCGMEDIASIZE, &mediasize) != 0) || + (ioctl(f, DIOCGSECTORSIZE, &secsize) != 0)) { + close (f); + return (NULL); + } + memset(&loclab, 0, sizeof loclab); + loclab.d_magic = DISKMAGIC; + loclab.d_magic2 = DISKMAGIC; + loclab.d_secsize = secsize; + loclab.d_secperunit = mediasize / secsize; + + /* + * Nobody in these enligthened days uses the CHS geometry for + * anything, but nontheless try to get it right. If we fail + * to get any good ideas from the device, construct something + * which is IBM-PC friendly. + */ + if (ioctl(f, DIOCGFWSECTORS, &u) == 0) + loclab.d_nsectors = u; + else + loclab.d_nsectors = 63; + if (ioctl(f, DIOCGFWHEADS, &u) == 0) + loclab.d_ntracks = u; + else if (loclab.d_secperunit <= 63*1*1024) + loclab.d_ntracks = 1; + else if (loclab.d_secperunit <= 63*16*1024) + loclab.d_ntracks = 16; + else + loclab.d_ntracks = 255; + loclab.d_secpercyl = loclab.d_ntracks * loclab.d_nsectors; + loclab.d_ncylinders = loclab.d_secperunit / loclab.d_secpercyl; + loclab.d_npartitions = MAXPARTITIONS; + + /* Various (unneeded) compat stuff */ + loclab.d_rpm = 3600; + loclab.d_bbsize = BBSIZE; + loclab.d_interleave = 1; + strncpy(loclab.d_typename, "amnesiac", + sizeof(loclab.d_typename)); + + dp = &loclab.d_partitions[RAW_PART]; + dp->p_size = loclab.d_secperunit; + loclab.d_checksum = dkcksum(&loclab); + close (f); + return (&loclab); +} Index: bsdlabel.h =================================================================== RCS file: bsdlabel.h diff -N bsdlabel.h --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ bsdlabel.h 15 Sep 2005 16:52:55 -0000 @@ -0,0 +1,14 @@ +#ifndef _BSDLABEL_H_ +#define _BSD_LABEL_H_ + +__BEGIN_DECLS +void makelabel(const char *, const char *, struct disklabel *, int); +int writelabel(struct disklabel *, const char *, const char *, const char *, int, int, int, int); +int readlabel(struct disklabel *, const char *, const char *, u_char *, int, int); +void display(const char *specname, FILE *, const struct disklabel *, int); +int edit(const char *, const char *, int, int, int, int); +void fixlabel(struct disklabel *); +int checklabel(const char *, struct disklabel *, int, int); +__END_DECLS + +#endif /* ! _BSDLABEL_H_ */ Index: libdisk.h =================================================================== RCS file: /home/ncvs/src/lib/libdisk/libdisk.h,v retrieving revision 1.62 diff -u -u -r1.62 libdisk.h --- libdisk.h 21 Apr 2004 23:21:13 -0000 1.62 +++ libdisk.h 15 Sep 2005 16:52:55 -0000 @@ -10,6 +10,9 @@ * */ +#ifndef LIBDISK_H +#define LIBDISK_H + /* #define DEBUG 1 */ /* You can define a particular architecture here if you are debugging. */ /* #define P_DEBUG p_sparc64 */ @@ -361,3 +364,5 @@ * * */ + +#endif /* ! LIBDISK_H */ Index: write_i386_disk.c =================================================================== RCS file: /home/ncvs/src/lib/libdisk/write_i386_disk.c,v retrieving revision 1.9 diff -u -u -r1.9 write_i386_disk.c --- write_i386_disk.c 4 Jun 2004 11:49:11 -0000 1.9 +++ write_i386_disk.c 15 Sep 2005 16:52:55 -0000 @@ -11,6 +11,7 @@ __FBSDID("$FreeBSD: src/lib/libdisk/write_i386_disk.c,v 1.9 2004/06/04 11:49:11 brian Exp $"); #include +#include #include #include #include @@ -20,39 +21,40 @@ #include #include #include +#include /* XXX: debug */ #include "libdisk.h" +#include "boot0cfg.h" +#include "bsdlabel.h" +#define LABELSIZE (148 + 16 * MAXPARTITIONS) + +/* XXX: debug */ +FILE *libdisk_debug; +const char *junk = "CRAIG"__DATE__ __TIME__ ; /* * XXX: A lot of hardcoded 512s probably should be foo->sector_size; * I'm not sure which, so I leave it like it worked before. --schweikh */ static int -Write_FreeBSD(int fd, const struct disk *new, const struct chunk *c1) +Write_BSDLabel(const char *device, const struct disk *new, const struct chunk *c1) { - struct disklabel *dl; - int i; - void *p; + struct disklabel dl = { 0 }; + //int i, fd; + //void *p; u_char buf[BBSIZE]; + //u_char label[LABELSIZE]; + int installboot = (new->boot1 || new->boot2); + //const char *q; + //struct gctl_req *grq; + int error; + + readlabel(&dl, device, c1->name, buf, 0, 0); + makelabel(device, "auto", &dl, 0); + fixlabel(&dl); + if(checklabel(device, &dl, 0, 0) == 0) + error = writelabel(&dl, device, c1->name, NULL, 0, 0, installboot, 1); - for (i = 0; i < BBSIZE/512; i++) { - if (!(p = read_block(fd, i + c1->offset, 512))) - return (1); - memcpy(buf + 512 * i, p, 512); - free(p); - } - if (new->boot1) - memcpy(buf, new->boot1, 512); - - if (new->boot2) - memcpy(buf + 512, new->boot2, BBSIZE - 512); - - dl = (struct disklabel *)(buf + 512 * LABELSECTOR + LABELOFFSET); - Fill_Disklabel(dl, new, c1); - - for (i = 0; i < BBSIZE / 512; i++) - write_block(fd, i + c1->offset, buf + 512 * i, 512); - - return 0; + return(error); } static void @@ -84,7 +86,7 @@ int Write_Disk(const struct disk *d1) { - int fd, j; + int j, fd; uint i; struct chunk *c1; int ret = 0; @@ -92,24 +94,24 @@ u_char *mbrblk; struct dos_partition *dp,work[NDOSPART]; int s[4]; + int mbr_size; int need_edd = 0; /* Need EDD (packet interface) */ strcpy(device, _PATH_DEV); strcat(device, d1->name); - fd = open(device, O_RDWR); - if (fd < 0) - return 1; + /* XXX: debug */ + libdisk_debug = fopen("/tmp/debug.txt", "w"); + err_set_file(libdisk_debug); memset(s, 0, sizeof s); - if (!(mbrblk = read_block(fd, 0, d1->sector_size))) { - close (fd); - return (1); + if ((mbr_size = read_mbr(device, &mbrblk, 1)) < 0) { + return 1; } dp = (struct dos_partition *)(mbrblk + DOSPARTOFF); memcpy(work, dp, sizeof work); dp = work; - free(mbrblk); + for (c1 = d1->chunks->part; c1; c1 = c1->next) { if (c1->type == unused) continue; @@ -119,8 +121,6 @@ if (j < 0 || j > 3) continue; s[j]++; - if (c1->type == freebsd) - ret += Write_FreeBSD(fd, d1, c1); Write_Int32(&dp[j].dp_start, c1->offset); Write_Int32(&dp[j].dp_size, c1->size); @@ -182,10 +182,6 @@ if (dp[i].dp_typ == 0xa5) dp[i].dp_flag = 0x80; - if (!(mbrblk = read_block(fd, 0, d1->sector_size))) { - close (fd); - return (1); - } if (d1->bootmgr) { memcpy(mbrblk, d1->bootmgr, DOSPARTOFF); Cfg_Boot_Mgr(mbrblk, need_edd); @@ -193,12 +189,40 @@ memcpy(mbrblk + DOSPARTOFF, dp, sizeof *dp * NDOSPART); mbrblk[512-2] = 0x55; mbrblk[512-1] = 0xaa; - write_block(fd, 0, mbrblk, d1->sector_size); + if (d1->bootmgr && d1->bootmgr_size > d1->sector_size) - for (i = 1; i * d1->sector_size <= d1->bootmgr_size; i++) - write_block(fd, i, &d1->bootmgr[i * d1->sector_size], - d1->sector_size); + for (i = 1; (i * d1->sector_size <= d1->bootmgr_size) && i + d1->sector_size < mbr_size; i++) { + memcpy(&mbrblk[i], &d1->bootmgr[i * d1->sector_size], + d1->sector_size); + + } + /* XXX: debug */ + warnx("LIBDISK: writing mbrblk here\n"); + ret = write_mbr(device, 0, mbrblk, mbr_size); + if (ret != 0) { + warnx("LIBDISK: failed writing mbrblk\n"); + } else { // XXX: extra warning + warnx("LIBDISK: succeeded mbrblk\n"); + } + + /* open the device to let GEOM reconfigure */ + fd = open(device, O_WRONLY); + if (fd != -1) + close(fd); - close(fd); - return 0; + for (c1 = d1->chunks->part; c1; c1 = c1->next) { + if (c1->type == freebsd) { + j = Write_BSDLabel(device, d1, c1); + if (j !=0) { + warnx("LIBDISK: failed to write bsdlabel %s", + c1->name); + } else { /* XXX: extra warning */ + warnx("LIBDISK: succeeded writing bsdlabel %s", + c1->name); + } + + ret +=j; + } + } + return ret; } --jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch2.txt" Index: Makefile =================================================================== RCS file: /home/ncvs/src/usr.sbin/sysinstall/Makefile,v retrieving revision 1.134 diff -u -u -r1.134 Makefile --- Makefile 19 Mar 2005 02:28:02 -0000 1.134 +++ Makefile 15 Sep 2005 16:53:22 -0000 @@ -24,8 +24,8 @@ .endif CFLAGS+= -I${.CURDIR}/../../gnu/lib/libdialog -I. -DPADD= ${LIBDIALOG} ${LIBNCURSES} ${LIBUTIL} ${LIBDISK} ${LIBFTPIO} -LDADD= -ldialog -lncurses -lutil -ldisk -lftpio +DPADD= ${LIBDIALOG} ${LIBNCURSES} ${LIBUTIL} ${LIBDISK} ${LIBFTPIO} ${LIBGEOM} +LDADD= -ldialog -lncurses -lutil -ldisk -lftpio -lgeom CLEANFILES= makedevs.c rtermcap CLEANFILES+= keymap.tmp keymap.h --jI8keyz6grp/JLjh-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 15 17:20:22 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3BCBD16A41F for ; Thu, 15 Sep 2005 17:20:22 +0000 (GMT) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7140A43D45 for ; Thu, 15 Sep 2005 17:20:21 +0000 (GMT) (envelope-from mike@sentex.net) Received: from pumice3.sentex.ca (pumice3.sentex.ca [64.7.153.26]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j8FHKKmK099699 for ; Thu, 15 Sep 2005 13:20:20 -0400 (EDT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by pumice3.sentex.ca (8.13.3/8.13.3) with ESMTP id j8FHKKkT070684; Thu, 15 Sep 2005 13:20:20 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.3/8.13.3) with ESMTP id j8FHKIGs082820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Sep 2005 13:20:18 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.2.3.4.0.20050915123947.0810e140@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Thu, 15 Sep 2005 13:20:50 -0400 To: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= ) From: Mike Tancsa In-Reply-To: <867jj5wyvf.fsf@xps.des.no> References: <6.2.1.2.0.20050412220212.055c5d48@64.7.153.2> <867jj5wyvf.fsf@xps.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 X-Scanned-By: MIMEDefang 2.51 on 64.7.153.26 Cc: freebsd-current@freebsd.org Subject: Re: ichwd fixes / patches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2005 17:20:22 -0000 At 04:23 AM 14/04/2005, Dag-Erling Sm=F8rgrav wrote: >Mike Tancsa writes: > > Any chance someone could champion / commit the fixes in > > http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/79698 and perhaps MFC > > ? Its non functional right now and the patches provided there make it > > work once again. > >ichwd is mine... the PR originator sent me patches a couple of days >ago which I'll test. I have both ICH5 and ICH6 hardware to test on. FYI, ICH7 boards seem to work just fine with the=20 above fixes and the PCI IDs defined. I made a=20 followup to the bug report, but made a typo in=20 the board name. Its actually a 945 chipset, not 925. sample dmesg below Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.0-BETA4 #0: Thu Sep 15 23:21:18 EDT 2005 mdtancsa@formerly-itx-vpn.sentex.ca:/usr/obj/usr/src/sys/smp Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) D CPU 2.80GHz (2805.61-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0xf44 Stepping =3D 4 = Features=3D0xbfebfbff Features2=3D0x641d> AMD Features=3D0x20000000 Hyperthreading: 2 logical CPUs real memory =3D 1063841792 (1014 MB) avail memory =3D 1029885952 (982 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) pci_link0: irq 11 on acpi0 pci_link1: irq 11 on acpi0 pci_link2: irq 11 on acpi0 pci_link3: irq 11 on acpi0 pci_link4: irq 11 on acpi0 pci_link5: irq 11 on acpi0 pci_link6: irq 9 on acpi0 pci_link7: irq 10 on acpi0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 2.0 (no driver attached) pci0: at device 27.0 (no driver attached) pcib1: at device 28.0 on pci0 pci1: on pcib1 pcib2: at device 28.2 on pci0 pci2: on pcib2 pcib3: at device 28.3 on pci0 pci3: on pcib3 pcib4: at device 28.4 on pci0 pci4: on pcib4 pcib5: at device 28.5 on pci0 pci5: on pcib5 uhci0: port=20 0x2080-0x209f irq 23 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=20 0x2060-0x207f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port=20 0x2040-0x205f irq 18 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 uhci3: port=20 0x2020-0x203f irq 16 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: mem=20 0x509c4400-0x509c47ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered pcib6: at device 30.0 on pci0 pci6: on pcib6 em0: port 0x1040-0x107f mem=20 0x50820000-0x5083ffff,0x50800000-0x5081ffff irq 21 at device 0.0 on pci6 em0: Ethernet address: 00:0e:0c:5d:f8:ca em0: Speed:N/A Duplex:N/A twe0: <3ware Storage Controller. Driver version=20 1.50.01.002> port 0x1080-0x108f mem=20 0x50000000-0x507fffff irq 22 at device 1.0 on pci6 twe0: [GIANT-LOCKED] twe0: AEN: twe0: AEN: twe0: 2 ports, Firmware FE7X 1.05.00.068, BIOS BE7X 1.08.00.048 fwohci0: mem=20 0x50845000-0x508457ff,0x50840000-0x50843fff irq 17 at device 5.0 on pci6 fwohci0: OHCI version 1.10 (ROM=3D0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:13:20:00:00:6c:21:46 fwohci0: Phy 1394a available S400, 3 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:13:20:6c:21:46 fwe0: Ethernet address: 02:13:20:6c:21:46 fwe0: if_start running deferred for Giant sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=3D0xc800ffc0, gen=3D1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <=3D 0, cable IRM =3D 0 (me) firewire0: bus manager 0 (me) fxp0: port=20 0x1000-0x103f mem 0x50844000-0x50844fff irq 20 at device 8.0 on pci6 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:13:20:6c:21:46 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port=20 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x20b0-0x20bf irq 18 at device 31.1 on= pci0 ata0: on atapci0 ata1: on atapci0 atapci1: port=20 0x20c8-0x20cf,0x20ec-0x20ef,0x20c0-0x20c7,0x20e8-0x20eb,0x20a0-0x20af=20 mem 0x509c4000-0x509c43ff irq 19 at device 31.2 on pci0 ata2: on atapci1 ata3: on atapci1 ata4: on atapci1 ata5: on atapci1 pci0: at device 31.3 (no driver attached) ppc0: port 0x378-0x37f,0x778-0x77f irq 7 on= acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on= acpi0 sio0: type 16550A, console pmtimer0 on isa0 orm0: at iomem 0xcb000-0xcbfff,0xcc000-0xccfff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec Fast IPsec: Initialized Security Association Processing. ad0: 38166MB at ata0-master UDMA100 twed0: on twe0 twed0: 38165MB (78163312 sectors) SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad0s1a=20 From owner-freebsd-current@FreeBSD.ORG Thu Sep 15 18:21:03 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C45116A420; Thu, 15 Sep 2005 18:21:03 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D90943D49; Thu, 15 Sep 2005 18:21:02 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.41.233] (Not Verified[10.50.41.233]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Thu, 15 Sep 2005 14:36:42 -0400 From: John Baldwin To: freebsd-current@freebsd.org, dan.cojocar@gmail.com Date: Thu, 15 Sep 2005 14:22:03 -0400 User-Agent: KMail/1.8 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509151422.04459.jhb@FreeBSD.org> Cc: rwatson@FreeBSD.org Subject: Re: LOR in /usr/src/sys/netinet/in.c:972 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2005 18:21:03 -0000 On Saturday 03 September 2005 10:28 am, Dan Cojocar wrote: > Hello, > Here is my second lor for today :) that i didn't find on > http://sources.zabbadoz.net/freebsd/lor.html > I get this when i run dhclient on cdce0 interface. It's harmless, because I > obtain an valid ip and everything is working ok. > > lock order reversal > 1st 0xc06a2e40 in_multi_mtx (in_multi_mtx) @ /usr/src/sys/netinet/in.c:972 > 2nd 0xc0655660 Giant (Giant) @ /usr/src/sys/net/if.c:1998 > KDB: stack backtrace: > witness_checkorder(c0655660,9,c0612eef,7ce,12c) at witness_checkorder+0x51c > _mtx_lock_flags(c0655660,0,c0612eef,7ce,c) at _mtx_lock_flags+0x54 > if_addmulti(c1a67800,d5729afc,d5729af8,3cc,c1bf0780) at if_addmulti+0x260 > in_addmulti(d5729b40,c1a67800,1,2cc,c1b8bbc8) at in_addmulti+0x66 > in_ifinit(c1f53190,0,0,0,d5729b90) at in_ifinit+0x5bc > in_control(c1f8b000,8040691a,c1f53180,c1a67800,c1aa0e10) at > in_control+0xfaa ifioctl(c1f8b000,8040691a,c1f53180,c1aa0e10,2) at > ifioctl+0x15a > soo_ioctl(c1f5e000,8040691a,c1f53180,c1f65200,c1aa0e10) at soo_ioctl+0x2e8 > ioctl(c1aa0e10,d5729d04,c,422,3) at ioctl+0x118 > syscall(3b,3b,3b,808e3a0,0) at syscall+0x13d > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x807f49b, esp = 0xbfbfe5bc, > ebp = 0xbfbfee28 --- This is a real LOR caused by the fact that in_addmulti() holds the in_multi_mtx() lock across the call to if_addmulti() and if_addmulti() will acquire Giant for non-MPsafe drivers around calls into their ioctl routine. I think that to better expose these issues, the various conditional-Giant macros need to include a witness_warn() to make sure only sleepable locks and/or Giant are held when the lock macro is invoked. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Sep 15 18:22:46 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C14F116A420; Thu, 15 Sep 2005 18:22:46 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4185143D46; Thu, 15 Sep 2005 18:22:46 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.41.233] (Not Verified[10.50.41.233]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Thu, 15 Sep 2005 14:38:26 -0400 From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 15 Sep 2005 14:23:50 -0400 User-Agent: KMail/1.8 References: <200509021321.36320.jhb@FreeBSD.org> In-Reply-To: <200509021321.36320.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509151423.51704.jhb@FreeBSD.org> Cc: current@freebsd.org Subject: Re: Locking for txp(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2005 18:22:46 -0000 On Friday 02 September 2005 01:21 pm, John Baldwin wrote: > I have a patch that adds locking to txp(4) and marks it MPSAFE. I also > think I've found a bug in the driver in low-memory conditions where > txp_rxbuf_reclaim() can't allocate a new mbuf cluster, so I'd appreciate it > if folks could test this. Thanks. > > http://www.FreeBSD.org/~jhb/patches/txp_locking.patch Does anyone have a txp(4) card? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Sep 15 18:22:46 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C14F116A420; Thu, 15 Sep 2005 18:22:46 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4185143D46; Thu, 15 Sep 2005 18:22:46 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.41.233] (Not Verified[10.50.41.233]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Thu, 15 Sep 2005 14:38:26 -0400 From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 15 Sep 2005 14:23:50 -0400 User-Agent: KMail/1.8 References: <200509021321.36320.jhb@FreeBSD.org> In-Reply-To: <200509021321.36320.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509151423.51704.jhb@FreeBSD.org> Cc: current@freebsd.org Subject: Re: Locking for txp(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2005 18:22:46 -0000 On Friday 02 September 2005 01:21 pm, John Baldwin wrote: > I have a patch that adds locking to txp(4) and marks it MPSAFE. I also > think I've found a bug in the driver in low-memory conditions where > txp_rxbuf_reclaim() can't allocate a new mbuf cluster, so I'd appreciate it > if folks could test this. Thanks. > > http://www.FreeBSD.org/~jhb/patches/txp_locking.patch Does anyone have a txp(4) card? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Sep 15 18:56:32 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 05AE416A41F; Thu, 15 Sep 2005 18:56:32 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6941243D45; Thu, 15 Sep 2005 18:56:31 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.41.233] (Not Verified[10.50.41.233]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Thu, 15 Sep 2005 15:12:11 -0400 From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 15 Sep 2005 14:56:49 -0400 User-Agent: KMail/1.8 References: <200509022137.j82LbUj2024170@gw.catspoiler.org> In-Reply-To: <200509022137.j82LbUj2024170@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509151456.50584.jhb@FreeBSD.org> Cc: Don Lewis , rwatson@freebsd.org, current@freebsd.org Subject: Re: Witness patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2005 18:56:32 -0000 On Friday 02 September 2005 05:37 pm, Don Lewis wrote: > On 2 Sep, John Baldwin wrote: > > On Thursday 01 September 2005 11:52 pm, Don Lewis wrote: > >> On 1 Sep, John Baldwin wrote: > >> > This patch forces witness to complain if any mutex is held when Giant > >> > is locked to enforce Giant being the first mutex in the lock order. > >> > This might help track down some of the network LORs being reported > >> > recently. > >> > > >> > http://www.FreeBSD.org/~jhb/patches/witness.patch > >> > >> I think it would make sense to print different messages for the > >> different trigger conditions. > > > > Hmm, I guess I view them as all just being reversals, and that we have > > some implicit orders that go something like this: > > > > sleepable locks --> Giant --> non-sleepable locks --> spin locks > > Attempting to lock one one of the other lock types while holding a spin > lock already prints a unique message and results in a panic. Identifying > the other cases of incorrect lock type ordering with a unique warning > message eliminates the need to grovel through the source code just to > find the types of the locks, and it indicates that looking at the output > of "show witness" is not needed. Ok. I'll still list the reversal (so you know which locks are involved) but will tailor the first line to include the implicit rule in parens if the reversal is the result of an implicit rule. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Sep 15 18:56:32 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 05AE416A41F; Thu, 15 Sep 2005 18:56:32 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6941243D45; Thu, 15 Sep 2005 18:56:31 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.41.233] (Not Verified[10.50.41.233]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Thu, 15 Sep 2005 15:12:11 -0400 From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 15 Sep 2005 14:56:49 -0400 User-Agent: KMail/1.8 References: <200509022137.j82LbUj2024170@gw.catspoiler.org> In-Reply-To: <200509022137.j82LbUj2024170@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509151456.50584.jhb@FreeBSD.org> Cc: Don Lewis , rwatson@freebsd.org, current@freebsd.org Subject: Re: Witness patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2005 18:56:32 -0000 On Friday 02 September 2005 05:37 pm, Don Lewis wrote: > On 2 Sep, John Baldwin wrote: > > On Thursday 01 September 2005 11:52 pm, Don Lewis wrote: > >> On 1 Sep, John Baldwin wrote: > >> > This patch forces witness to complain if any mutex is held when Giant > >> > is locked to enforce Giant being the first mutex in the lock order. > >> > This might help track down some of the network LORs being reported > >> > recently. > >> > > >> > http://www.FreeBSD.org/~jhb/patches/witness.patch > >> > >> I think it would make sense to print different messages for the > >> different trigger conditions. > > > > Hmm, I guess I view them as all just being reversals, and that we have > > some implicit orders that go something like this: > > > > sleepable locks --> Giant --> non-sleepable locks --> spin locks > > Attempting to lock one one of the other lock types while holding a spin > lock already prints a unique message and results in a panic. Identifying > the other cases of incorrect lock type ordering with a unique warning > message eliminates the need to grovel through the source code just to > find the types of the locks, and it indicates that looking at the output > of "show witness" is not needed. Ok. I'll still list the reversal (so you know which locks are involved) but will tailor the first line to include the implicit rule in parens if the reversal is the result of an implicit rule. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Sep 15 19:02:41 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD45516A41F for ; Thu, 15 Sep 2005 19:02:41 +0000 (GMT) (envelope-from minimarmot@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2CAD43D49 for ; Thu, 15 Sep 2005 19:02:40 +0000 (GMT) (envelope-from minimarmot@gmail.com) Received: by xproxy.gmail.com with SMTP id h27so71882wxd for ; Thu, 15 Sep 2005 12:02:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=XipSSkYGMI9tRrWobOrgRDYVALE6tG7DzpuzMbzxsr7XCeQuwl26uBG8JP+0R1JGqW9ePXc2SOgrTg8ovgFQ5A7kLCqPUt/nGOe+faO4sd42DLVZN0R43eOA+REORUDD8LLCRfK8Sn3LtDYJb7cqN5rMGZOm6lVNIvWWKRNI7Zo= Received: by 10.70.12.20 with SMTP id 20mr442257wxl; Thu, 15 Sep 2005 11:34:38 -0700 (PDT) Received: by 10.70.9.2 with HTTP; Thu, 15 Sep 2005 11:34:38 -0700 (PDT) Message-ID: <47d0403c050915113475b8e99d@mail.gmail.com> Date: Thu, 15 Sep 2005 18:34:38 +0000 From: Ben Kaduk To: Bachilo Dmitry In-Reply-To: <200509151735.06711.root@solink.ru> Mime-Version: 1.0 References: <200509151735.06711.root@solink.ru> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: 3com wireless pccard X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: minimarmot@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2005 19:02:41 -0000 On 9/15/05, Bachilo Dmitry wrote: >=20 > Hello >=20 > I am having a problem with my 3com card. On my 5.4 i had to compile NDIS > drivers using original Windows XP drivers presented on drivers disk=20 > included > in this 3Com wirless device box. And it worked fine. >=20 > Now the system still compiles with device ndis and options NDISAPI but it > writes cardbus0: at device 0.0 (no driver attached) > instead of creating ndis0 device. >=20 > By the way device ath and device ath_hal do not compile since 5.4, but=20 > that's > other story, because this driver actually does not suppord my NIC. >=20 > Did I miss something about ndis in 6.0-CURRENT or do i do something wrong= ? >=20 > Best regards, Bachilo Dmitry. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " >=20 The way the ndis driver works has been changed -- the ndis option/module=20 only generates infrastructure, it doesn't pull in the actual windows driver= s=20 anymore -- a separate utility (shell script) ndisgen is now used for this.= =20 Just type ndisgen at a root prompt and it should be fairly self-explanatory= .=20 This change allows the ndis framework to support more than one type of=20 windows driver at a time -- I have a BCMWL5_SYS.ko module for my wireless= =20 card, but I could also have a bcm4324.ko module for my onboard card (which= =20 is actually natively supported) and use them both at the same time. It is m= y=20 understanding that such dual-use was not possible before this change. Unfortunately, the documentation of this change is not in a prominent place= =20 (I missed it myself). Hope this solves your problem Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Thu Sep 15 19:24:18 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C6BA116A41F; Thu, 15 Sep 2005 19:24:18 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54E3343D48; Thu, 15 Sep 2005 19:24:18 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 84C7446BA1; Thu, 15 Sep 2005 15:24:17 -0400 (EDT) Date: Thu, 15 Sep 2005 20:24:17 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: John Baldwin In-Reply-To: <200509151422.04459.jhb@FreeBSD.org> Message-ID: <20050915202308.H75005@fledge.watson.org> References: <200509151422.04459.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, dan.cojocar@gmail.com Subject: Re: LOR in /usr/src/sys/netinet/in.c:972 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2005 19:24:18 -0000 On Thu, 15 Sep 2005, John Baldwin wrote: > On Saturday 03 September 2005 10:28 am, Dan Cojocar wrote: >> Hello, >> Here is my second lor for today :) that i didn't find on >> http://sources.zabbadoz.net/freebsd/lor.html >> I get this when i run dhclient on cdce0 interface. It's harmless, because I >> obtain an valid ip and everything is working ok. >> >> lock order reversal >> 1st 0xc06a2e40 in_multi_mtx (in_multi_mtx) @ /usr/src/sys/netinet/in.c:972 >> 2nd 0xc0655660 Giant (Giant) @ /usr/src/sys/net/if.c:1998 >> KDB: stack backtrace: >> witness_checkorder(c0655660,9,c0612eef,7ce,12c) at witness_checkorder+0x51c >> _mtx_lock_flags(c0655660,0,c0612eef,7ce,c) at _mtx_lock_flags+0x54 >> if_addmulti(c1a67800,d5729afc,d5729af8,3cc,c1bf0780) at if_addmulti+0x260 >> in_addmulti(d5729b40,c1a67800,1,2cc,c1b8bbc8) at in_addmulti+0x66 >> in_ifinit(c1f53190,0,0,0,d5729b90) at in_ifinit+0x5bc >> in_control(c1f8b000,8040691a,c1f53180,c1a67800,c1aa0e10) at >> in_control+0xfaa ifioctl(c1f8b000,8040691a,c1f53180,c1aa0e10,2) at >> ifioctl+0x15a >> soo_ioctl(c1f5e000,8040691a,c1f53180,c1f65200,c1aa0e10) at soo_ioctl+0x2e8 >> ioctl(c1aa0e10,d5729d04,c,422,3) at ioctl+0x118 >> syscall(3b,3b,3b,808e3a0,0) at syscall+0x13d >> Xint0x80_syscall() at Xint0x80_syscall+0x1f >> --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x807f49b, esp = 0xbfbfe5bc, >> ebp = 0xbfbfee28 --- > > This is a real LOR caused by the fact that in_addmulti() holds the > in_multi_mtx() lock across the call to if_addmulti() and if_addmulti() > will acquire Giant for non-MPsafe drivers around calls into their ioctl > routine. I think that to better expose these issues, the various > conditional-Giant macros need to include a witness_warn() to make sure > only sleepable locks and/or Giant are held when the lock macro is > invoked. The right strategy here may in fact be to eliminate Giant acquisition by network device drivers... Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Thu Sep 15 19:27:51 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B384216A41F; Thu, 15 Sep 2005 19:27:51 +0000 (GMT) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F2C643D49; Thu, 15 Sep 2005 19:27:50 +0000 (GMT) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.4/8.13.4) with ESMTP id j8FJRnIj000735; Thu, 15 Sep 2005 23:27:49 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.4/8.13.4/Submit) id j8FJRnx0000734; Thu, 15 Sep 2005 23:27:49 +0400 (MSD) (envelope-from ache) Date: Thu, 15 Sep 2005 23:27:48 +0400 From: Andrey Chernov To: current@freebsd.org, phk@freebsd.org Message-ID: <20050915192748.GA705@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , current@freebsd.org, phk@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.10i Cc: Subject: Recent kernel panic (devfs locking) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2005 19:27:51 -0000 #2 0xc049ae1d in panic (fmt=0xc05d224a "lockmgr: upgrade exclusive lock") at ../../../kern/kern_shutdown.c:555 #3 0xc048dcf6 in lockmgr (lkp=0xc18468d8, flags=3, interlkp=0x0, td=0xc1618a80) at ../../../kern/kern_lock.c:266 #4 0xc0459225 in devfs_populate (dm=0xc18468c0) at pcpu.h:162 #5 0xc045c161 in devfs_rioctl (ap=0xd5471bf0) at ../../../fs/devfs/devfs_vnops.c:974 #6 0xc05bd610 in VOP_IOCTL_APV (vop=0x0, a=0xd5471bf0) at vnode_if.c:804 #7 0xc05031d9 in vn_ioctl (fp=0xc17aae10, com=2147632138, data=0xc16b8bd0, active_cred=0xc1582d00, td=0xc1618a80) at vnode_if.h:436 #8 0xc04c1ad8 in ioctl (td=0xc1618a80, uap=0xd5471d04) at file.h:258 #9 0xc05b365f in syscall (frame= {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = -1077940564, tf_esi = -1077940390, tf_ebp = -1077940664, tf_isp = -716759708, tf_ebx = 134525812, tf_edx = 1, tf_ecx = -1077940732, tf_eax = 54, tf_trapno = 12, tf_err = 2, tf_eip = 672323951, tf_cs = 51, tf_eflags = 646, tf_esp = -1077940692, tf_ss = 59}) at ../../../i386/i386/trap.c:986 #10 0xc05a4d8f in Xint0x80_syscall () at ../../../i386/i386/exception.s:200 -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Thu Sep 15 19:59:49 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D1ED16A421; Thu, 15 Sep 2005 19:59:48 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id D18B243D5E; Thu, 15 Sep 2005 19:59:46 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.41.233] (Not Verified[10.50.41.233]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Thu, 15 Sep 2005 16:15:26 -0400 From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 15 Sep 2005 15:57:09 -0400 User-Agent: KMail/1.8 References: <200509151422.04459.jhb@FreeBSD.org> <20050915202308.H75005@fledge.watson.org> In-Reply-To: <20050915202308.H75005@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509151557.11162.jhb@FreeBSD.org> Cc: Robert Watson , dan.cojocar@gmail.com Subject: Re: LOR in /usr/src/sys/netinet/in.c:972 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2005 19:59:49 -0000 On Thursday 15 September 2005 03:24 pm, Robert Watson wrote: > On Thu, 15 Sep 2005, John Baldwin wrote: > > On Saturday 03 September 2005 10:28 am, Dan Cojocar wrote: > >> Hello, > >> Here is my second lor for today :) that i didn't find on > >> http://sources.zabbadoz.net/freebsd/lor.html > >> I get this when i run dhclient on cdce0 interface. It's harmless, > >> because I obtain an valid ip and everything is working ok. > >> > >> lock order reversal > >> 1st 0xc06a2e40 in_multi_mtx (in_multi_mtx) @ > >> /usr/src/sys/netinet/in.c:972 2nd 0xc0655660 Giant (Giant) @ > >> /usr/src/sys/net/if.c:1998 > >> KDB: stack backtrace: > >> witness_checkorder(c0655660,9,c0612eef,7ce,12c) at > >> witness_checkorder+0x51c _mtx_lock_flags(c0655660,0,c0612eef,7ce,c) at > >> _mtx_lock_flags+0x54 > >> if_addmulti(c1a67800,d5729afc,d5729af8,3cc,c1bf0780) at > >> if_addmulti+0x260 in_addmulti(d5729b40,c1a67800,1,2cc,c1b8bbc8) at > >> in_addmulti+0x66 in_ifinit(c1f53190,0,0,0,d5729b90) at in_ifinit+0x5bc > >> in_control(c1f8b000,8040691a,c1f53180,c1a67800,c1aa0e10) at > >> in_control+0xfaa ifioctl(c1f8b000,8040691a,c1f53180,c1aa0e10,2) at > >> ifioctl+0x15a > >> soo_ioctl(c1f5e000,8040691a,c1f53180,c1f65200,c1aa0e10) at > >> soo_ioctl+0x2e8 ioctl(c1aa0e10,d5729d04,c,422,3) at ioctl+0x118 > >> syscall(3b,3b,3b,808e3a0,0) at syscall+0x13d > >> Xint0x80_syscall() at Xint0x80_syscall+0x1f > >> --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x807f49b, esp = > >> 0xbfbfe5bc, ebp = 0xbfbfee28 --- > > > > This is a real LOR caused by the fact that in_addmulti() holds the > > in_multi_mtx() lock across the call to if_addmulti() and if_addmulti() > > will acquire Giant for non-MPsafe drivers around calls into their ioctl > > routine. I think that to better expose these issues, the various > > conditional-Giant macros need to include a witness_warn() to make sure > > only sleepable locks and/or Giant are held when the lock macro is > > invoked. > > The right strategy here may in fact be to eliminate Giant acquisition by > network device drivers... I'm working on that. :) -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Sep 15 20:16:21 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7840716A41F; Thu, 15 Sep 2005 20:16:21 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23FF343D7B; Thu, 15 Sep 2005 20:16:18 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 2E21B46B42; Thu, 15 Sep 2005 16:16:17 -0400 (EDT) Date: Thu, 15 Sep 2005 21:16:17 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: John Baldwin In-Reply-To: <200509151557.11162.jhb@FreeBSD.org> Message-ID: <20050915211552.O75005@fledge.watson.org> References: <200509151422.04459.jhb@FreeBSD.org> <20050915202308.H75005@fledge.watson.org> <200509151557.11162.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, dan.cojocar@gmail.com Subject: Re: LOR in /usr/src/sys/netinet/in.c:972 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2005 20:16:21 -0000 On Thu, 15 Sep 2005, John Baldwin wrote: >>> This is a real LOR caused by the fact that in_addmulti() holds the >>> in_multi_mtx() lock across the call to if_addmulti() and if_addmulti() >>> will acquire Giant for non-MPsafe drivers around calls into their >>> ioctl routine. I think that to better expose these issues, the various >>> conditional-Giant macros need to include a witness_warn() to make sure >>> only sleepable locks and/or Giant are held when the lock macro is >>> invoked. >> >> The right strategy here may in fact be to eliminate Giant acquisition >> by network device drivers... > > I'm working on that. :) And it is much appreciated :-). Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Thu Sep 15 20:40:14 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A555016A41F for ; Thu, 15 Sep 2005 20:40:14 +0000 (GMT) (envelope-from jay@codegurus.org) Received: from ptb-relay01.plus.net (ptb-relay01.plus.net [212.159.14.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51E8C43D46 for ; Thu, 15 Sep 2005 20:40:14 +0000 (GMT) (envelope-from jay@codegurus.org) Received: from [84.92.156.191] (helo=[192.168.0.3]) by ptb-relay01.plus.net with esmtp (Exim) id 1EG0Wh-0001nv-5M for freebsd-current@freebsd.org; Thu, 15 Sep 2005 21:40:11 +0100 Message-ID: <4329DC37.4090305@codegurus.org> Date: Thu, 15 Sep 2005 21:40:23 +0100 From: Jayton Garnett User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: making custom kernel module with ndiscvt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2005 20:40:14 -0000 Hello, A while back I asked about my wireless card and if it will be supported in 6.0-Release. It wont be :-( . Anyway, I have now decided to use ndiscvt to create my own customer kernel module for my wireless card using the windows drivers. I now have a file called cvwl.h and want to convert it to cvwl.ko so I can either: a)Compile it into the Kernel b)load/unload it dynamically. How would I go about creating the .ko file from the .h file? Cheers, Jayton From owner-freebsd-current@FreeBSD.ORG Thu Sep 15 21:01:31 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 403DD16A41F for ; Thu, 15 Sep 2005 21:01:31 +0000 (GMT) (envelope-from gbergling@0xfce3.net) Received: from einhorn.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E0BE43D46 for ; Thu, 15 Sep 2005 21:01:29 +0000 (GMT) (envelope-from gbergling@0xfce3.net) X-Envelope-From: gbergling@0xfce3.net X-Envelope-To: Received: from node26.0xfce3.net (port-212-202-34-177.dynamic.qsc.de [212.202.34.177]) (authenticated bits=128) by einhorn.in-berlin.de (8.12.10/8.12.10/Debian-4) with ESMTP id j8FL1RLE007885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 15 Sep 2005 23:01:27 +0200 Received: from node26.0xfce3.net (localhost [127.0.0.1]) by node26.0xfce3.net (8.13.4/8.13.4) with ESMTP id j8FL0kY8035298 for ; Thu, 15 Sep 2005 23:00:46 +0200 (CEST) (envelope-from gbergling@0xfce3.net) Received: (from gordon@localhost) by node26.0xfce3.net (8.13.4/8.13.4/Submit) id j8FL0jUp035297 for freebsd-current@freebsd.org; Thu, 15 Sep 2005 23:00:45 +0200 (CEST) (envelope-from gbergling@0xfce3.net) X-Authentication-Warning: node26.0xfce3.net: gordon set sender to gbergling@0xfce3.net using -f Date: Thu, 15 Sep 2005 23:00:45 +0200 From: Gordon Bergling To: freebsd-current@freebsd.org Message-ID: <20050915210045.GA35239@node26.0xfce3.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Url: X-Operating-System: FreeBSD 6.0-BETA4 i386 X-Host-Uptime: 10:51PM up 9:19, 3 users, load averages: 0.33, 0.42, 0.22 User-Agent: Mutt/1.5.10i X-Spam-Score: (-0.859) AWL,BAYES_00,FORGED_RCVD_HELO,HELO_DYNAMIC_DHCP X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 Subject: slow console caused by powerd usage (1024x768) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2005 21:01:31 -0000 Hi, I wondered why my console is something slow on 6.0-BETAx and I played a little bit with my setup and discovered that powerd slows down the console. After killing the process the console seems to be a lot snappier. I run the powerd on a IBM Thinkpad T22 with a 900 MHz PIII. I could unterstand if the powerd lower the clockrate while the notebook isn't connected to a AC line, but it doesn't matter wether I connect the notebook to the AC line or battery usage. I have looked at hw.clockrate and while connected to the AC line the clockrate isn't changed. Thats okay, I think. ;) But, whats makes me wonder, is that the console is soo slow on the notebook while running powerd and connected to AC. Has anyone discovered the same, or has someone an idea on how to fix this? best regards, Gordon -- Gordon Bergling http://www.0xFCE3.net/ PGP Fingerprint: 7732 9BB1 5013 AE8B E42C 28E0 93B9 D32B C76F 02A0 RIPE-HDL: MDTP-RIPE "There is no place like 127.0.0.0/8" From owner-freebsd-current@FreeBSD.ORG Thu Sep 15 21:37:23 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B2E916A41F for ; Thu, 15 Sep 2005 21:37:23 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fileserver.fields.utoronto.ca (fileserver.fields.utoronto.ca [128.100.216.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id B597C43D45 for ; Thu, 15 Sep 2005 21:37:22 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fields.fields.utoronto.ca (fields.localdomain [192.168.216.11]) by fileserver.fields.utoronto.ca (8.12.8/8.12.8/Fields 6.0) with ESMTP id j8FLbK0r026199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Sep 2005 17:37:20 -0400 Received: from obsecurity.dyndns.org (localhost.localdomain [127.0.0.1]) by fields.fields.utoronto.ca (8.12.8/8.12.8/Fields WS 6.0) with ESMTP id j8FLbJ6P027696; Thu, 15 Sep 2005 17:37:20 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 3509F51237; Thu, 15 Sep 2005 17:37:19 -0400 (EDT) Date: Thu, 15 Sep 2005 17:37:19 -0400 From: Kris Kennaway To: Oliver Lehmann Message-ID: <20050915213719.GA26998@xor.obsecurity.org> References: <20050914194612.15692485.lehmann@ans-netz.de> <43286E37.40203@samsco.org> <20050914222013.178dc4dc.lehmann@ans-netz.de> <84dead72050914135239514c49@mail.gmail.com> <20050915000053.448f251b.lehmann@ans-netz.de> <84dead7205091500152a7c25d1@mail.gmail.com> <20050915172005.072f4bdf.lehmann@ans-netz.de> <20050915181238.54b16b4b.lehmann@ans-netz.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wac7ysb48OaltWcw" Content-Disposition: inline In-Reply-To: <20050915181238.54b16b4b.lehmann@ans-netz.de> User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org Subject: Re: low(er) disk performance with sched_4bsd then with sched_ule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2005 21:37:23 -0000 --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 15, 2005 at 06:12:38PM +0200, Oliver Lehmann wrote: > Oliver Lehmann wrote: >=20 > > Joseph Koshy wrote: > >=20 > > > What happens if you use a kernel with 'options NO_ADAPTIVE_MUTEXES' ? > >=20 > > I'll try this and respond back > >=20 >=20 > Hmm, that made it more worse What about using schedgraph as I suggested previously? Kris --wac7ysb48OaltWcw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDKemOWry0BWjoQKURAj6RAJ4s2aleNhLs/wFJG4F7++eAwl5JVwCg9pRx zN6lbW/tiaKrHZVIq6bHAQ0= =jaVB -----END PGP SIGNATURE----- --wac7ysb48OaltWcw-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 15 21:37:50 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BDB8E16A41F; Thu, 15 Sep 2005 21:37:50 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fileserver.fields.utoronto.ca (fileserver.fields.utoronto.ca [128.100.216.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F82D43D46; Thu, 15 Sep 2005 21:37:50 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fields.fields.utoronto.ca (fields.localdomain [192.168.216.11]) by fileserver.fields.utoronto.ca (8.12.8/8.12.8/Fields 6.0) with ESMTP id j8FLbn0r026239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Sep 2005 17:37:49 -0400 Received: from obsecurity.dyndns.org (localhost.localdomain [127.0.0.1]) by fields.fields.utoronto.ca (8.12.8/8.12.8/Fields WS 6.0) with ESMTP id j8FLbn6P027745; Thu, 15 Sep 2005 17:37:49 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 1E8C2514FD; Thu, 15 Sep 2005 17:37:49 -0400 (EDT) Date: Thu, 15 Sep 2005 17:37:48 -0400 From: Kris Kennaway To: Andrey Chernov , current@freebsd.org, phk@freebsd.org Message-ID: <20050915213748.GB26998@xor.obsecurity.org> References: <20050915192748.GA705@nagual.pp.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Fba/0zbH8Xs+Fj9o" Content-Disposition: inline In-Reply-To: <20050915192748.GA705@nagual.pp.ru> User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: Recent kernel panic (devfs locking) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2005 21:37:50 -0000 --Fba/0zbH8Xs+Fj9o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Sep 15, 2005 at 11:27:48PM +0400, Andrey Chernov wrote: > #2 0xc049ae1d in panic (fmt=0xc05d224a "lockmgr: upgrade exclusive lock") > at ../../../kern/kern_shutdown.c:555 phk fixed this a little while ago. Kris --Fba/0zbH8Xs+Fj9o Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDKemsWry0BWjoQKURAhf/AKC6UxrNJk+JU8A6TMY6ldSUGvoVqACdGuY+ DxmY7AXS9lS1l83gtGBzkGI= =OBSW -----END PGP SIGNATURE----- --Fba/0zbH8Xs+Fj9o-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 15 21:39:24 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 94D6F16A41F for ; Thu, 15 Sep 2005 21:39:24 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fileserver.fields.utoronto.ca (fileserver.fields.utoronto.ca [128.100.216.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2579B43D45 for ; Thu, 15 Sep 2005 21:39:24 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fields.fields.utoronto.ca (fields.localdomain [192.168.216.11]) by fileserver.fields.utoronto.ca (8.12.8/8.12.8/Fields 6.0) with ESMTP id j8FLdI0r026349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Sep 2005 17:39:18 -0400 Received: from obsecurity.dyndns.org (localhost.localdomain [127.0.0.1]) by fields.fields.utoronto.ca (8.12.8/8.12.8/Fields WS 6.0) with ESMTP id j8FLdH6P027920; Thu, 15 Sep 2005 17:39:18 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 8938A51237; Thu, 15 Sep 2005 17:39:17 -0400 (EDT) Date: Thu, 15 Sep 2005 17:39:17 -0400 From: Kris Kennaway To: Matthew Dillon Message-ID: <20050915213917.GC26998@xor.obsecurity.org> References: <20050911075157.GA93947@xor.obsecurity.org> <200509132200.j8DM0fHI005530@apollo.backplane.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="96YOpH+ONegL0A3E" Content-Disposition: inline In-Reply-To: <200509132200.j8DM0fHI005530@apollo.backplane.com> User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org, Kris Kennaway Subject: Re: 'swap_pager: indefinite wait buffer' with swapfile X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2005 21:39:24 -0000 --96YOpH+ONegL0A3E Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 13, 2005 at 03:00:41PM -0700, Matthew Dillon wrote: >=20 > : > : > :--bp/iNruPH9dso1Pn > :Content-Type: text/plain; charset=3Dus-ascii > :Content-Disposition: inline > : > :I configured a vnode-backed md and enabled swapping on it. A few > :hours later after moderate swap use the console showed: > : > :swap_pager: indefinite wait buffer: bufobj: 0, blkno: 889347, size: 8192 > :[...repeated...] > : > :The backing store was a sparse file, but there was ample space: >=20 > This is likely your problem. Do NOT use a sparse file for file-backed > swap. Unfortunately making the file non-sparse did not cure the deadlock. Since it's a heavily loaded 14-processor machine it's difficult to trace every process to look for activity out of the ordinary. Kris --96YOpH+ONegL0A3E Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDKeoEWry0BWjoQKURAsKrAJ0aGSJHU+KkhBwgPK2TWqZA51i9IACfbwvi sC0ddiLlJqv3pE8FVnGxANM= =D01R -----END PGP SIGNATURE----- --96YOpH+ONegL0A3E-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 15 22:29:38 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 00DF916A41F for ; Thu, 15 Sep 2005 22:29:38 +0000 (GMT) (envelope-from minimarmot@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F01243D46 for ; Thu, 15 Sep 2005 22:29:37 +0000 (GMT) (envelope-from minimarmot@gmail.com) Received: by xproxy.gmail.com with SMTP id i27so271419wxd for ; Thu, 15 Sep 2005 15:29:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=lc7wTnFFu8GxxDby1h0BTKXFvliF4PrTcqnFULWQFVY716oCSC2dgYOfqkMJy9J4JuQ44Y19KY/HTbuaxTQw92br1grN+SeKL8uAR77SXeLeefPJAh+KcUpALsBJbLR3y5EpWNdtz8E/LjzSnMK4LWdV1BT9pmkimoNBauGwZag= Received: by 10.70.44.4 with SMTP id r4mr6579wxr; Thu, 15 Sep 2005 15:29:36 -0700 (PDT) Received: by 10.70.9.2 with HTTP; Thu, 15 Sep 2005 15:29:36 -0700 (PDT) Message-ID: <47d0403c0509151529177cf5cc@mail.gmail.com> Date: Thu, 15 Sep 2005 22:29:36 +0000 From: Ben Kaduk To: Jayton Garnett In-Reply-To: <4329DC37.4090305@codegurus.org> Mime-Version: 1.0 References: <4329DC37.4090305@codegurus.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: making custom kernel module with ndiscvt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: minimarmot@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2005 22:29:38 -0000 On 9/15/05, Jayton Garnett wrote: >=20 > Hello, >=20 > A while back I asked about my wireless card and if it will be supported > in 6.0-Release. It wont be :-( . > Anyway, I have now decided to use ndiscvt to create my own customer > kernel module for my wireless card > using the windows drivers. >=20 > I now have a file called cvwl.h and want to convert it to cvwl.ko so I > can either: > a)Compile it into the Kernel > b)load/unload it dynamically. >=20 > How would I go about creating the .ko file from the .h file? >=20 > Cheers, > Jayton > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " >=20 Have you looked at ndisgen(8)? Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Thu Sep 15 23:18:48 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4679516A41F; Thu, 15 Sep 2005 23:18:48 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5805A43D45; Thu, 15 Sep 2005 23:18:46 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id j8FNIYrR058745; Thu, 15 Sep 2005 16:18:39 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200509152318.j8FNIYrR058745@gw.catspoiler.org> Date: Thu, 15 Sep 2005 16:18:34 -0700 (PDT) From: Don Lewis To: jhb@FreeBSD.org In-Reply-To: <200509151456.50584.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org, rwatson@FreeBSD.org, current@FreeBSD.org Subject: Re: Witness patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2005 23:18:48 -0000 On 15 Sep, John Baldwin wrote: > On Friday 02 September 2005 05:37 pm, Don Lewis wrote: >> On 2 Sep, John Baldwin wrote: >> > On Thursday 01 September 2005 11:52 pm, Don Lewis wrote: >> >> I think it would make sense to print different messages for the >> >> different trigger conditions. >> > >> > Hmm, I guess I view them as all just being reversals, and that we have >> > some implicit orders that go something like this: >> > >> > sleepable locks --> Giant --> non-sleepable locks --> spin locks >> >> Attempting to lock one one of the other lock types while holding a spin >> lock already prints a unique message and results in a panic. Identifying >> the other cases of incorrect lock type ordering with a unique warning >> message eliminates the need to grovel through the source code just to >> find the types of the locks, and it indicates that looking at the output >> of "show witness" is not needed. > > Ok. I'll still list the reversal (so you know which locks are involved) but > will tailor the first line to include the implicit rule in parens if the > reversal is the result of an implicit rule. Sounds perfect to me. From owner-freebsd-current@FreeBSD.ORG Thu Sep 15 23:18:48 2005 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4679516A41F; Thu, 15 Sep 2005 23:18:48 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5805A43D45; Thu, 15 Sep 2005 23:18:46 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id j8FNIYrR058745; Thu, 15 Sep 2005 16:18:39 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200509152318.j8FNIYrR058745@gw.catspoiler.org> Date: Thu, 15 Sep 2005 16:18:34 -0700 (PDT) From: Don Lewis To: jhb@FreeBSD.org In-Reply-To: <200509151456.50584.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org, rwatson@FreeBSD.org, current@FreeBSD.org Subject: Re: Witness patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2005 23:18:48 -0000 On 15 Sep, John Baldwin wrote: > On Friday 02 September 2005 05:37 pm, Don Lewis wrote: >> On 2 Sep, John Baldwin wrote: >> > On Thursday 01 September 2005 11:52 pm, Don Lewis wrote: >> >> I think it would make sense to print different messages for the >> >> different trigger conditions. >> > >> > Hmm, I guess I view them as all just being reversals, and that we have >> > some implicit orders that go something like this: >> > >> > sleepable locks --> Giant --> non-sleepable locks --> spin locks >> >> Attempting to lock one one of the other lock types while holding a spin >> lock already prints a unique message and results in a panic. Identifying >> the other cases of incorrect lock type ordering with a unique warning >> message eliminates the need to grovel through the source code just to >> find the types of the locks, and it indicates that looking at the output >> of "show witness" is not needed. > > Ok. I'll still list the reversal (so you know which locks are involved) but > will tailor the first line to include the implicit rule in parens if the > reversal is the result of an implicit rule. Sounds perfect to me. From owner-freebsd-current@FreeBSD.ORG Fri Sep 16 01:26:04 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 281E516A425 for ; Fri, 16 Sep 2005 01:26:03 +0000 (GMT) (envelope-from rnoland@2hip.net) Received: from mailserver1.internap.com (mailserver1.internap.com [63.251.68.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5926743D46 for ; Fri, 16 Sep 2005 01:26:03 +0000 (GMT) (envelope-from rnoland@2hip.net) Received: from [24.30.90.186] (account rnoland@mail.internap.com HELO [192.168.1.101]) by mailserver1.internap.com (CommuniGate Pro SMTP 4.2.10) with ESMTP-TLS id 52456910; Thu, 15 Sep 2005 21:26:02 -0400 From: "Robert C. Noland III" To: Marcin Jessa In-Reply-To: <20050914224334.03249148.lists@yazzy.org> References: <1126734222.981.5.camel@bbeng-laptop.acs.internap.com> <20050914224334.03249148.lists@yazzy.org> Content-Type: text/plain Organization: 2 Hip Networks Date: Thu, 15 Sep 2005 21:26:00 -0400 Message-Id: <1126833960.937.3.camel@bbeng-laptop.acs.internap.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: ath_rate_sample build error? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2005 01:26:04 -0000 On Wed, 2005-09-14 at 22:43 +0000, Marcin Jessa wrote: > On Wed, 14 Sep 2005 17:43:42 -0400 > "Robert C. Noland III" wrote: > > > I'm a little confused here, as I can't figure out what change broke this > > for me. I am getting this with cvs from Tuesday morning until now. > > I just recompiled my kernel. > Worked fine for me with fresh sources for tag=RELENG_6 > This is the relevant part of my kernel config: > > # Wireless NIC cards > device wlan # 802.11 support > device wlan_wep > device wlan_ccmp > device wlan_tkip > device wlan_xauth > device wlan_acl > #device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. > > device iwi # Intel PRO/Wireless 2200BG > > #Atheros cards: > device ath > device ath_hal > #device ath_rate_onoe > #device ath_rate_amrr > device ath_rate_sample > > > > Relevant kernel config bits... > > > > # Wireless NIC cards > > device wi # WaveLAN/Intersil/Symbol 802.11 > > wireless NICs. > > device ath > > device ath_hal # Atheros HAL (includes binary > > component) > > #device ath_rate_onoe # Onoe rate control for ath driver > > #device ath_rate_amrr # AMRR rate control for ath driver > > device ath_rate_sample # SampleRate rate control for the ath > > driver > > > > device wlan # 802.11 support > > device wlan_wep # 802.11 WEP support > > device wlan_ccmp # 802.11 CCMP support > > device wlan_tkip # 802.11 TKIP support > > #device wlan_xauth # 802.11 external authenticator support > > #device wlan_acl # 802.11 MAC ACL support > > > > cc -c -O -pipe -march=pentium4m -Wall -Wredundant-decls -Wnested-externs > > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline > > -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. > > -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica > > -I/usr/src/sys/contrib/altq -D_KERNEL -include opt_global.h -fno-common > > -finline-limit=8000 --param inline-unit-growth=100 --param > > large-function-growth=1000 -mno-align-long-strings > > -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > > -mno-sse3 -ffreestanding > > -Werror /usr/src/sys/dev/ath/ath_rate/sample/sample.c > > In file included from /usr/src/sys/dev/ath/if_athvar.h:47, > > from /usr/src/sys/dev/ath/ath_rate/sample/sample.c:74: > > /usr/src/sys/contrib/dev/ath/ah.h:49:22: ah_osdep.h: No such file or > > directory > > In file included from /usr/src/sys/dev/ath/if_athvar.h:47, > > from /usr/src/sys/dev/ath/ath_rate/sample/sample.c:74: > > /usr/src/sys/contrib/dev/ath/ah.h:458: error: syntax error before > > "HAL_SOFTC" > > /usr/src/sys/contrib/dev/ath/ah.h:610: error: syntax error before > > "HAL_BUS_ADDR" > > /usr/src/sys/contrib/dev/ath/ah.h:610: warning: function declaration > > isn't a prototype > > /usr/src/sys/contrib/dev/ath/ah.h:639: error: syntax error before > > "HAL_SOFTC" > > /usr/src/sys/contrib/dev/ath/ah.h:640: warning: function declaration > > isn't a prototype > > *** Error code 1 > > > > Stop in /usr/obj/usr/src/sys/LAPTOP. > > *** Error code 1 > > > > Stop in /usr/src. > > *** Error code 1 > > > > Stop in /usr/src. > > > > robert. It looks like this was broken by rev 1.70 of src/sys/conf/kern.pre.mk can someone take a look... thanks, robert. From owner-freebsd-current@FreeBSD.ORG Fri Sep 16 02:01:01 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 600DB16A41F for ; Fri, 16 Sep 2005 02:01:01 +0000 (GMT) (envelope-from Emanuel.strobl@gmx.net) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 5782A43D45 for ; Fri, 16 Sep 2005 02:00:59 +0000 (GMT) (envelope-from Emanuel.strobl@gmx.net) Received: (qmail invoked by alias); 16 Sep 2005 02:00:58 -0000 Received: from flb.schmalzbauer.de (EHLO cale.flintsbach.schmalzbauer.de) [62.245.232.135] by mail.gmx.net (mp017) with SMTP; 16 Sep 2005 04:00:58 +0200 X-Authenticated: #301138 From: Emanuel Strobl To: freebsd-current@freebsd.org Date: Fri, 16 Sep 2005 04:00:45 +0200 User-Agent: KMail/1.8.1 References: <20050915165931.GA13872@crodrigues.org> In-Reply-To: <20050915165931.GA13872@crodrigues.org> X-Birthday: Oct. 6th 1972 X-CelPhone: +49 (0) 173 9967781 X-Tel: +49 (0) 89 18947781 X-Country: Germany X-Address: Munich, 80686 X-OS: FreeBSD MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2949595.jPeO7TuiYO"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200509160400.54289@harrymail> X-Y-GMX-Trusted: 0 Subject: Re: [RFC] Patch to add GEOM support to libdisk and sysinstall X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2005 02:01:01 -0000 --nextPart2949595.jPeO7TuiYO Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Donnerstag, 15. September 2005 18:59 CEST schrieb Craig Rodrigues: > Hi, > > I have been working on a patch to add GEOM support > to libdisk and sysinstall. These I guess this would also fix=20 http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dbin/82030 I hope not another release will include this bug! Thanks, =2DHarry > fixes allow you to label a disk which you > currently have a partition mounted on. > This is one of the "Desired features" for > the 6.0-RELEASE. I copied a lot of code > from boot0cfg and bsdlabel into libdisk. > > My code is available in Perforce on the > "rodrigc_libdisk_geom" branch. > > Also attached are patches against CURRENT CVS. > Note: my code is not in CVS yet. > > Since I am new to GEOM and disk partitioning > issues, I would appreciate any feedback. --nextPart2949595.jPeO7TuiYO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBDKidWBylq0S4AzzwRAmOnAJ9YMl2bQS6G3RsSurM5QsnyCi7q6ACgjbUc TcopP28g5cdOaBjxGHCFP04= =BM+m -----END PGP SIGNATURE----- --nextPart2949595.jPeO7TuiYO-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 16 02:52:06 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F1C216A422 for ; Fri, 16 Sep 2005 02:52:06 +0000 (GMT) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id A261C43D58 for ; Fri, 16 Sep 2005 02:52:05 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtp (Exim 4.51 (FreeBSD)) id 1EG6Kb-0008w9-6C for freebsd-current@freebsd.org; Fri, 16 Sep 2005 02:52:05 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EG6KY-000KE5-6r for freebsd-current@freebsd.org; Thu, 15 Sep 2005 16:52:02 -1000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17194.13137.807061.218023@roam.psg.com> Date: Thu, 15 Sep 2005 16:52:01 -1000 To: FreeBSD Current Subject: current kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2005 02:52:06 -0000 just cvsupped -current cc -c -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/altq -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /usr/src/sys/fs/devfs/devfs_vnops.c /usr/src/sys/fs/devfs/devfs_vnops.c:1182: warning: redundant redeclaration of 'devfs_ops_f' /usr/src/sys/fs/devfs/devfs_vnops.c:71: warning: previous declaration of 'devfs_ops_f' was here /usr/src/sys/fs/devfs/devfs_vnops.c:1193: warning: redundant redeclaration of 'devfs_vnodeops' /usr/src/sys/fs/devfs/devfs_vnops.c:69: warning: previous declaration of 'devfs_vnodeops' was here /usr/src/sys/fs/devfs/devfs_vnops.c:1215: warning: redundant redeclaration of 'devfs_specops' /usr/src/sys/fs/devfs/devfs_vnops.c:70: warning: previous declaration of 'devfs_specops' was here *** Error code 1 From owner-freebsd-current@FreeBSD.ORG Fri Sep 16 03:07:12 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D143B16A41F for ; Fri, 16 Sep 2005 03:07:12 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [204.127.198.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3155043D45 for ; Fri, 16 Sep 2005 03:07:11 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from c-66-30-115-133.hsd1.ma.comcast.net (c-66-30-112-193.hsd1.ma.comcast.net[66.30.112.193](misconfigured sender)) by comcast.net (rwcrmhc12) with ESMTP id <200509160307100140013465e>; Fri, 16 Sep 2005 03:07:10 +0000 Received: from c-66-30-112-193.hsd1.ma.comcast.net (localhost.127.in-addr.arpa [127.0.0.1]) by c-66-30-115-133.hsd1.ma.comcast.net (8.13.4/8.13.1) with ESMTP id j8G37A23018070; Thu, 15 Sep 2005 23:07:10 -0400 (EDT) (envelope-from rodrigc@c-66-30-112-193.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-66-30-112-193.hsd1.ma.comcast.net (8.13.4/8.13.1/Submit) id j8G37A72018069; Thu, 15 Sep 2005 23:07:10 -0400 (EDT) (envelope-from rodrigc) Date: Thu, 15 Sep 2005 23:07:10 -0400 From: Craig Rodrigues To: Randy Bush Message-ID: <20050916030710.GA18050@crodrigues.org> References: <17194.13137.807061.218023@roam.psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17194.13137.807061.218023@roam.psg.com> User-Agent: Mutt/1.4.2.1i Cc: FreeBSD Current Subject: Re: current kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2005 03:07:13 -0000 On Thu, Sep 15, 2005 at 04:52:01PM -1000, Randy Bush wrote: > /usr/src/sys/fs/devfs/devfs_vnops.c:1215: warning: redundant redeclaration of 'devfs_specops' > /usr/src/sys/fs/devfs/devfs_vnops.c:70: warning: previous declaration of 'devfs_specops' was here See: http://lists.freebsd.org/pipermail/freebsd-current/2005-September/055429.html -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-current@FreeBSD.ORG Fri Sep 16 03:25:15 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 421C916A41F for ; Fri, 16 Sep 2005 03:25:15 +0000 (GMT) (envelope-from root@solink.ru) Received: from ns.itam.nsc.ru (ns.itam.nsc.ru [194.226.179.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32B2043D53 for ; Fri, 16 Sep 2005 03:25:13 +0000 (GMT) (envelope-from root@solink.ru) Received: from site.lan (itut.itam.nsc.ru [194.226.179.2]) by ns.itam.nsc.ru (8.13.1/8.12.8) with ESMTP id j8G3PBN0009886; Fri, 16 Sep 2005 10:25:11 +0700 Received: from bocha.solink.office ([192.168.66.166]) (authenticated bits=0) by site.lan (8.12.11/8.12.11) with ESMTP id j8G3P6q2001777; Fri, 16 Sep 2005 10:25:06 +0700 From: Bachilo Dmitry Organization: SoLink To: minimarmot@gmail.com, freebsd-current@freebsd.org Date: Fri, 16 Sep 2005 10:25:06 +0700 User-Agent: KMail/1.8 References: <200509151735.06711.root@solink.ru> <47d0403c050915113475b8e99d@mail.gmail.com> In-Reply-To: <47d0403c050915113475b8e99d@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509161025.07217.root@solink.ru> Cc: Subject: Re: 3com wireless pccard X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2005 03:25:15 -0000 > Just type ndisgen at a root prompt and it should be fairly > self-explanatory. > Hope this solves your problem > > Ben Kaduk Thanx, Ben, it works. Actually when I read "Windows driver converter", I almost began to cry. One thing left is to make Windows User Converter and FreeBSD project would be able to begin to take over the world :-))) From owner-freebsd-current@FreeBSD.ORG Fri Sep 16 03:32:43 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9990416A41F; Fri, 16 Sep 2005 03:32:43 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 234A843D45; Fri, 16 Sep 2005 03:32:43 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j8G3VHWW041278; Thu, 15 Sep 2005 21:31:17 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 15 Sep 2005 21:31:28 -0600 (MDT) Message-Id: <20050915.213128.33791792.imp@bsdimp.com> To: jhb@freebsd.org From: "M. Warner Losh" In-Reply-To: <200509151557.11162.jhb@FreeBSD.org> References: <200509151422.04459.jhb@FreeBSD.org> <20050915202308.H75005@fledge.watson.org> <200509151557.11162.jhb@FreeBSD.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 15 Sep 2005 21:31:17 -0600 (MDT) Cc: freebsd-current@freebsd.org, rwatson@freebsd.org, dan.cojocar@gmail.com Subject: Re: LOR in /usr/src/sys/netinet/in.c:972 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2005 03:32:43 -0000 In message: <200509151557.11162.jhb@FreeBSD.org> John Baldwin writes: : > The right strategy here may in fact be to eliminate Giant acquisition by : > network device drivers... : : I'm working on that. :) /me too :-) Warner From owner-freebsd-current@FreeBSD.ORG Fri Sep 16 04:20:59 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 423BF16A41F for ; Fri, 16 Sep 2005 04:20:59 +0000 (GMT) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D53443D48 for ; Fri, 16 Sep 2005 04:20:58 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtp (Exim 4.51 (FreeBSD)) id 1EG7ic-000B7E-3a; Fri, 16 Sep 2005 04:20:58 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EG7iZ-0000Mp-89; Thu, 15 Sep 2005 18:20:55 -1000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17194.18470.737964.74091@roam.psg.com> Date: Thu, 15 Sep 2005 18:20:54 -1000 To: Craig Rodrigues References: <17194.13137.807061.218023@roam.psg.com> <20050916030710.GA18050@crodrigues.org> Cc: FreeBSD Current Subject: Re: current kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2005 04:20:59 -0000 >> /usr/src/sys/fs/devfs/devfs_vnops.c:1215: warning: redundant redeclaration of 'devfs_specops' >> /usr/src/sys/fs/devfs/devfs_vnops.c:70: warning: previous declaration of 'devfs_specops' was here > See: > http://lists.freebsd.org/pipermail/freebsd-current/2005-September/055429.html thanks. building world first worked. randy From owner-freebsd-current@FreeBSD.ORG Fri Sep 16 08:49:13 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0312816A426 for ; Fri, 16 Sep 2005 08:49:13 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B09D43D49 for ; Fri, 16 Sep 2005 08:49:03 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id j8G8mwOX015975; Fri, 16 Sep 2005 12:48:58 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id j8G8mwOT015973; Fri, 16 Sep 2005 12:48:58 +0400 (MSD) (envelope-from yar) Date: Fri, 16 Sep 2005 12:48:57 +0400 From: Yar Tikhiy To: Pyun YongHyeon Message-ID: <20050916084857.GA14782@comp.chem.msu.su> References: <47d0403c05091121047a037946@mail.gmail.com> <20050912044212.GC5182@rndsoft.co.kr> <47d0403c05091122276fd0a231@mail.gmail.com> <20050912063853.GD5182@rndsoft.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050912063853.GD5182@rndsoft.co.kr> User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org, Ben Kaduk Subject: Re: panic upon kldunload snd_ich (lor # 159) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2005 08:49:13 -0000 On Mon, Sep 12, 2005 at 03:38:53PM +0900, Pyun YongHyeon wrote: > > Your kernel and driver module should be synced. And I think you still > have missing sysmbols.(You have to use 'add-symbol-file' command as > shown in developers handbook in your kgdb session.) > > Record offset of text section within the module after loading snd_ich. > And use the offset number in kgdb session to insert symbol information. FWIW, there has been asf(8) in the base system since 5.2, which can help to avoid all the manual work of recording module offsets and issuing 'add-symbol-file' commands. -- Yar From owner-freebsd-current@FreeBSD.ORG Fri Sep 16 09:04:52 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8EDD316A41F for ; Fri, 16 Sep 2005 09:04:52 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5382743D45 for ; Fri, 16 Sep 2005 09:04:45 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id j8G94eKj017531; Fri, 16 Sep 2005 13:04:40 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id j8G94dKI017530; Fri, 16 Sep 2005 13:04:39 +0400 (MSD) (envelope-from yar) Date: Fri, 16 Sep 2005 13:04:39 +0400 From: Yar Tikhiy To: Huang wen hui Message-ID: <20050916090439.GB14782@comp.chem.msu.su> References: <4328B0D7.3090601@gddsn.org.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4328B0D7.3090601@gddsn.org.cn> User-Agent: Mutt/1.5.9i Cc: current@freebsd.org Subject: Re: Panic on CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2005 09:04:52 -0000 On Thu, Sep 15, 2005 at 07:23:03AM +0800, Huang wen hui wrote: > Got this panic from CURRENT: [...] > #8 0xc084e335 in trap (frame= > {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -1063692320, tf_esi = > -1063692320, tf_ebp = -120058940, tf_isp = -120058968, tf_ebx = > -1014159968, tf_edx = 32, tf_ecx = -1014856092, tf_eax = 4096, tf_trapno > = 12, tf_err = 2, tf_eip = -1066308142, tf_cs = 32, tf_eflags = 66050, > tf_esp = -1004422012, tf_ss = -1014159968}) at > /usr/src/sys/i386/i386/trap.c:442 > #9 0xc084069a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > #10 0xc0716dd2 in in_pcbremlists (inp=0xc38d25a0) at > /usr/src/sys/netinet/in_pcb.c:1180 Evidently, this is where the exception occured. Could you please load the kernel and the core file into kgdb again, and issue the following command: frame 10 so that we have a chance to see what actually happened there? Thanks! -- Yar From owner-freebsd-current@FreeBSD.ORG Fri Sep 16 14:37:33 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A77E116A420 for ; Fri, 16 Sep 2005 14:37:33 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F3A543D55 for ; Fri, 16 Sep 2005 14:37:32 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: (qmail 38738 invoked by uid 89); 16 Sep 2005 14:36:07 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 16 Sep 2005 14:36:07 -0000 Date: Fri, 16 Sep 2005 16:37:26 +0200 From: Oliver Lehmann To: Kris Kennaway Message-Id: <20050916163726.729ada59.lehmann@ans-netz.de> In-Reply-To: <20050915213719.GA26998@xor.obsecurity.org> References: <20050914194612.15692485.lehmann@ans-netz.de> <43286E37.40203@samsco.org> <20050914222013.178dc4dc.lehmann@ans-netz.de> <84dead72050914135239514c49@mail.gmail.com> <20050915000053.448f251b.lehmann@ans-netz.de> <84dead7205091500152a7c25d1@mail.gmail.com> <20050915172005.072f4bdf.lehmann@ans-netz.de> <20050915181238.54b16b4b.lehmann@ans-netz.de> <20050915213719.GA26998@xor.obsecurity.org> X-Mailer: Sylpheed version 2.0.1 (GTK+ 2.6.10; amd64-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: low(er) disk performance with sched_4bsd then with sched_ule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2005 14:37:33 -0000 Hi Kris, Kris Kennaway wrote: > What about using schedgraph as I suggested previously? After I installed py24-tkinter and all the dependencies, I recompiled the kernel and so on, but it seems not to work: root@nudel olivleh1> dd if=/dev/zero of=/mnt/files/test.dd bs=64k count=32000 32000+0 records in 32000+0 records out 2097152000 bytes transferred in 379.623777 secs (5524290 bytes/sec) root@nudel olivleh1> ktrdump -ct > ule.ktr.out root@nudel olivleh1> grep ULE /usr/src/sys/i386/conf/NUDEL options SCHED_ULE root@nudel olivleh1> python /mnt/files/FreeBSD/6.0/src/tools/sched/schedgraph.py ule.ktr.out Traceback (most recent call last): File "/mnt/files/FreeBSD/6.0/src/tools/sched/schedgraph.py", line 1224, in ? graph = SchedGraph(root) File "/mnt/files/FreeBSD/6.0/src/tools/sched/schedgraph.py", line 1168, in __init__ self.draw(sys.argv[1]) File "/mnt/files/FreeBSD/6.0/src/tools/sched/schedgraph.py", line 1201, in draw ktrfile = KTRFile(file) File "/mnt/files/FreeBSD/6.0/src/tools/sched/schedgraph.py", line 822, in __init__ ticksps = self.ticksps() File "/mnt/files/FreeBSD/6.0/src/tools/sched/schedgraph.py", line 911, in ticksps return (self.timespan() / self.ticks[0]) * int(self.stathz) File "/mnt/files/FreeBSD/6.0/src/tools/sched/schedgraph.py", line 908, in timespan return (self.timestamp_first - self.timestamp_last); TypeError: unsupported operand type(s) for -: 'NoneType' and 'NoneType' Exit 1 root@nudel olivleh1> -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-current@FreeBSD.ORG Fri Sep 16 15:24:04 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5258016A41F for ; Fri, 16 Sep 2005 15:24:04 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fileserver.fields.utoronto.ca (fileserver.fields.utoronto.ca [128.100.216.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76B8143D69 for ; Fri, 16 Sep 2005 15:23:50 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fields.fields.utoronto.ca (fields.localdomain [192.168.216.11]) by fileserver.fields.utoronto.ca (8.12.8/8.12.8/Fields 6.0) with ESMTP id j8GFNm0r007666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Sep 2005 11:23:48 -0400 Received: from obsecurity.dyndns.org (localhost.localdomain [127.0.0.1]) by fields.fields.utoronto.ca (8.12.8/8.12.8/Fields WS 6.0) with ESMTP id j8GFNl6P023692; Fri, 16 Sep 2005 11:23:47 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id BEDAC51545; Fri, 16 Sep 2005 11:23:46 -0400 (EDT) Date: Fri, 16 Sep 2005 11:23:46 -0400 From: Kris Kennaway To: Oliver Lehmann Message-ID: <20050916152346.GA27708@xor.obsecurity.org> References: <20050914194612.15692485.lehmann@ans-netz.de> <43286E37.40203@samsco.org> <20050914222013.178dc4dc.lehmann@ans-netz.de> <84dead72050914135239514c49@mail.gmail.com> <20050915000053.448f251b.lehmann@ans-netz.de> <84dead7205091500152a7c25d1@mail.gmail.com> <20050915172005.072f4bdf.lehmann@ans-netz.de> <20050915181238.54b16b4b.lehmann@ans-netz.de> <20050915213719.GA26998@xor.obsecurity.org> <20050916163726.729ada59.lehmann@ans-netz.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/04w6evG8XlLl3ft" Content-Disposition: inline In-Reply-To: <20050916163726.729ada59.lehmann@ans-netz.de> User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org, Kris Kennaway Subject: Re: low(er) disk performance with sched_4bsd then with sched_ule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2005 15:24:04 -0000 --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 16, 2005 at 04:37:26PM +0200, Oliver Lehmann wrote: > Hi Kris, >=20 > Kris Kennaway wrote: >=20 > > What about using schedgraph as I suggested previously? >=20 > After I installed py24-tkinter and all the dependencies, I recompiled the= kernel and so on, but it seems not to work: >=20 > root@nudel olivleh1> dd if=3D/dev/zero of=3D/mnt/files/test.dd bs=3D64k c= ount=3D32000 > 32000+0 records in > 32000+0 records out > 2097152000 bytes transferred in 379.623777 secs (5524290 bytes/sec) > root@nudel olivleh1> ktrdump -ct > ule.ktr.out > root@nudel olivleh1> grep ULE /usr/src/sys/i386/conf/NUDEL=20 > options SCHED_ULE And you enabled the correct KTR options in your kernel, right? Kris --/04w6evG8XlLl3ft Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDKuOCWry0BWjoQKURAse4AKDWbvjtmPiSFqvYOLdNczqoBd318QCeNVaQ +4JyiI935NVVrBFnBXIrfDw= =CFoY -----END PGP SIGNATURE----- --/04w6evG8XlLl3ft-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 16 15:39:36 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D4D9916A41F for ; Fri, 16 Sep 2005 15:39:36 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE65143D46 for ; Fri, 16 Sep 2005 15:39:35 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: (qmail 40134 invoked by uid 89); 16 Sep 2005 15:38:12 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 16 Sep 2005 15:38:12 -0000 Date: Fri, 16 Sep 2005 17:39:32 +0200 From: Oliver Lehmann To: Kris Kennaway Message-Id: <20050916173932.78a74896.lehmann@ans-netz.de> In-Reply-To: <20050916152346.GA27708@xor.obsecurity.org> References: <20050914194612.15692485.lehmann@ans-netz.de> <43286E37.40203@samsco.org> <20050914222013.178dc4dc.lehmann@ans-netz.de> <84dead72050914135239514c49@mail.gmail.com> <20050915000053.448f251b.lehmann@ans-netz.de> <84dead7205091500152a7c25d1@mail.gmail.com> <20050915172005.072f4bdf.lehmann@ans-netz.de> <20050915181238.54b16b4b.lehmann@ans-netz.de> <20050915213719.GA26998@xor.obsecurity.org> <20050916163726.729ada59.lehmann@ans-netz.de> <20050916152346.GA27708@xor.obsecurity.org> X-Mailer: Sylpheed version 2.0.1 (GTK+ 2.6.10; amd64-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: low(er) disk performance with sched_4bsd then with sched_ule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2005 15:39:36 -0000 Kris Kennaway wrote: > And you enabled the correct KTR options in your kernel, right? options KTR options KTR_COMPILE=KTR_SCHED options KTR_MASK options KTR_ENTRIES=32768 I hope these are the correct ones -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-current@FreeBSD.ORG Fri Sep 16 15:42:19 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE84116A41F for ; Fri, 16 Sep 2005 15:42:19 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fileserver.fields.utoronto.ca (fileserver.fields.utoronto.ca [128.100.216.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 40FC643D45 for ; Fri, 16 Sep 2005 15:42:19 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fields.fields.utoronto.ca (fields.localdomain [192.168.216.11]) by fileserver.fields.utoronto.ca (8.12.8/8.12.8/Fields 6.0) with ESMTP id j8GFgH0r009166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Sep 2005 11:42:17 -0400 Received: from obsecurity.dyndns.org (localhost.localdomain [127.0.0.1]) by fields.fields.utoronto.ca (8.12.8/8.12.8/Fields WS 6.0) with ESMTP id j8GFgH6P025725; Fri, 16 Sep 2005 11:42:17 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id ABFEB51251; Fri, 16 Sep 2005 11:42:16 -0400 (EDT) Date: Fri, 16 Sep 2005 11:42:16 -0400 From: Kris Kennaway To: Oliver Lehmann Message-ID: <20050916154216.GA28028@xor.obsecurity.org> References: <20050914222013.178dc4dc.lehmann@ans-netz.de> <84dead72050914135239514c49@mail.gmail.com> <20050915000053.448f251b.lehmann@ans-netz.de> <84dead7205091500152a7c25d1@mail.gmail.com> <20050915172005.072f4bdf.lehmann@ans-netz.de> <20050915181238.54b16b4b.lehmann@ans-netz.de> <20050915213719.GA26998@xor.obsecurity.org> <20050916163726.729ada59.lehmann@ans-netz.de> <20050916152346.GA27708@xor.obsecurity.org> <20050916173932.78a74896.lehmann@ans-netz.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EeQfGwPcQSOJBaQU" Content-Disposition: inline In-Reply-To: <20050916173932.78a74896.lehmann@ans-netz.de> User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org, Kris Kennaway Subject: Re: low(er) disk performance with sched_4bsd then with sched_ule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2005 15:42:19 -0000 --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 16, 2005 at 05:39:32PM +0200, Oliver Lehmann wrote: > Kris Kennaway wrote: >=20 > > And you enabled the correct KTR options in your kernel, right? >=20 > options KTR > options KTR_COMPILE=3DKTR_SCHED > options KTR_MASK options KTR_MASK=3DKTR_SCHED, per the instructions in schedgraph.py Kris --EeQfGwPcQSOJBaQU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDKufYWry0BWjoQKURArX9AJ9GxzZKMddRpKRXgfCf2Ub7pdY4KwCfcSXx quQnZnzpmx8UoEQeKl+cV8Q= =B+T/ -----END PGP SIGNATURE----- --EeQfGwPcQSOJBaQU-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 16 15:44:34 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB6FA16A41F for ; Fri, 16 Sep 2005 15:44:34 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1B4843D46 for ; Fri, 16 Sep 2005 15:44:33 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: (qmail 40293 invoked by uid 89); 16 Sep 2005 15:43:10 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 16 Sep 2005 15:43:10 -0000 Date: Fri, 16 Sep 2005 17:44:31 +0200 From: Oliver Lehmann To: Kris Kennaway Message-Id: <20050916174431.798e5d1c.lehmann@ans-netz.de> In-Reply-To: <20050916154216.GA28028@xor.obsecurity.org> References: <20050914222013.178dc4dc.lehmann@ans-netz.de> <84dead72050914135239514c49@mail.gmail.com> <20050915000053.448f251b.lehmann@ans-netz.de> <84dead7205091500152a7c25d1@mail.gmail.com> <20050915172005.072f4bdf.lehmann@ans-netz.de> <20050915181238.54b16b4b.lehmann@ans-netz.de> <20050915213719.GA26998@xor.obsecurity.org> <20050916163726.729ada59.lehmann@ans-netz.de> <20050916152346.GA27708@xor.obsecurity.org> <20050916173932.78a74896.lehmann@ans-netz.de> <20050916154216.GA28028@xor.obsecurity.org> X-Mailer: Sylpheed version 2.0.1 (GTK+ 2.6.10; amd64-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: low(er) disk performance with sched_4bsd then with sched_ule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2005 15:44:34 -0000 Kris Kennaway wrote: > On Fri, Sep 16, 2005 at 05:39:32PM +0200, Oliver Lehmann wrote: > > Kris Kennaway wrote: > > > > > And you enabled the correct KTR options in your kernel, right? > > > > options KTR > > options KTR_COMPILE=KTR_SCHED > > options KTR_MASK > > options KTR_MASK=KTR_SCHED, per the instructions in schedgraph.py "Add KTR_SCHED to KTR_COMPILE and KTR_MASK in your KERNCONF" would be easier to parse if exaclty would be written down what should be placed into KERNCONF instead of describing it :/ -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-current@FreeBSD.ORG Fri Sep 16 15:47:29 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E602B16A41F for ; Fri, 16 Sep 2005 15:47:29 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fileserver.fields.utoronto.ca (fileserver.fields.utoronto.ca [128.100.216.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 677FD43D45 for ; Fri, 16 Sep 2005 15:47:29 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fields.fields.utoronto.ca (fields.localdomain [192.168.216.11]) by fileserver.fields.utoronto.ca (8.12.8/8.12.8/Fields 6.0) with ESMTP id j8GFlR0r009639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Sep 2005 11:47:27 -0400 Received: from obsecurity.dyndns.org (localhost.localdomain [127.0.0.1]) by fields.fields.utoronto.ca (8.12.8/8.12.8/Fields WS 6.0) with ESMTP id j8GFlR6P026291; Fri, 16 Sep 2005 11:47:27 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id BCDE951251; Fri, 16 Sep 2005 11:47:26 -0400 (EDT) Date: Fri, 16 Sep 2005 11:47:26 -0400 From: Kris Kennaway To: Oliver Lehmann Message-ID: <20050916154726.GA28275@xor.obsecurity.org> References: <20050915000053.448f251b.lehmann@ans-netz.de> <84dead7205091500152a7c25d1@mail.gmail.com> <20050915172005.072f4bdf.lehmann@ans-netz.de> <20050915181238.54b16b4b.lehmann@ans-netz.de> <20050915213719.GA26998@xor.obsecurity.org> <20050916163726.729ada59.lehmann@ans-netz.de> <20050916152346.GA27708@xor.obsecurity.org> <20050916173932.78a74896.lehmann@ans-netz.de> <20050916154216.GA28028@xor.obsecurity.org> <20050916174431.798e5d1c.lehmann@ans-netz.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="huq684BweRXVnRxX" Content-Disposition: inline In-Reply-To: <20050916174431.798e5d1c.lehmann@ans-netz.de> User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org, Kris Kennaway Subject: Re: low(er) disk performance with sched_4bsd then with sched_ule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2005 15:47:30 -0000 --huq684BweRXVnRxX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 16, 2005 at 05:44:31PM +0200, Oliver Lehmann wrote: > Kris Kennaway wrote: >=20 > > On Fri, Sep 16, 2005 at 05:39:32PM +0200, Oliver Lehmann wrote: > > > Kris Kennaway wrote: > > >=20 > > > > And you enabled the correct KTR options in your kernel, right? > > >=20 > > > options KTR > > > options KTR_COMPILE=3DKTR_SCHED > > > options KTR_MASK > >=20 > > options KTR_MASK=3DKTR_SCHED, per the instructions in schedgraph.py >=20 > "Add KTR_SCHED to KTR_COMPILE and KTR_MASK in your KERNCONF" would be > easier to parse if exaclty would be written down what should be placed > into KERNCONF instead of describing it :/ It should be parsed as "Add KTR_SCHED to (KTR_COMPILE and KTR_MASK) ..." Since the user may already have ktr configured with other events, this is about the best you can do. See the ktr manpage for more documentation if you need it. Kris --huq684BweRXVnRxX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDKukOWry0BWjoQKURAl9lAJ0cirqqb0EOd7T+c/6WwxHY82TLNwCfdoKN LpG/pYQplREpF8SvbxUiaV4= =73Op -----END PGP SIGNATURE----- --huq684BweRXVnRxX-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 16 16:21:23 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 20BDF16A41F for ; Fri, 16 Sep 2005 16:21:23 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3407743D49 for ; Fri, 16 Sep 2005 16:21:22 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by xproxy.gmail.com with SMTP id i31so723142wxd for ; Fri, 16 Sep 2005 09:21:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=emqLnBMhcyhIb9t1ItU6UDCuuZ0OeSwWuGtSVRgtw20rfX/bgBuD2UxKWApjW54L5N8ZXKnwVYxaBl5/phgjadvNv3XwJp12WympbkpxRUwwwHZFO7sGJ2gfwIKX8CVwIwt36eIdGBTNN/17x91id1dqSKgTxkG7NbvoHXZ2M4M= Received: by 10.70.117.2 with SMTP id p2mr243087wxc; Fri, 16 Sep 2005 09:21:21 -0700 (PDT) Received: by 10.70.115.15 with HTTP; Fri, 16 Sep 2005 09:21:21 -0700 (PDT) Message-ID: <84dead720509160921732e7f96@mail.gmail.com> Date: Fri, 16 Sep 2005 21:51:21 +0530 From: Joseph Koshy To: Oliver Lehmann In-Reply-To: <20050915181238.54b16b4b.lehmann@ans-netz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050914194612.15692485.lehmann@ans-netz.de> <43286E37.40203@samsco.org> <20050914222013.178dc4dc.lehmann@ans-netz.de> <84dead72050914135239514c49@mail.gmail.com> <20050915000053.448f251b.lehmann@ans-netz.de> <84dead7205091500152a7c25d1@mail.gmail.com> <20050915172005.072f4bdf.lehmann@ans-netz.de> <20050915181238.54b16b4b.lehmann@ans-netz.de> Cc: current@freebsd.org Subject: Re: low(er) disk performance with sched_4bsd then with sched_ule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: joseph.koshy@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2005 16:21:23 -0000 jk> What happens if you use a kernel with 'options=20 jk> NO_ADAPTIVE_MUTEXES' ? ol> Hmm, that made it more worse ol> http://pofo.de/tmp/gprof.4bsd.2 >From the profile it appears that with adaptive mutexes turned off the kernel is spinning inside vm_pageout(). 41.1 vm_pageout [1] 25.0 _mtx_trylock [2] 5.1 smp_tlb_shootdown [3] Hmm ... the dd command line *did* ask for about approx 2 GB of zero-filled memory from the kernel while the machine has about 640M. I'm just not able to reproduce this kind of skewed profile on -current on a uniprocessor amd64 and on a P4 HT machine. Just as an off-chance: how upto-date is your kernel? In=20 particular, do you have the following fix:=20 "sys/vm/vm_pager.c:" revision 1.105.2.1 date: 2005/08/15 14:04:47; author: kan; state: Exp; lines: +1 -0 MFC: Do not use vm_pager_init() to initialize=20 vnode_pbuf_freecnt variable. vm_pager_init() is run before=20 required nswbuf variable has been set to correct value. This=20 caused system to run with single pbuf available for=20 vnode_pager. Handle both cluster_pbuf_freecnt and=20 node_pbuf_freecnt variableis in the same way. --=20 FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-current@FreeBSD.ORG Fri Sep 16 16:28:31 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D83016A41F for ; Fri, 16 Sep 2005 16:28:31 +0000 (GMT) (envelope-from bobself@charter.net) Received: from mxsf18.cluster1.charter.net (mxsf18.cluster1.charter.net [209.225.28.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 779EF43D5C for ; Fri, 16 Sep 2005 16:28:27 +0000 (GMT) (envelope-from bobself@charter.net) Received: from mxip26a.cluster1.charter.net (mxip26a.cluster1.charter.net [209.225.28.181]) by mxsf18.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id j8GGSP3F011435 for ; Fri, 16 Sep 2005 12:28:25 -0400 Received: from 24-177-225-234.dhcp.spbg.sc.charter.com (HELO [127.0.0.1]) ([24.177.225.234]) by mxip26a.cluster1.charter.net with ESMTP; 16 Sep 2005 12:28:25 -0400 X-IronPort-AV: i="3.97,117,1125892800"; d="scan'208"; a="207803283:sNHT14792024" Message-ID: <432AF297.80203@charter.net> Date: Fri, 16 Sep 2005 12:28:07 -0400 From: bob self User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: can't run wine anymore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2005 16:28:31 -0000 I'm running 6.0 beta 4 and after doing a nightly portupgrade a couple of nights ago I can no longer run wine. Six ports upgraded sucessfully, including xorg-server. I get this message now when I run wine: X Error of failed request: BadAlloc (insufficient resources for operation) Major opcode of failed request: 53 (X_CreatePixmap) Serial number of failed request: 12785 Current serial number in output stream: 12787 X Error of failed request: BadAlloc (insufficient resources for operation) Major opcode of failed request: 53 (X_CreatePixmap) Serial number of failed request: 12785 Current serial number in output stream: 12787 Does anyone know what this means or what is causing it? thanks, Bob From owner-freebsd-current@FreeBSD.ORG Fri Sep 16 16:29:33 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 788AD16A41F for ; Fri, 16 Sep 2005 16:29:33 +0000 (GMT) (envelope-from joao.barros@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1216843D66 for ; Fri, 16 Sep 2005 16:29:23 +0000 (GMT) (envelope-from joao.barros@gmail.com) Received: by xproxy.gmail.com with SMTP id i27so214285wxd for ; Fri, 16 Sep 2005 09:29:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=oaFowru0MjUam5S+SuVOAQy3Ic75PFNn1spWu5E+ELGTkYofVcdeh48uCVGNMWrC/wpnMOxF46IbMyTzbMRC4Lxy+GDi/F8wNeauHVDNb+YpwOCvQ5p5O5xEPEckaEqRoY84Dm1VA80ZUKqNnccIueckE2Q4Ct1D+4GgnQCV/K8= Received: by 10.70.20.10 with SMTP id 10mr161027wxt; Fri, 16 Sep 2005 09:29:23 -0700 (PDT) Received: by 10.70.10.5 with HTTP; Fri, 16 Sep 2005 09:29:23 -0700 (PDT) Message-ID: <70e8236f050916092979979613@mail.gmail.com> Date: Fri, 16 Sep 2005 17:29:23 +0100 From: Joao Barros To: Scott Long In-Reply-To: <4327DC81.7040903@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1126683752.4306.6.camel@massimo.datacode.it> <4327DC81.7040903@samsco.org> Cc: Massimo , freebsd-current@freebsd.org Subject: Re: raid framework from OpenBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: joao.barros@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2005 16:29:33 -0000 On 9/14/05, Scott Long wrote: > Massimo wrote: > > I would like to know what do you think about new OpenBSD raid framework > > management. > > http://marc.theaimsgroup.com/?l=3Dopenbsd-misc&m=3D112630095818062 > > > > Doesn't it seems good stuff which is good for consideration? > > > > Regards. >=20 > Creating a unified management tool for multiple RAID architectures has > been a Holy Grail for at least 10 years, if not longer. It's > deceptively hard, though. While it sounds straight-forward and is > relatively easy to do for 1 or 2 architectures, the vast differences in > how different architectures work makes it quickly turn into a huge mess. > This is especially true when it comes to topology discovery and > management and asynchronous event notification. Often times the only > course is to degrade to a very simple, lowest common denominator > interface, which then starts to limit the usefulness of the tool. I've > been involved in several professional projects in exactly this area, and > it simply is very, very hard to do well. The OpenBSD work looks > interesting, but unless they can demostrate useful operation on more > than 1 or 2 architectures, it's not terribly impressive. That's not to > say that it can't be done and be a success, but the amount of required > effort should not be underestimated. It's relatively easy to come up > with a framework and implement one architecture module in it, then tell > everyone else to simply add more modules. >=20 > Also, it's not clear from the email whether the tool has to be manually > told to rescan and look for changes in the state of the array (not just > SES/SAFTE changes of the component drives). Displaying status on demand > is fine, but what admin sits in front of their terminal and refreshes > their monitoring apps every 5 seconds? The key is to have a an event > notification pipeline that can collect events in near real time, filter > them in a configurable way, and send out email/pager alerts when > appropriate. Also, what does this mean for a datacenter full of > machines that need to be monitored? Does a remote terminal session need > to be opened on each one in order for monitoring to work? >=20 > But, even if this particular work degrades into only being a tool for > AMI (I assume they mean MegaRAID) controllers, it's still useful and I > give them credit for doing it. Having an amr I'm most interested in this, as I guess more people are. Given that there is "customer" interest, my question is: is there interest from you in this, having it imported to FreeBSD? I've looked at the code and I wouldn't mind starting to work on this. -- Joao Barros From owner-freebsd-current@FreeBSD.ORG Fri Sep 16 16:49:15 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 653DD16A41F for ; Fri, 16 Sep 2005 16:49:15 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F77F43D46 for ; Fri, 16 Sep 2005 16:49:14 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: (qmail 41770 invoked by uid 89); 16 Sep 2005 16:47:50 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 16 Sep 2005 16:47:50 -0000 Date: Fri, 16 Sep 2005 18:49:11 +0200 From: Oliver Lehmann To: joseph.koshy@gmail.com Message-Id: <20050916184911.38e2739a.lehmann@ans-netz.de> In-Reply-To: <84dead720509160921732e7f96@mail.gmail.com> References: <20050914194612.15692485.lehmann@ans-netz.de> <43286E37.40203@samsco.org> <20050914222013.178dc4dc.lehmann@ans-netz.de> <84dead72050914135239514c49@mail.gmail.com> <20050915000053.448f251b.lehmann@ans-netz.de> <84dead7205091500152a7c25d1@mail.gmail.com> <20050915172005.072f4bdf.lehmann@ans-netz.de> <20050915181238.54b16b4b.lehmann@ans-netz.de> <84dead720509160921732e7f96@mail.gmail.com> X-Mailer: Sylpheed version 2.0.1 (GTK+ 2.6.10; amd64-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: low(er) disk performance with sched_4bsd then with sched_ule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2005 16:49:15 -0000 Joseph Koshy wrote: > I'm just not able to reproduce this kind of skewed > profile on -current on a uniprocessor amd64 and > on a P4 HT machine. I remember that when I tried w/o SMP it was much faster with 4bsd then it was with SMP (4BSd-UP was about the same as ULE with SMP). That was the point why I tried SMP with ULE - because I hoped to get the performance back I lost with switching from UP to SMP with 4BSD. > Just as an off-chance: how upto-date is your kernel? In > particular, do you have the following fix: > > "sys/vm/vm_pager.c:" > revision 1.105.2.1 I've 1.105 - I'll cvsup my 6_RELENG and report back if anything changed. -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-current@FreeBSD.ORG Fri Sep 16 17:53:37 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C36A316A420 for ; Fri, 16 Sep 2005 17:53:37 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD5F643D45 for ; Fri, 16 Sep 2005 17:53:36 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id j8GHrUhp007943; Fri, 16 Sep 2005 11:53:30 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <432B069E.8000104@samsco.org> Date: Fri, 16 Sep 2005 11:53:34 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: joao.barros@gmail.com References: <1126683752.4306.6.camel@massimo.datacode.it> <4327DC81.7040903@samsco.org> <70e8236f050916092979979613@mail.gmail.com> In-Reply-To: <70e8236f050916092979979613@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: Massimo , freebsd-current@freebsd.org Subject: Re: raid framework from OpenBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2005 17:53:38 -0000 Joao Barros wrote: > On 9/14/05, Scott Long wrote: > >>Massimo wrote: >> >>>I would like to know what do you think about new OpenBSD raid framework >>>management. >>>http://marc.theaimsgroup.com/?l=openbsd-misc&m=112630095818062 >>> >>>Doesn't it seems good stuff which is good for consideration? >>> >>>Regards. >> >>Creating a unified management tool for multiple RAID architectures has >>been a Holy Grail for at least 10 years, if not longer. It's >>deceptively hard, though. While it sounds straight-forward and is >>relatively easy to do for 1 or 2 architectures, the vast differences in >>how different architectures work makes it quickly turn into a huge mess. >>This is especially true when it comes to topology discovery and >>management and asynchronous event notification. Often times the only >>course is to degrade to a very simple, lowest common denominator >>interface, which then starts to limit the usefulness of the tool. I've >>been involved in several professional projects in exactly this area, and >>it simply is very, very hard to do well. The OpenBSD work looks >>interesting, but unless they can demostrate useful operation on more >>than 1 or 2 architectures, it's not terribly impressive. That's not to >>say that it can't be done and be a success, but the amount of required >>effort should not be underestimated. It's relatively easy to come up >>with a framework and implement one architecture module in it, then tell >>everyone else to simply add more modules. >> >>Also, it's not clear from the email whether the tool has to be manually >>told to rescan and look for changes in the state of the array (not just >>SES/SAFTE changes of the component drives). Displaying status on demand >>is fine, but what admin sits in front of their terminal and refreshes >>their monitoring apps every 5 seconds? The key is to have a an event >>notification pipeline that can collect events in near real time, filter >>them in a configurable way, and send out email/pager alerts when >>appropriate. Also, what does this mean for a datacenter full of >>machines that need to be monitored? Does a remote terminal session need >>to be opened on each one in order for monitoring to work? >> >>But, even if this particular work degrades into only being a tool for >>AMI (I assume they mean MegaRAID) controllers, it's still useful and I >>give them credit for doing it. > > > Having an amr I'm most interested in this, as I guess more people are. > Given that there is "customer" interest, my question is: is there > interest from you in this, having it imported to FreeBSD? > I've looked at the code and I wouldn't mind starting to work on this. > > -- > Joao Barros Give it a try if you're interested. Scott From owner-freebsd-current@FreeBSD.ORG Fri Sep 16 19:17:27 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F22416A422 for ; Fri, 16 Sep 2005 19:17:27 +0000 (GMT) (envelope-from Emanuel.strobl@gmx.net) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 457FA43D45 for ; Fri, 16 Sep 2005 19:17:25 +0000 (GMT) (envelope-from Emanuel.strobl@gmx.net) Received: (qmail invoked by alias); 16 Sep 2005 19:17:24 -0000 Received: from flb.schmalzbauer.de (EHLO cale.flintsbach.schmalzbauer.de) [62.245.232.135] by mail.gmx.net (mp016) with SMTP; 16 Sep 2005 21:17:24 +0200 X-Authenticated: #301138 From: Emanuel Strobl To: freebsd-current@freebsd.org Date: Fri, 16 Sep 2005 21:17:06 +0200 User-Agent: KMail/1.8.1 X-Birthday: Oct. 6th 1972 X-CelPhone: +49 (0) 173 9967781 X-Tel: +49 (0) 89 18947781 X-Country: Germany X-Address: Munich, 80686 X-OS: FreeBSD MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart9531054.Gs3dyNyUNE"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200509162117.17787@harrymail> X-Y-GMX-Trusted: 0 Subject: powerd (cpufreq) problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2005 19:17:27 -0000 --nextPart9531054.Gs3dyNyUNE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, I noticed that whenever my notebook (VAIO SRX41p, BETA4) crashed, powerd=20 prints the following error after reboot: acpi_perf0: Px transition to 500 failed acpi_perf0: set freq failed, err 6 I can't solve that state, no shutdown/reboot will fix it. _But_, if I boot= =20 XP and reboot everything is fine again. I don't have problems if I do a clean shutdown and reboot FreeBSD. There seems to be something in an invalid state while powerd is running=20 which powerd corrects at exit. Can I provide any useful info to get this fixed? I'm not planning to leave= =20 XP on that machine just because I need it to "reset" cpufreq related=20 stuff ;) Thanks, =2DHarry --nextPart9531054.Gs3dyNyUNE Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBDKxo9Bylq0S4AzzwRAqkmAJ0YYrUG2SitpEwpyiaucAw54dwTCgCfb8zJ 2Dx4mjtINi1xlvkAR3jL1NY= =xXeK -----END PGP SIGNATURE----- --nextPart9531054.Gs3dyNyUNE-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 16 19:33:49 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2411516A41F; Fri, 16 Sep 2005 19:33:49 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id B1C6E43D45; Fri, 16 Sep 2005 19:33:48 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.3/8.13.3) with ESMTP id j8GJXkNQ024443; Fri, 16 Sep 2005 15:33:46 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.3/8.13.3) with ESMTP id j8GJXlC9029475; Fri, 16 Sep 2005 15:33:47 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 21CAE7302F; Fri, 16 Sep 2005 15:33:47 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050916193347.21CAE7302F@freebsd-current.sentex.ca> Date: Fri, 16 Sep 2005 15:33:47 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.86, clamav-milter version 0.86 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on alpha/alpha X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2005 19:33:49 -0000 TB --- 2005-09-16 18:02:46 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-09-16 18:02:46 - starting HEAD tinderbox run for alpha/alpha TB --- 2005-09-16 18:02:46 - cleaning the object tree TB --- 2005-09-16 18:03:07 - checking out the source tree TB --- 2005-09-16 18:03:07 - cd /tinderbox/HEAD/alpha/alpha TB --- 2005-09-16 18:03:07 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-09-16 18:08:59 - building world (CFLAGS=-O2 -pipe) TB --- 2005-09-16 18:08:59 - cd /src TB --- 2005-09-16 18:08:59 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2005-09-16 19:12:25 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-09-16 19:12:25 - cd /src TB --- 2005-09-16 19:12:25 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Sep 16 19:12:25 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Fri Sep 16 19:25:38 UTC 2005 TB --- 2005-09-16 19:25:38 - generating LINT kernel config TB --- 2005-09-16 19:25:38 - cd /src/sys/alpha/conf TB --- 2005-09-16 19:25:38 - /usr/bin/make -B LINT TB --- 2005-09-16 19:25:38 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-09-16 19:25:38 - cd /src TB --- 2005-09-16 19:25:38 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Sep 16 19:25:38 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/net/if_spppsubr.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/net/if_stf.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/net/if_tun.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/net/if_tap.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/net/if_vlan.c /src/sys/net/if_vlan.c: In function `vlan_start': /src/sys/net/if_vlan.c:540: warning: format argument is not a pointer (arg 2) /src/sys/net/if_vlan.c:540: warning: field width is not type int (arg 3) *** Error code 1 Stop in /obj/alpha/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-09-16 19:33:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-09-16 19:33:46 - ERROR: failed to build lint kernel TB --- 2005-09-16 19:33:46 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Sep 16 20:24:00 2005 Return-Path: X-Original-To: Freebsd-current@FreeBSD.org Delivered-To: Freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2889116A41F for ; Fri, 16 Sep 2005 20:24:00 +0000 (GMT) (envelope-from pbowen@fastmail.fm) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87CD743D72 for ; Fri, 16 Sep 2005 20:23:52 +0000 (GMT) (envelope-from pbowen@fastmail.fm) Received: from frontend1.internal (mysql-sessions.internal [10.202.2.149]) by frontend1.messagingengine.com (Postfix) with ESMTP id ACA58CCFD2E for ; Fri, 16 Sep 2005 16:23:50 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.151]) by frontend1.internal (MEProxy); Fri, 16 Sep 2005 16:23:50 -0400 X-Sasl-enc: fDgSpcWQRg8Tmuzr0xWu6YCb/8Ma8QfbhPUsmq4SDxa14ecK/fM 1126902228 Received: from [192.168.214.123] (unknown [12.43.65.66]) by frontend2.messagingengine.com (Postfix) with ESMTP id 36B49570360 for ; Fri, 16 Sep 2005 16:23:47 -0400 (EDT) Message-ID: <432B2985.50302@fastmail.fm> Date: Fri, 16 Sep 2005 15:22:29 -0500 From: Patrick Bowen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041221 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Freebsd-current@FreeBSD.org References: <1126047871.687.1.camel@localhost> <4328D0F7.2090501@fastmail.fm> <2B22BF98-3FF4-4BE5-B8FF-56BB07CDB4D9@FreeBSD.org> In-Reply-To: <2B22BF98-3FF4-4BE5-B8FF-56BB07CDB4D9@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: Re: ATA error on 6.0-BETA4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2005 20:24:00 -0000 Søren Schmidt wrote: > On 15/09/2005, at 3:40, Patrick Bowen wrote: > >> I've notice the same behaviour on my Dell C600. I've attached >> verbose dmesg's for -current and 5.4. When I boot 5.4 the CD-RW is >> found and I have no problems using it for either reading or writing. >> I hope they're useful for you. > > > OK, please try the below patch and let me know if that helps any. > >> I'd like to say that I have the greatest respect for *all* of you >> that work at making FreeBSD the great OS that it is. I just wonder >> where you find the time to work on it, what with your day jobs, >> family responsibilities and all... > > > I guess we have understanding environments and need for less sleep > than usual :) > > Index: ata-lowlevel.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/ata/ata-lowlevel.c,v > retrieving revision 1.71 > diff -u -r1.71 ata-lowlevel.c > --- ata-lowlevel.c 14 Sep 2005 12:45:06 -0000 1.71 > +++ ata-lowlevel.c 15 Sep 2005 07:35:41 -0000 > @@ -278,7 +278,7 @@ > /* if read data get it */ > if (request->flags & ATA_R_READ) { > - if (ata_wait(ch, atadev, (ATA_S_READY | ATA_S_DRQ)) < > 0) { > + if (ata_wait(ch, atadev, ATA_S_DRQ) < 0) { > device_printf(request->dev, > "timeout waiting for read DRQ\n"); > request->result = EIO; > > > Søren Schmidt > sos@FreeBSD.org > > > > Søren: Outstanding! The drive is now recognized at boot, I can read and write CD's, and even listen to audio CD's. It all seems to work! Such a small change had a huge impact. If you don't mind, what exactly was the purpose for making the change (other than to make things work)? Thanks for everything, Patrick From owner-freebsd-current@FreeBSD.ORG Fri Sep 16 20:39:24 2005 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B21D16A41F; Fri, 16 Sep 2005 20:39:24 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA20B43D46; Fri, 16 Sep 2005 20:39:23 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j8GKdM6v058925; Fri, 16 Sep 2005 23:39:22 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 95733-03; Fri, 16 Sep 2005 23:39:21 +0300 (EEST) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j8GKdL8i058922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Sep 2005 23:39:21 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.3/8.13.3) id j8GKda0p064856; Fri, 16 Sep 2005 23:39:36 +0300 (EEST) (envelope-from ru) Date: Fri, 16 Sep 2005 23:39:36 +0300 From: Ruslan Ermilov To: Yar Tikhiy , FreeBSD Tinderbox Message-ID: <20050916203935.GB22151@ip.net.ua> References: <20050916193347.21CAE7302F@freebsd-current.sentex.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="24zk1gE8NUlDmwG9" Content-Disposition: inline In-Reply-To: <20050916193347.21CAE7302F@freebsd-current.sentex.ca> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua Cc: alpha@FreeBSD.org, current@FreeBSD.org Subject: Re: [head tinderbox] failure on alpha/alpha X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2005 20:39:24 -0000 --24zk1gE8NUlDmwG9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 16, 2005 at 03:33:47PM -0400, FreeBSD Tinderbox wrote: > >>> stage 3.2: building everything > [...] > cc -c -O2 -pipe -fno-strict-aliasing -mcpu=3Dev4 -mtune=3Dev5 -mieee -Wal= l -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototy= pes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=3Dc99 -= nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contr= ib/altq -D_KERNEL -include opt_global.h -fno-common -finline-limit=3D15000 = --param inline-unit-growth=3D100 --param large-function-growth=3D1000 -fno-= builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/n= et/if_spppsubr.c > cc -c -O2 -pipe -fno-strict-aliasing -mcpu=3Dev4 -mtune=3Dev5 -mieee -Wal= l -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototy= pes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=3Dc99 -= nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contr= ib/altq -D_KERNEL -include opt_global.h -fno-common -finline-limit=3D15000 = --param inline-unit-growth=3D100 --param large-function-growth=3D1000 -fno-= builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/n= et/if_stf.c > cc -c -O2 -pipe -fno-strict-aliasing -mcpu=3Dev4 -mtune=3Dev5 -mieee -Wal= l -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototy= pes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=3Dc99 -= nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contr= ib/altq -D_KERNEL -include opt_global.h -fno-common -finline-limit=3D15000 = --param inline-unit-growth=3D100 --param large-function-growth=3D1000 -fno-= builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/n= et/if_tun.c > cc -c -O2 -pipe -fno-strict-aliasing -mcpu=3Dev4 -mtune=3Dev5 -mieee -Wal= l -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototy= pes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=3Dc99 -= nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contr= ib/altq -D_KERNEL -include opt_global.h -fno-common -finline-limit=3D15000 = --param inline-unit-growth=3D100 --param large-function-growth=3D1000 -fno-= builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/n= et/if_tap.c > cc -c -O2 -pipe -fno-strict-aliasing -mcpu=3Dev4 -mtune=3Dev5 -mieee -Wal= l -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototy= pes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=3Dc99 -= nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contr= ib/altq -D_KERNEL -include opt_global.h -fno-common -finline-limit=3D15000 = --param inline-unit-growth=3D100 --param large-function-growth=3D1000 -fno-= builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/n= et/if_vlan.c > /src/sys/net/if_vlan.c: In function `vlan_start': > /src/sys/net/if_vlan.c:540: warning: format argument is not a pointer (ar= g 2) > /src/sys/net/if_vlan.c:540: warning: field width is not type int (arg 3) > *** Error code 1 >=20 > Stop in /obj/alpha/src/sys/LINT. > *** Error code 1 >=20 Should be fixed. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --24zk1gE8NUlDmwG9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFDKy2HqRfpzJluFF4RAh9KAJ44e4EdSXMnrzdHV8hN5ZSDJb6IxACcCs5S XOQwTflx7xKVQ6U+4EthM+Y= =/Cv6 -----END PGP SIGNATURE----- --24zk1gE8NUlDmwG9-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 16 20:52:23 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E95C716A41F for ; Fri, 16 Sep 2005 20:52:23 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12EFA43D45 for ; Fri, 16 Sep 2005 20:52:22 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: (qmail 47839 invoked by uid 89); 16 Sep 2005 20:50:59 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 16 Sep 2005 20:50:59 -0000 Date: Fri, 16 Sep 2005 22:52:19 +0200 From: Oliver Lehmann To: joseph.koshy@gmail.com Message-Id: <20050916225219.73b53cd0.lehmann@ans-netz.de> In-Reply-To: <20050916184911.38e2739a.lehmann@ans-netz.de> References: <20050914194612.15692485.lehmann@ans-netz.de> <43286E37.40203@samsco.org> <20050914222013.178dc4dc.lehmann@ans-netz.de> <84dead72050914135239514c49@mail.gmail.com> <20050915000053.448f251b.lehmann@ans-netz.de> <84dead7205091500152a7c25d1@mail.gmail.com> <20050915172005.072f4bdf.lehmann@ans-netz.de> <20050915181238.54b16b4b.lehmann@ans-netz.de> <84dead720509160921732e7f96@mail.gmail.com> <20050916184911.38e2739a.lehmann@ans-netz.de> X-Mailer: Sylpheed version 2.0.1 (GTK+ 2.6.10; amd64-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: low(er) disk performance with sched_4bsd then with sched_ule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2005 20:52:24 -0000 Oliver Lehmann wrote: > I'll cvsup my 6_RELENG and report back if anything changed. Wow, that update to BETA4 did the trick! While running SCHED_4BSD: root@nudel olivleh1> dd if=/dev/zero of=/mnt/files/test.dd bs=64k count=32000 32000+0 records in 32000+0 records out 2097152000 bytes transferred in 27.161129 secs (77211518 bytes/sec) with SCHED_ULE: root@nudel olivleh1> dd if=/dev/zero of=/mnt/files/test.dd bs=64k count=32000 32000+0 records in 32000+0 records out 2097152000 bytes transferred in 27.004929 secs (77658119 bytes/sec) -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-current@FreeBSD.ORG Fri Sep 16 20:54:17 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 33FBA16A41F for ; Fri, 16 Sep 2005 20:54:17 +0000 (GMT) (envelope-from jay@codegurus.org) Received: from pih-relay04.plus.net (pih-relay04.plus.net [212.159.14.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id C953B43D45 for ; Fri, 16 Sep 2005 20:54:16 +0000 (GMT) (envelope-from jay@codegurus.org) Received: from [84.92.156.191] (helo=[192.168.0.3]) by pih-relay04.plus.net with esmtp (Exim) id 1EGNDo-0003zz-Fu; Fri, 16 Sep 2005 21:54:12 +0100 Message-ID: <432B3100.5030409@codegurus.org> Date: Fri, 16 Sep 2005 21:54:24 +0100 From: Jayton Garnett User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: minimarmot@gmail.com References: <4329DC37.4090305@codegurus.org> <47d0403c0509151529177cf5cc@mail.gmail.com> In-Reply-To: <47d0403c0509151529177cf5cc@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: making custom kernel module with ndiscvt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2005 20:54:17 -0000 I am using 5.4Release (with custom kernel) and there are no manual entries for ndisgen nor are there any applications by the name of ndisgen. I probably sent this to the wrong mailing list aswell. Ben Kaduk wrote: >On 9/15/05, Jayton Garnett wrote: > > >>Hello, >> >>A while back I asked about my wireless card and if it will be supported >>in 6.0-Release. It wont be :-( . >>Anyway, I have now decided to use ndiscvt to create my own customer >>kernel module for my wireless card >>using the windows drivers. >> >>I now have a file called cvwl.h and want to convert it to cvwl.ko so I >>can either: >>a)Compile it into the Kernel >>b)load/unload it dynamically. >> >>How would I go about creating the .ko file from the .h file? >> >>Cheers, >>Jayton >>_______________________________________________ >>freebsd-current@freebsd.org mailing list >>http://lists.freebsd.org/mailman/listinfo/freebsd-current >>To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> >> >> > >Have you looked at ndisgen(8)? > >Ben Kaduk >_______________________________________________ >freebsd-current@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-current >To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > > > From owner-freebsd-current@FreeBSD.ORG Fri Sep 16 21:35:46 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0146C16A41F; Fri, 16 Sep 2005 21:35:46 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86CF643D46; Fri, 16 Sep 2005 21:35:45 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j8GLZiR9024802; Fri, 16 Sep 2005 17:35:44 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.3/8.13.3) with ESMTP id j8GLZinE089393; Fri, 16 Sep 2005 17:35:44 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id EC3227302F; Fri, 16 Sep 2005 17:35:43 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050916213543.EC3227302F@freebsd-current.sentex.ca> Date: Fri, 16 Sep 2005 17:35:43 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.86, clamav-milter version 0.86 on clamscanner1 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2005 21:35:46 -0000 TB --- 2005-09-16 19:33:47 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-09-16 19:33:47 - starting HEAD tinderbox run for amd64/amd64 TB --- 2005-09-16 19:33:47 - cleaning the object tree TB --- 2005-09-16 19:34:19 - checking out the source tree TB --- 2005-09-16 19:34:19 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2005-09-16 19:34:19 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-09-16 19:40:11 - building world (CFLAGS=-O2 -pipe) TB --- 2005-09-16 19:40:11 - cd /src TB --- 2005-09-16 19:40:11 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries TB --- 2005-09-16 21:11:08 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-09-16 21:11:08 - cd /src TB --- 2005-09-16 21:11:08 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Sep 16 21:11:09 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Fri Sep 16 21:26:56 UTC 2005 TB --- 2005-09-16 21:26:56 - generating LINT kernel config TB --- 2005-09-16 21:26:56 - cd /src/sys/amd64/conf TB --- 2005-09-16 21:26:56 - /usr/bin/make -B LINT TB --- 2005-09-16 21:26:57 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-09-16 21:26:57 - cd /src TB --- 2005-09-16 21:26:57 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Sep 16 21:26:57 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/net/if_spppsubr.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/net/if_stf.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/net/if_tun.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/net/if_tap.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/net/if_vlan.c /src/sys/net/if_vlan.c: In function `vlan_start': /src/sys/net/if_vlan.c:540: warning: format argument is not a pointer (arg 2) /src/sys/net/if_vlan.c:540: warning: field width is not type int (arg 3) *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-09-16 21:35:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-09-16 21:35:43 - ERROR: failed to build lint kernel TB --- 2005-09-16 21:35:43 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sat Sep 17 02:43:33 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 542CA16A41F for ; Sat, 17 Sep 2005 02:43:33 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC6D543D45 for ; Sat, 17 Sep 2005 02:43:32 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by xproxy.gmail.com with SMTP id i31so30580wxd for ; Fri, 16 Sep 2005 19:43:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pFYxMNh4RIs/coCMfB2M1yMeME+jE2S3M2UumciyB49uTNVN88MwjvZLcqdYWUbfoCCzjXYiVnZkExynZfo6DTvtc+AvMvytw5dqTbSw1djgKSH7Gs9lYLQIeVv3dLS3ljqnq/13RYmBuDDokD0DQMTXBngmnMN2DkmwA0h8uFE= Received: by 10.70.116.4 with SMTP id o4mr459822wxc; Fri, 16 Sep 2005 19:43:32 -0700 (PDT) Received: by 10.70.115.15 with HTTP; Fri, 16 Sep 2005 19:43:32 -0700 (PDT) Message-ID: <84dead7205091619435c12b528@mail.gmail.com> Date: Sat, 17 Sep 2005 08:13:32 +0530 From: Joseph Koshy To: Oliver Lehmann In-Reply-To: <20050916225219.73b53cd0.lehmann@ans-netz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050914194612.15692485.lehmann@ans-netz.de> <20050914222013.178dc4dc.lehmann@ans-netz.de> <84dead72050914135239514c49@mail.gmail.com> <20050915000053.448f251b.lehmann@ans-netz.de> <84dead7205091500152a7c25d1@mail.gmail.com> <20050915172005.072f4bdf.lehmann@ans-netz.de> <20050915181238.54b16b4b.lehmann@ans-netz.de> <84dead720509160921732e7f96@mail.gmail.com> <20050916184911.38e2739a.lehmann@ans-netz.de> <20050916225219.73b53cd0.lehmann@ans-netz.de> Cc: current@freebsd.org Subject: Re: low(er) disk performance with sched_4bsd then with sched_ule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: joseph.koshy@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Sep 2005 02:43:33 -0000 ol> Wow, that update to BETA4 did the trick! While running=20 ol> SCHED_4BSD: Fantastic! What is the profile like with the new 4BSD kernel? I'm still puzzled as to how the ULE kernel managed to avoid the bug. --=20 FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-current@FreeBSD.ORG Sat Sep 17 04:43:36 2005 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0BB3416A41F; Sat, 17 Sep 2005 04:43:36 +0000 (GMT) (envelope-from bland@FreeBSD.org) Received: from mvs5.plala.or.jp (c158133.vh.plala.or.jp [210.150.158.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D32843D46; Sat, 17 Sep 2005 04:43:34 +0000 (GMT) (envelope-from bland@FreeBSD.org) Received: from hub.bbnest.net ([219.164.5.135]) by mvs5.plala.or.jp with ESMTP id <20050917044333.SFSR6132.mvs5.plala.or.jp@hub.bbnest.net>; Sat, 17 Sep 2005 13:43:33 +0900 Received: from [10.0.0.2] (nest.bbnest.net [10.0.0.2]) by hub.bbnest.net (8.13.4/8.13.3) with ESMTP id j8H4hWp2067350; Sat, 17 Sep 2005 13:43:32 +0900 (JST) (envelope-from bland@FreeBSD.org) Message-ID: <432B9E4B.1020306@FreeBSD.org> Date: Sat, 17 Sep 2005 13:40:43 +0900 From: Alexander Nedotsukov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.11) Gecko/20050909 X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@FreeBSD.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: threads@FreeBSD.org Subject: GDB warning message. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Sep 2005 04:43:36 -0000 Guys, Can anyone say what is it (see warning message bellow)? (gdb) r The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /usr/X11R6/bin/gnome-dictionary warning: Unable to get location for thread creation breakpoint: generic error [New LWP 100212] [New Thread 0x806b000 (LWP 100212)] [Switching to Thread 0x806b000 (LWP 100120)] Breakpoint 1, dict_disconnect (context=0x8277000) at dict.c:844 844 g_return_if_fail (context != NULL); This is 100% reproducible. Just run program with breakpoint set. Do we have something broken? Thanks, Alexander. From owner-freebsd-current@FreeBSD.ORG Sat Sep 17 06:14:18 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4034816A420; Sat, 17 Sep 2005 06:14:18 +0000 (GMT) (envelope-from fujita@soum.co.jp) Received: from gate.soum.co.jp (gate.soum.co.jp [202.221.40.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A86AE43D46; Sat, 17 Sep 2005 06:14:16 +0000 (GMT) (envelope-from fujita@soum.co.jp) Received: from mail.soum.co.jp (hoth.soum.co.jp [IPv6:2001:240:c4:1:203:baff:fea1:6471]) by gate.soum.co.jp (8.13.3/8.13.3) with ESMTP id j8H6EESM061104; Sat, 17 Sep 2005 15:14:15 +0900 (JST) (envelope-from fujita@soum.co.jp) Received: from localhost (luke.soum.co.jp [172.19.2.3]) by mail.soum.co.jp (8.13.4/8.13.4) with ESMTP id j8H6E9JF014784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 17 Sep 2005 15:14:09 +0900 (JST) Date: Sat, 17 Sep 2005 15:14:08 +0900 (JST) Message-Id: <20050917.151408.46626816.fujita@soum.co.jp> To: freebsd-amd64@freebsd.org, freebsd-current@freebsd.org From: FUJITA Kazutoshi In-Reply-To: <20050902.103259.08238152.fujita@soum.co.jp> <20050902.105311.24457489.fujita@soum.co.jp> References: <17166.21317.705489.47055@grasshopper.cs.duke.edu> <20050902.100210.123568240.fujita@soum.co.jp> <20050902.103259.08238152.fujita@soum.co.jp> X-Face: "; PnIN=f2{%Xj2PnI+zHd.39&Cn1)}br_7:N|2[CbS87Du6#6?|UeqX'&OfyZG-mX#'5T>k/~8X(F,2Mb_pNd8]3Cb1u[kSZjF}J+#`L5(g); List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Sep 2005 06:14:18 -0000 ----Next_Part(Sat_Sep_17_15_14_08_2005_164)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I have AMD64 -CURRENT box. Motherboard is ASUS A8N-E(chipset is nForce4). It has 4GB Memory. There is some trouble with GENERIC kernel, but specifying MAXMEM, such as options MAXMEM=(2*1024*1024) in kernel configuration solve that. What is the problem? [trouble 1] From: FUJITA Kazutoshi Subject: bge problem Date: Fri, 02 Sep 2005 10:32:59 +0900 (JST) > > nve never works on my amd64 box. > > It links up successfully, but... > > > > nve0: device timeout (5) > > nve0: link state changed to DOWN > > nve0: link state changed to UP > > nve0: device timeout (8) > > nve0: link state changed to DOWN > > nve0: link state changed to UP > > > > > > my motherboard is ASUS A8N-E. > > on my amd64 box, bge (at PCI slot) also never works. > it seems same problem as nve. > > > bge0: link state changed to UP > bge0: watchdog timeout -- resetting > bge0: link state changed to DOWN > bge0: link state changed to UP > bge0: watchdog timeout -- resetting > bge0: link state changed to DOWN > bge0: link state changed to UP > bge0: watchdog timeout -- resetting > bge0: link state changed to DOWN > > > bge0: mem 0xd8000000-0xd800ffff irq 16 at device 6.0 on pci5 > bge0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xd8000000 > miibus0: on bge0 > brgphy0: on miibus0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto > bge0: bpf attached > bge0: Ethernet address: 00:09:5b:8e:63:2f > bge0: [MPSAFE] > > > of course, the bge works well on my i386 box. > any suggestions ? [trouble 2] From: FUJITA Kazutoshi Subject: uhub1: device problem (SHORT_XFER), disabling port 1 Date: Fri, 02 Sep 2005 10:53:11 +0900 (JST) > my axe never works on my amd64 box with 7.0-current. > > insert axe to the usb port, following message is out. > > uhub1: device problem (SHORT_XFER), disabling port 1 > > > of course, > the axe works well on my i386 laptop(ThinkPad T43) > with 7.0-current. Regards, ----Next_Part(Sat_Sep_17_15_14_08_2005_164)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg.txt" Copyright (c) 1992-2005 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 7.0-CURRENT #15: Sat Sep 17 14:16:11 JST 2005 fujita@oscar:/usr/obj/usr/src/sys/OSCAR WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80a62000. Preloaded elf obj module "/boot/kernel/sound.ko" at 0xffffffff80a621d0. Preloaded elf obj module "/boot/kernel/snd_ich.ko" at 0xffffffff80a627f8. Preloaded elf obj module "/boot/kernel/smbus.ko" at 0xffffffff80a62d60. Preloaded elf obj module "/boot/kernel/smb.ko" at 0xffffffff80a631c8. Preloaded elf obj module "/boot/kernel/ichsmb.ko" at 0xffffffff80a63630. ACPI APIC Table: Calibrating clock(s) ... i8254 clock: 1193257 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2412374352 Hz CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4800+ (2412.37-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x20f32 Stepping = 2 Features=0x178bfbff Features2=0x1 AMD Features=0xe2500800,LM,3DNow+,3DNow> Hyperthreading: 2 logical CPUs L1 2MB data TLB: 8 entries, fully associative L1 2MB instruction TLB: 8 entries, fully associative L1 4KB data TLB: 32 entries, fully associative L1 4KB instruction TLB: 32 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 2MB unified TLB: 0 entries, disabled/not present L2 4KB data TLB: 512 entries, 4-way associative L2 4KB instruction TLB: 512 entries, 4-way associative L2 unified cache: 1024 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative real memory = 5368709120 (5120 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009bfff, 634880 bytes (155 pages) 0x0000000000b61000 - 0x00000000b69bffff, 3051745280 bytes (745055 pages) 0x0000000100000000 - 0x000000013ffebfff, 1073659904 bytes (262124 pages) avail memory = 4115156992 (3924 MB) APIC ID: physical 0, logical 0:0 APIC ID: physical 1, logical 0:1 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 2 ioapic0: Routing external 8259A's -> intpin 0 ioapic0: intpin 0 -> ExtINT (edge, high) ioapic0: intpin 1 -> ISA IRQ 1 (edge, high) ioapic0: intpin 2 -> ISA IRQ 2 (edge, high) ioapic0: intpin 3 -> ISA IRQ 3 (edge, high) ioapic0: intpin 4 -> ISA IRQ 4 (edge, high) ioapic0: intpin 5 -> ISA IRQ 5 (edge, high) ioapic0: intpin 6 -> ISA IRQ 6 (edge, high) ioapic0: intpin 7 -> ISA IRQ 7 (edge, high) ioapic0: intpin 8 -> ISA IRQ 8 (edge, high) ioapic0: intpin 9 -> ISA IRQ 9 (edge, high) ioapic0: intpin 10 -> ISA IRQ 10 (edge, high) ioapic0: intpin 11 -> ISA IRQ 11 (edge, high) ioapic0: intpin 12 -> ISA IRQ 12 (edge, high) ioapic0: intpin 13 -> ISA IRQ 13 (edge, high) ioapic0: intpin 14 -> ISA IRQ 14 (edge, high) ioapic0: intpin 15 -> ISA IRQ 15 (edge, high) ioapic0: intpin 16 -> PCI IRQ 16 (level, low) ioapic0: intpin 17 -> PCI IRQ 17 (level, low) ioapic0: intpin 18 -> PCI IRQ 18 (level, low) ioapic0: intpin 19 -> PCI IRQ 19 (level, low) ioapic0: intpin 20 -> PCI IRQ 20 (level, low) ioapic0: intpin 21 -> PCI IRQ 21 (level, low) ioapic0: intpin 22 -> PCI IRQ 22 (level, low) ioapic0: intpin 23 -> PCI IRQ 23 (level, low) MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: high MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: high MADT: Interrupt override: source 14, irq 14 ioapic0: intpin 14 trigger: edge ioapic0: intpin 14 polarity: high MADT: Interrupt override: source 15, irq 15 ioapic0: intpin 15 trigger: edge ioapic0: intpin 15 polarity: high lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00040010 LDR: 0x01000000 DFR: 0x0fffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00000000 err: 0x00010000 pcm: 0x00010000 wlan: <802.11 Link Layer> random: nfslock: pseudo-device mem: io: null: acpi0: on motherboard acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x80004004 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=058000] [hdr=00] is there (id=005e10de) acpi_bus_number: root bus has no _BBN, assuming 0 acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR AcpiOsDerivePciId: bus 0 dev 1 func 0 acpi0: Power Button (fixed) acpi_bus_number: root bus has no _BBN, assuming 0 acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR AcpiOsDerivePciId: bus 0 dev 1 func 0 pci_link0: on acpi0 pci_link0: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link0: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link0: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link1: irq 3 on acpi0 pci_link1: Links after initial probe: Index IRQ Rtd Ref IRQs 0 3 N 0 3 4 5 7 9 10 11 12 14 15 pci_link1: Links after initial validation: Index IRQ Rtd Ref IRQs 0 3 N 0 3 4 5 7 9 10 11 12 14 15 pci_link1: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link2: irq 11 on acpi0 pci_link2: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 7 9 10 11 12 14 15 pci_link2: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 7 9 10 11 12 14 15 pci_link2: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link3: on acpi0 pci_link3: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link3: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link3: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link4: on acpi0 pci_link4: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link4: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link4: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link5: on acpi0 pci_link5: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link5: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link5: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link6: on acpi0 pci_link6: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link6: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link6: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link7: irq 3 on acpi0 pci_link7: Links after initial probe: Index IRQ Rtd Ref IRQs 0 3 N 0 3 4 5 7 9 10 11 12 14 15 pci_link7: Links after initial validation: Index IRQ Rtd Ref IRQs 0 3 N 0 3 4 5 7 9 10 11 12 14 15 pci_link7: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link8: irq 5 on acpi0 pci_link8: Links after initial probe: Index IRQ Rtd Ref IRQs 0 5 N 0 3 4 5 7 9 10 11 12 14 15 pci_link8: Links after initial validation: Index IRQ Rtd Ref IRQs 0 5 N 0 3 4 5 7 9 10 11 12 14 15 pci_link8: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link9: on acpi0 pci_link9: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link9: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link9: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link10: on acpi0 pci_link10: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link10: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link10: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link11: on acpi0 pci_link11: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link11: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link11: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link12: on acpi0 pci_link12: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link12: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link12: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link13: irq 5 on acpi0 pci_link13: Links after initial probe: Index IRQ Rtd Ref IRQs 0 5 N 0 3 4 5 7 9 10 11 12 14 15 pci_link13: Links after initial validation: Index IRQ Rtd Ref IRQs 0 5 N 0 3 4 5 7 9 10 11 12 14 15 pci_link13: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link14: irq 11 on acpi0 pci_link14: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 7 9 10 11 12 14 15 pci_link14: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 7 9 10 11 12 14 15 pci_link14: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link15: on acpi0 pci_link15: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link15: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link15: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link16: irq 0 on acpi0 pci_link16: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 16 pci_link16: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 16 pci_link16: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 16 pci_link17: irq 0 on acpi0 pci_link17: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 17 pci_link17: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 17 pci_link17: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 17 pci_link18: irq 0 on acpi0 pci_link18: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 18 pci_link18: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 18 pci_link18: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 18 pci_link19: irq 0 on acpi0 pci_link19: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 19 pci_link19: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 19 pci_link19: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 19 pci_link20: irq 16 on acpi0 pci_link20: Links after initial probe: Index IRQ Rtd Ref IRQs 0 16 N 0 16 pci_link20: Links after initial validation: Index IRQ Rtd Ref IRQs 0 16 N 0 16 pci_link20: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 16 pci_link21: irq 0 on acpi0 pci_link21: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link21: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link21: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link22: irq 0 on acpi0 pci_link22: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link22: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link22: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link23: irq 0 on acpi0 pci_link23: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link23: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link23: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link24: irq 0 on acpi0 pci_link24: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link24: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link24: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link25: irq 0 on acpi0 pci_link25: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link25: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link25: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link26: irq 0 on acpi0 pci_link26: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link26: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link26: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link27: irq 0 on acpi0 pci_link27: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link27: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link27: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link28: irq 0 on acpi0 pci_link28: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link28: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link28: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link29: irq 0 on acpi0 pci_link29: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link29: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link29: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link30: irq 0 on acpi0 pci_link30: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link30: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link30: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link31: irq 0 on acpi0 pci_link31: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link31: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link31: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 ACPI timer: 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x10de, dev=0x005e, revid=0xa3 bus=0, slot=0, func=0 class=05-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x0050, revid=0xa3 bus=0, slot=1, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x00a0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x0052, revid=0xa2 bus=0, slot=1, func=1 class=0c-05-00, hdrtype=0x00, mfdev=1 cmdreg=0x0001, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 0000e400, size 5, enabled map[20]: type 4, range 32, base 00004c00, size 6, enabled map[24]: type 4, range 32, base 00004c40, size 6, enabled found-> vendor=0x10de, dev=0x005a, revid=0xa2 bus=0, slot=2, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=a, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base d8104000, size 12, enabled found-> vendor=0x10de, dev=0x005b, revid=0xa3 bus=0, slot=2, func=1 class=0c-03-20, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=b, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base feb00000, size 8, enabled found-> vendor=0x10de, dev=0x0059, revid=0xa2 bus=0, slot=4, func=0 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x05 (1250 ns) intpin=a, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000dc00, size 8, enabled map[14]: type 4, range 32, base 0000e000, size 8, enabled map[18]: type 1, range 32, base d8103000, size 12, enabled pcib0: matched entry for 0.4.INTA (src \\_SB_.PCI0.APCJ:0) pci_link24: Picked IRQ 20 with weight 0 pcib0: slot 4 INTA routed to irq 20 via \\_SB_.PCI0.APCJ found-> vendor=0x10de, dev=0x0053, revid=0xf2 bus=0, slot=6, func=0 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000f000, size 4, enabled found-> vendor=0x10de, dev=0x0054, revid=0xf3 bus=0, slot=7, func=0 class=01-01-85, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 000009f0, size 3, enabled map[14]: type 4, range 32, base 00000bf0, size 2, enabled map[18]: type 4, range 32, base 00000970, size 3, enabled map[1c]: type 4, range 32, base 00000b70, size 2, enabled map[20]: type 4, range 32, base 0000d800, size 4, enabled map[24]: type 1, range 32, base d8102000, size 12, enabled pcib0: matched entry for 0.7.INTA (src \\_SB_.PCI0.APSI:0) pci_link29: Picked IRQ 21 with weight 0 pcib0: slot 7 INTA routed to irq 21 via \\_SB_.PCI0.APSI found-> vendor=0x10de, dev=0x0055, revid=0xf3 bus=0, slot=8, func=0 class=01-01-85, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 000009e0, size 3, enabled map[14]: type 4, range 32, base 00000be0, size 2, enabled map[18]: type 4, range 32, base 00000960, size 3, enabled map[1c]: type 4, range 32, base 00000b60, size 2, enabled map[20]: type 4, range 32, base 0000c400, size 4, enabled map[24]: type 1, range 32, base d8101000, size 12, enabled pcib0: matched entry for 0.8.INTA (src \\_SB_.PCI0.APSJ:0) pci_link30: Picked IRQ 22 with weight 0 pcib0: slot 8 INTA routed to irq 22 via \\_SB_.PCI0.APSJ found-> vendor=0x10de, dev=0x005c, revid=0xa2 bus=0, slot=9, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x00a0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x02 (500 ns) found-> vendor=0x10de, dev=0x0057, revid=0xa3 bus=0, slot=10, func=0 class=06-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x01 (250 ns), maxlat=0x14 (5000 ns) intpin=a, irq=3 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base d8100000, size 12, enabled map[14]: type 4, range 32, base 0000b000, size 3, enabled pcib0: matched entry for 0.10.INTA (src \\_SB_.PCI0.APCH:0) pci_link23: Picked IRQ 23 with weight 0 pcib0: slot 10 INTA routed to irq 23 via \\_SB_.PCI0.APCH found-> vendor=0x10de, dev=0x005d, revid=0xa3 bus=0, slot=11, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x005d, revid=0xa3 bus=0, slot=12, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x005d, revid=0xa3 bus=0, slot=13, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x005d, revid=0xa3 bus=0, slot=14, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x0a (2500 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1100, revid=0x00 bus=0, slot=24, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1101, revid=0x00 bus=0, slot=24, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1102, revid=0x00 bus=0, slot=24, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1103, revid=0x00 bus=0, slot=24, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) pci0: at device 0.0 (no driver attached) isab0: at device 1.0 on pci0 isa0: on isab0 ichsmb0: port 0xe400-0xe41f,0x4c00-0x4c3f,0x4c40-0x4c7f at device 1.1 on pci0 ichsmb0: Reserved 0x40 bytes for rid 0x20 type 4 at 0x4c00 pcib0: matched entry for 0.1.INTA (src \\_SB_.PCI0.APCS:0) pci_link26: Picked IRQ 20 with weight 1 pcib0: slot 1 INTA routed to irq 20 via \\_SB_.PCI0.APCS ichsmb0: [GIANT-LOCKED] smbus0: on ichsmb0 smb0: on smbus0 ohci0: mem 0xd8104000-0xd8104fff at device 2.0 on pci0 ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xd8104000 pcib0: matched entry for 0.2.INTA (src \\_SB_.PCI0.APCF:0) pci_link21: Picked IRQ 21 with weight 1 pcib0: slot 2 INTA routed to irq 21 via \\_SB_.PCI0.APCF ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 10 ports with 10 removable, self powered ehci0: mem 0xfeb00000-0xfeb000ff at device 2.1 on pci0 ehci0: Reserved 0x100 bytes for rid 0x10 type 3 at 0xfeb00000 pcib0: matched entry for 0.2.INTB (src \\_SB_.PCI0.APCL:0) pci_link27: Picked IRQ 22 with weight 1 pcib0: slot 2 INTB routed to irq 22 via \\_SB_.PCI0.APCL ehci0: [GIANT-LOCKED] usb1: EHCI version 1.0 usb1: companion controller, 4 ports each: usb0 usb1: on ehci0 usb1: USB revision 2.0 uhub1: nVidia EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub1: 10 ports with 10 removable, self powered pcm0: port 0xdc00-0xdcff,0xe000-0xe0ff mem 0xd8103000-0xd8103fff irq 20 at device 4.0 on pci0 pcm0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xdc00 pcm0: Reserved 0x100 bytes for rid 0x14 type 4 at 0xe000 pcm0: [GIANT-LOCKED] pcm0: pcm0: Codec features 5 bit master volume, no 3D Stereo Enhancement pcm0: Primary codec extended features double rate PCM, reserved 1, center DAC, surround DAC, LFE DAC, reserved 5 pcm0: ac97 codec dac ready count: 0 pcm0: sndbuf_setmap b69aa000, 4000; 0xffffffffb4abf000 -> b69aa000 pcm0: sndbuf_setmap b69a6000, 4000; 0xffffffffb4ac3000 -> b69a6000 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 6.0 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xf000 ata0: 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=60 ostat1=70 ata0: stat0=0x20 err=0x20 lsb=0x20 msb=0x20 ata0: stat1=0x30 err=0x30 lsb=0x30 msb=0x30 ata0: reset tp2 stat0=20 stat1=30 devices=0x0 ata0: [MPSAFE] ata1: 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: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 ata1: reset tp2 stat0=00 stat1=00 devices=0x4 ata1: [MPSAFE] atapci1: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xd800-0xd80f mem 0xd8102000-0xd8102fff irq 21 at device 7.0 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xd800 atapci1: [MPSAFE] atapci1: Reserved 0x1000 bytes for rid 0x24 type 3 at 0xd8102000 atapci1: [MPSAFE] ata2: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x9f0 atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0xbf0 ata2: SATA connect status=00000000 ata2: [MPSAFE] ata3: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0x970 atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0xb70 ata3: SATA connect status=00000000 ata3: [MPSAFE] atapci2: port 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xc400-0xc40f mem 0xd8101000-0xd8101fff irq 22 at device 8.0 on pci0 atapci2: Reserved 0x10 bytes for rid 0x20 type 4 at 0xc400 atapci2: [MPSAFE] atapci2: Reserved 0x1000 bytes for rid 0x24 type 3 at 0xd8101000 atapci2: [MPSAFE] ata4: on atapci2 atapci2: Reserved 0x8 bytes for rid 0x10 type 4 at 0x9e0 atapci2: Reserved 0x4 bytes for rid 0x14 type 4 at 0xbe0 ata4: SATA connect ready time=0ms ata4: sata_connect devices=0x1 ata4: [MPSAFE] ata5: on atapci2 atapci2: Reserved 0x8 bytes for rid 0x18 type 4 at 0x960 atapci2: Reserved 0x4 bytes for rid 0x1c type 4 at 0xb60 ata5: SATA connect ready time=0ms ata5: sata_connect devices=0x1 ata5: [MPSAFE] pcib1: at device 9.0 on pci0 pcib1: secondary bus 5 pcib1: subordinate bus 5 pcib1: I/O decode 0xf000-0xfff pcib1: memory decode 0xd8000000-0xd80fffff pcib1: prefetched decode 0xfff00000-0xfffff pcib1: Subtractively decoded bridge. ACPI: Found matching pin for 0.7.INTA at func 0: 21 pci_link17: BIOS IRQ 21 for 0.7.INTA is invalid ACPI: Found matching pin for 0.8.INTA at func 0: 22 pci_link18: BIOS IRQ 22 for 0.8.INTA is invalid ACPI: Found matching pin for 0.10.INTA at func 0: 23 pci_link18: BIOS IRQ 23 for 0.10.INTA is invalid pci5: on pcib1 pci5: physical bus=5 found-> vendor=0x173b, dev=0x03ea, revid=0x15 bus=5, slot=7, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x02b0, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x40 (16000 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 powerspec 2 supports D0 D3 current D0 MSI supports 8 messages, 64 bit map[10]: type 1, range 64, base d8000000, size 16, enabled pcib1: (null) requested memory range 0xd8000000-0xd800ffff: good pcib1: matched entry for 5.7.INTA (src \\_SB_.PCI0.APC2:0) pci_link17: Picked IRQ 17 with weight 0 pcib1: slot 7 INTA routed to irq 17 via \\_SB_.PCI0.APC2 bge0: mem 0xd8000000-0xd800ffff irq 17 at device 7.0 on pci5 bge0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xd8000000 miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge0: bpf attached bge0: Ethernet address: 00:09:5b:8e:63:2f bge0: [MPSAFE] nve0: port 0xb000-0xb007 mem 0xd8100000-0xd8100fff irq 23 at device 10.0 on pci0 nve0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xd8100000 nve0: Ethernet address 00:13:d4:36:79:07 miibus1: on nve0 ukphy0: on miibus1 ukphy0: OUI 0x005043, model 0x000c, rev. 2 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto nve0: bpf attached nve0: Ethernet address: 00:13:d4:36:79:07 nve0: [GIANT-LOCKED] pcib2: at device 11.0 on pci0 pcib2: secondary bus 4 pcib2: subordinate bus 4 pcib2: I/O decode 0xf000-0xfff pcib2: memory decode 0xfff00000-0xfffff pcib2: prefetched decode 0xfff00000-0xfffff pcib2: could not get PCI interrupt routing table for \\_SB_.PCI0.XVR3 - AE_NOT_FOUND pci4: on pcib2 pci4: physical bus=4 pcib3: at device 12.0 on pci0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0xf000-0xfff pcib3: memory decode 0xfff00000-0xfffff pcib3: prefetched decode 0xfff00000-0xfffff pcib3: could not get PCI interrupt routing table for \\_SB_.PCI0.XVR2 - AE_NOT_FOUND pci3: on pcib3 pci3: physical bus=3 pcib4: at device 13.0 on pci0 pcib4: secondary bus 2 pcib4: subordinate bus 2 pcib4: I/O decode 0xf000-0xfff pcib4: memory decode 0xfff00000-0xfffff pcib4: prefetched decode 0xfff00000-0xfffff pcib4: could not get PCI interrupt routing table for \\_SB_.PCI0.XVR1 - AE_NOT_FOUND pci2: on pcib4 pci2: physical bus=2 pcib5: at device 14.0 on pci0 pcib5: secondary bus 1 pcib5: subordinate bus 1 pcib5: I/O decode 0xf000-0xfff pcib5: memory decode 0xd0000000-0xd7ffffff pcib5: prefetched decode 0xc0000000-0xcfffffff pcib5: could not get PCI interrupt routing table for \\_SB_.PCI0.XVR0 - AE_NOT_FOUND pci1: on pcib5 pci1: physical bus=1 found-> vendor=0x10de, dev=0x0141, revid=0xa2 bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type 1, range 32, base d0000000, size 26, enabled pcib5: (null) requested memory range 0xd0000000-0xd3ffffff: good map[14]: type 3, range 64, base c0000000, size 28, enabled pcib5: (null) requested memory range 0xc0000000-0xcfffffff: good map[1c]: type 1, range 64, base d4000000, size 24, enabled pcib5: (null) requested memory range 0xd4000000-0xd4ffffff: good pcib0: matched entry for 0.14.INTA (src \\_SB_.PCI0.APC3:0) pci_link18: Picked IRQ 18 with weight 0 pcib0: slot 14 INTA routed to irq 18 via \\_SB_.PCI0.APC3 pcib5: slot 0 INTA is routed to irq 18 pci1: at device 0.0 (no driver attached) acpi_tz0: on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: ic_type 90 part_id 80 fdc0: [MPSAFE] fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: irq maps: 0x829 0x839 0x829 0x829 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A ppc0: using extended I/O port range ppc0: ECP SPP ECP+EPP SPP ppc0: port 0x378-0x37f,0x778-0x77b irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 plip0: bpf attached lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 psmcpnp0: irq 12 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: flags 0x1 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:0x1, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: current command byte:0047 psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4-00, 5 buttons psm0: config:00000000, flags:00000008, packet size:4 psm0: syncmask:08, syncbits:00 atkbdc: atkbdc0 already exists; skipping it fdc: fdc0 already exists; skipping it ppc: ppc0 already exists; skipping it sio: sio0 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete ex_isa_identify() ahc_isa_probe 0: ioport 0xc00 alloc failed ahc_isa_probe 4: ioport 0x4c00 alloc failed ahc_isa_probe 13: ioport 0xdc00 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 0xc0000-0xcefff,0xd0000-0xd3fff pnpid ORM0000 on isa0 fb: new array size 4 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0x8a9 0x8a9 0x8a9 0x8a9 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 isa_probe_children: probing PnP devices Device configuration finished. Reducing kern.maxvnodes 233016 -> 100000 procfs registered linprocfs registered lapic: Divisor 2, Frequency 100515309 hz Timecounter "TSC" frequency 2412374352 Hz quality -100 Timecounters tick every 1.000 msec Linux ELF exec handler installed lo0: bpf attached ata1-master: pio=PIO4 wdma=WDMA2 udma=UDMA66 cable=80 wire acd0: setting PIO4 on nVidia nForce4 chip acd0: setting UDMA66 on nVidia nForce4 chip acd0: DVDR drive at ata1 as master acd0: read 6890KB/s (6890KB/s) write 6890KB/s (6890KB/s), 1419KB buffer, UDMA66 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: CDR, CDRW, DVDR, DVDRAM, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad8: 286188MB at ata4-master SATA150 ad8: 586114704 sectors [581463C/16H/63S] 16 sectors/interrupt 1 depth queue ad8: nVidia check1 failed ad8: Adaptec check1 failed ad8: LSI (v3) check1 failed ad8: LSI (v2) check1 failed ad8: FreeBSD check1 failed ata1-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad10: 286188MB at ata5-master SATA150 ad10: 586114704 sectors [581463C/16H/63S] 16 sectors/interrupt 1 depth queue ad10: nVidia check1 failed ad10: Adaptec check1 failed ad10: LSI (v3) check1 failed ad10: LSI (v2) check1 failed ad10: FreeBSD check1 failed pcm0: measured ac97 link rate at 48007 Hz, will use 48000 Hz ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00040010 LDR: 0x02000000 DFR: 0x0fffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00000000 err: 0x00010000 pcm: 0x00010000 ioapic0: routing intpin 1 (ISA IRQ 1) to cluster 0 ioapic0: routing intpin 4 (ISA IRQ 4) to cluster 0 ioapic0: routing intpin 6 (ISA IRQ 6) to cluster 0 ioapic0: routing intpin 7 (ISA IRQ 7) to cluster 0 ioapic0: routing intpin 9 (ISA IRQ 9) to cluster 0 ioapic0: routing intpin 12 (ISA IRQ 12) to cluster 0 ioapic0: routing intpin 14 (ISA IRQ 14) to cluster 0 ioapic0: routing intpin 15 (ISA IRQ 15) to cluster 0 ioapic0: routing intpin 17 (PCI IRQ 17) to cluster 0 ioapic0: routing intpin 20 (PCI IRQ 20) to cluster 0 ioapic0: routing intpin 21 (PCI IRQ 21) to cluster 0 ioapic0: routing intpin 22 (PCI IRQ 22) to cluster 0 ioapic0: routing intpin 23 (PCI IRQ 23) to cluster 0 GEOM: new disk ad8 GEOM: new disk ad10 Trying to mount root from ufs:/dev/ad8s1a start_init: trying /sbin/init bge0: link state changed to DOWN nve0: link state changed to UP splash: image decoder found: daemon_saver bge0: watchdog timeout -- resetting ----Next_Part(Sat_Sep_17_15_14_08_2005_164)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg-MAXMEM=2G.txt" Copyright (c) 1992-2005 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 7.0-CURRENT #12: Sat Sep 17 08:44:12 JST 2005 fujita@oscar:/usr/obj/usr/src/sys/OSCAR WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80a62000. Preloaded elf obj module "/boot/kernel/sound.ko" at 0xffffffff80a621d0. Preloaded elf obj module "/boot/kernel/snd_ich.ko" at 0xffffffff80a627f8. Preloaded elf obj module "/boot/kernel/smbus.ko" at 0xffffffff80a62d60. Preloaded elf obj module "/boot/kernel/smb.ko" at 0xffffffff80a631c8. Preloaded elf obj module "/boot/kernel/ichsmb.ko" at 0xffffffff80a63630. ACPI APIC Table: Calibrating clock(s) ... i8254 clock: 1193257 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2412375335 Hz CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4800+ (2412.38-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x20f32 Stepping = 2 Features=0x178bfbff Features2=0x1 AMD Features=0xe2500800,LM,3DNow+,3DNow> Hyperthreading: 2 logical CPUs L1 2MB data TLB: 8 entries, fully associative L1 2MB instruction TLB: 8 entries, fully associative L1 4KB data TLB: 32 entries, fully associative L1 4KB instruction TLB: 32 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 2MB unified TLB: 0 entries, disabled/not present L2 4KB data TLB: 512 entries, 4-way associative L2 4KB instruction TLB: 512 entries, 4-way associative L2 unified cache: 1024 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative real memory = 2147483648 (2048 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009bfff, 634880 bytes (155 pages) 0x0000000000b60000 - 0x000000007c3bbfff, 2072363008 bytes (505948 pages) avail memory = 2062155776 (1966 MB) APIC ID: physical 0, logical 0:0 APIC ID: physical 1, logical 0:1 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 2 ioapic0: Routing external 8259A's -> intpin 0 ioapic0: intpin 0 -> ExtINT (edge, high) ioapic0: intpin 1 -> ISA IRQ 1 (edge, high) ioapic0: intpin 2 -> ISA IRQ 2 (edge, high) ioapic0: intpin 3 -> ISA IRQ 3 (edge, high) ioapic0: intpin 4 -> ISA IRQ 4 (edge, high) ioapic0: intpin 5 -> ISA IRQ 5 (edge, high) ioapic0: intpin 6 -> ISA IRQ 6 (edge, high) ioapic0: intpin 7 -> ISA IRQ 7 (edge, high) ioapic0: intpin 8 -> ISA IRQ 8 (edge, high) ioapic0: intpin 9 -> ISA IRQ 9 (edge, high) ioapic0: intpin 10 -> ISA IRQ 10 (edge, high) ioapic0: intpin 11 -> ISA IRQ 11 (edge, high) ioapic0: intpin 12 -> ISA IRQ 12 (edge, high) ioapic0: intpin 13 -> ISA IRQ 13 (edge, high) ioapic0: intpin 14 -> ISA IRQ 14 (edge, high) ioapic0: intpin 15 -> ISA IRQ 15 (edge, high) ioapic0: intpin 16 -> PCI IRQ 16 (level, low) ioapic0: intpin 17 -> PCI IRQ 17 (level, low) ioapic0: intpin 18 -> PCI IRQ 18 (level, low) ioapic0: intpin 19 -> PCI IRQ 19 (level, low) ioapic0: intpin 20 -> PCI IRQ 20 (level, low) ioapic0: intpin 21 -> PCI IRQ 21 (level, low) ioapic0: intpin 22 -> PCI IRQ 22 (level, low) ioapic0: intpin 23 -> PCI IRQ 23 (level, low) MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: high MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: high MADT: Interrupt override: source 14, irq 14 ioapic0: intpin 14 trigger: edge ioapic0: intpin 14 polarity: high MADT: Interrupt override: source 15, irq 15 ioapic0: intpin 15 trigger: edge ioapic0: intpin 15 polarity: high lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00040010 LDR: 0x01000000 DFR: 0x0fffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00000000 err: 0x00010000 pcm: 0x00010000 wlan: <802.11 Link Layer> random: nfslock: pseudo-device mem: io: null: acpi0: on motherboard acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x80004004 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=058000] [hdr=00] is there (id=005e10de) acpi_bus_number: root bus has no _BBN, assuming 0 acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR AcpiOsDerivePciId: bus 0 dev 1 func 0 acpi0: Power Button (fixed) acpi_bus_number: root bus has no _BBN, assuming 0 acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR AcpiOsDerivePciId: bus 0 dev 1 func 0 pci_link0: on acpi0 pci_link0: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link0: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link0: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link1: irq 3 on acpi0 pci_link1: Links after initial probe: Index IRQ Rtd Ref IRQs 0 3 N 0 3 4 5 7 9 10 11 12 14 15 pci_link1: Links after initial validation: Index IRQ Rtd Ref IRQs 0 3 N 0 3 4 5 7 9 10 11 12 14 15 pci_link1: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link2: irq 11 on acpi0 pci_link2: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 7 9 10 11 12 14 15 pci_link2: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 7 9 10 11 12 14 15 pci_link2: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link3: on acpi0 pci_link3: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link3: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link3: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link4: on acpi0 pci_link4: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link4: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link4: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link5: on acpi0 pci_link5: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link5: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link5: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link6: on acpi0 pci_link6: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link6: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link6: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link7: irq 3 on acpi0 pci_link7: Links after initial probe: Index IRQ Rtd Ref IRQs 0 3 N 0 3 4 5 7 9 10 11 12 14 15 pci_link7: Links after initial validation: Index IRQ Rtd Ref IRQs 0 3 N 0 3 4 5 7 9 10 11 12 14 15 pci_link7: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link8: irq 5 on acpi0 pci_link8: Links after initial probe: Index IRQ Rtd Ref IRQs 0 5 N 0 3 4 5 7 9 10 11 12 14 15 pci_link8: Links after initial validation: Index IRQ Rtd Ref IRQs 0 5 N 0 3 4 5 7 9 10 11 12 14 15 pci_link8: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link9: on acpi0 pci_link9: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link9: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link9: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link10: on acpi0 pci_link10: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link10: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link10: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link11: on acpi0 pci_link11: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link11: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link11: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link12: on acpi0 pci_link12: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link12: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link12: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link13: irq 5 on acpi0 pci_link13: Links after initial probe: Index IRQ Rtd Ref IRQs 0 5 N 0 3 4 5 7 9 10 11 12 14 15 pci_link13: Links after initial validation: Index IRQ Rtd Ref IRQs 0 5 N 0 3 4 5 7 9 10 11 12 14 15 pci_link13: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link14: irq 11 on acpi0 pci_link14: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 7 9 10 11 12 14 15 pci_link14: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 7 9 10 11 12 14 15 pci_link14: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link15: on acpi0 pci_link15: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link15: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link15: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link16: irq 0 on acpi0 pci_link16: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 16 pci_link16: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 16 pci_link16: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 16 pci_link17: irq 0 on acpi0 pci_link17: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 17 pci_link17: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 17 pci_link17: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 17 pci_link18: irq 0 on acpi0 pci_link18: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 18 pci_link18: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 18 pci_link18: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 18 pci_link19: irq 0 on acpi0 pci_link19: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 19 pci_link19: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 19 pci_link19: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 19 pci_link20: irq 16 on acpi0 pci_link20: Links after initial probe: Index IRQ Rtd Ref IRQs 0 16 N 0 16 pci_link20: Links after initial validation: Index IRQ Rtd Ref IRQs 0 16 N 0 16 pci_link20: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 16 pci_link21: irq 0 on acpi0 pci_link21: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link21: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link21: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link22: irq 0 on acpi0 pci_link22: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link22: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link22: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link23: irq 0 on acpi0 pci_link23: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link23: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link23: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link24: irq 0 on acpi0 pci_link24: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link24: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link24: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link25: irq 0 on acpi0 pci_link25: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link25: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link25: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link26: irq 0 on acpi0 pci_link26: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link26: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link26: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link27: irq 0 on acpi0 pci_link27: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link27: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link27: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link28: irq 0 on acpi0 pci_link28: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link28: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link28: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link29: irq 0 on acpi0 pci_link29: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link29: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link29: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link30: irq 0 on acpi0 pci_link30: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link30: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link30: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link31: irq 0 on acpi0 pci_link31: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link31: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 pci_link31: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 23 ACPI timer: 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x10de, dev=0x005e, revid=0xa3 bus=0, slot=0, func=0 class=05-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x0050, revid=0xa3 bus=0, slot=1, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x00a0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x0052, revid=0xa2 bus=0, slot=1, func=1 class=0c-05-00, hdrtype=0x00, mfdev=1 cmdreg=0x0001, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 0000e400, size 5, enabled map[20]: type 4, range 32, base 00004c00, size 6, enabled map[24]: type 4, range 32, base 00004c40, size 6, enabled found-> vendor=0x10de, dev=0x005a, revid=0xa2 bus=0, slot=2, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=a, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base d8104000, size 12, enabled found-> vendor=0x10de, dev=0x005b, revid=0xa3 bus=0, slot=2, func=1 class=0c-03-20, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=b, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base feb00000, size 8, enabled found-> vendor=0x10de, dev=0x0059, revid=0xa2 bus=0, slot=4, func=0 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x05 (1250 ns) intpin=a, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000dc00, size 8, enabled map[14]: type 4, range 32, base 0000e000, size 8, enabled map[18]: type 1, range 32, base d8103000, size 12, enabled pcib0: matched entry for 0.4.INTA (src \\_SB_.PCI0.APCJ:0) pci_link24: Picked IRQ 20 with weight 0 pcib0: slot 4 INTA routed to irq 20 via \\_SB_.PCI0.APCJ found-> vendor=0x10de, dev=0x0053, revid=0xf2 bus=0, slot=6, func=0 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000f000, size 4, enabled found-> vendor=0x10de, dev=0x0054, revid=0xf3 bus=0, slot=7, func=0 class=01-01-85, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 000009f0, size 3, enabled map[14]: type 4, range 32, base 00000bf0, size 2, enabled map[18]: type 4, range 32, base 00000970, size 3, enabled map[1c]: type 4, range 32, base 00000b70, size 2, enabled map[20]: type 4, range 32, base 0000d800, size 4, enabled map[24]: type 1, range 32, base d8102000, size 12, enabled pcib0: matched entry for 0.7.INTA (src \\_SB_.PCI0.APSI:0) pci_link29: Picked IRQ 21 with weight 0 pcib0: slot 7 INTA routed to irq 21 via \\_SB_.PCI0.APSI found-> vendor=0x10de, dev=0x0055, revid=0xf3 bus=0, slot=8, func=0 class=01-01-85, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 000009e0, size 3, enabled map[14]: type 4, range 32, base 00000be0, size 2, enabled map[18]: type 4, range 32, base 00000960, size 3, enabled map[1c]: type 4, range 32, base 00000b60, size 2, enabled map[20]: type 4, range 32, base 0000c400, size 4, enabled map[24]: type 1, range 32, base d8101000, size 12, enabled pcib0: matched entry for 0.8.INTA (src \\_SB_.PCI0.APSJ:0) pci_link30: Picked IRQ 22 with weight 0 pcib0: slot 8 INTA routed to irq 22 via \\_SB_.PCI0.APSJ found-> vendor=0x10de, dev=0x005c, revid=0xa2 bus=0, slot=9, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x00a0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x02 (500 ns) found-> vendor=0x10de, dev=0x0057, revid=0xa3 bus=0, slot=10, func=0 class=06-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x01 (250 ns), maxlat=0x14 (5000 ns) intpin=a, irq=3 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base d8100000, size 12, enabled map[14]: type 4, range 32, base 0000b000, size 3, enabled pcib0: matched entry for 0.10.INTA (src \\_SB_.PCI0.APCH:0) pci_link23: Picked IRQ 23 with weight 0 pcib0: slot 10 INTA routed to irq 23 via \\_SB_.PCI0.APCH found-> vendor=0x10de, dev=0x005d, revid=0xa3 bus=0, slot=11, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x005d, revid=0xa3 bus=0, slot=12, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x005d, revid=0xa3 bus=0, slot=13, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x005d, revid=0xa3 bus=0, slot=14, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x0a (2500 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1100, revid=0x00 bus=0, slot=24, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1101, revid=0x00 bus=0, slot=24, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1102, revid=0x00 bus=0, slot=24, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1103, revid=0x00 bus=0, slot=24, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) pci0: at device 0.0 (no driver attached) isab0: at device 1.0 on pci0 isa0: on isab0 ichsmb0: port 0xe400-0xe41f,0x4c00-0x4c3f,0x4c40-0x4c7f at device 1.1 on pci0 ichsmb0: Reserved 0x40 bytes for rid 0x20 type 4 at 0x4c00 pcib0: matched entry for 0.1.INTA (src \\_SB_.PCI0.APCS:0) pci_link26: Picked IRQ 20 with weight 1 pcib0: slot 1 INTA routed to irq 20 via \\_SB_.PCI0.APCS ichsmb0: [GIANT-LOCKED] smbus0: on ichsmb0 smb0: on smbus0 ohci0: mem 0xd8104000-0xd8104fff at device 2.0 on pci0 ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xd8104000 pcib0: matched entry for 0.2.INTA (src \\_SB_.PCI0.APCF:0) pci_link21: Picked IRQ 21 with weight 1 pcib0: slot 2 INTA routed to irq 21 via \\_SB_.PCI0.APCF ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 10 ports with 10 removable, self powered ehci0: mem 0xfeb00000-0xfeb000ff at device 2.1 on pci0 ehci0: Reserved 0x100 bytes for rid 0x10 type 3 at 0xfeb00000 pcib0: matched entry for 0.2.INTB (src \\_SB_.PCI0.APCL:0) pci_link27: Picked IRQ 22 with weight 1 pcib0: slot 2 INTB routed to irq 22 via \\_SB_.PCI0.APCL ehci0: [GIANT-LOCKED] usb1: EHCI version 1.0 usb1: companion controller, 4 ports each: usb0 usb1: on ehci0 usb1: USB revision 2.0 uhub1: nVidia EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub1: 10 ports with 10 removable, self powered pcm0: port 0xdc00-0xdcff,0xe000-0xe0ff mem 0xd8103000-0xd8103fff irq 20 at device 4.0 on pci0 pcm0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xdc00 pcm0: Reserved 0x100 bytes for rid 0x14 type 4 at 0xe000 pcm0: [GIANT-LOCKED] pcm0: pcm0: Codec features 5 bit master volume, no 3D Stereo Enhancement pcm0: Primary codec extended features double rate PCM, reserved 1, center DAC, surround DAC, LFE DAC, reserved 5 pcm0: ac97 codec dac ready count: 0 pcm0: sndbuf_setmap 7ba37000, 4000; 0xffffffffb1ea6000 -> 7ba37000 pcm0: sndbuf_setmap 7ba1c000, 4000; 0xffffffffb1eaa000 -> 7ba1c000 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 6.0 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xf000 ata0: 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=60 ostat1=70 ata0: stat0=0x20 err=0x20 lsb=0x20 msb=0x20 ata0: stat1=0x30 err=0x30 lsb=0x30 msb=0x30 ata0: reset tp2 stat0=20 stat1=30 devices=0x0 ata0: [MPSAFE] ata1: 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: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 ata1: reset tp2 stat0=00 stat1=00 devices=0x4 ata1: [MPSAFE] atapci1: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xd800-0xd80f mem 0xd8102000-0xd8102fff irq 21 at device 7.0 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xd800 atapci1: [MPSAFE] atapci1: Reserved 0x1000 bytes for rid 0x24 type 3 at 0xd8102000 atapci1: [MPSAFE] ata2: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x9f0 atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0xbf0 ata2: SATA connect status=00000000 ata2: [MPSAFE] ata3: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0x970 atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0xb70 ata3: SATA connect status=00000000 ata3: [MPSAFE] atapci2: port 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xc400-0xc40f mem 0xd8101000-0xd8101fff irq 22 at device 8.0 on pci0 atapci2: Reserved 0x10 bytes for rid 0x20 type 4 at 0xc400 atapci2: [MPSAFE] atapci2: Reserved 0x1000 bytes for rid 0x24 type 3 at 0xd8101000 atapci2: [MPSAFE] ata4: on atapci2 atapci2: Reserved 0x8 bytes for rid 0x10 type 4 at 0x9e0 atapci2: Reserved 0x4 bytes for rid 0x14 type 4 at 0xbe0 ata4: SATA connect ready time=0ms ata4: sata_connect devices=0x1 ata4: [MPSAFE] ata5: on atapci2 atapci2: Reserved 0x8 bytes for rid 0x18 type 4 at 0x960 atapci2: Reserved 0x4 bytes for rid 0x1c type 4 at 0xb60 ata5: SATA connect ready time=0ms ata5: sata_connect devices=0x1 ata5: [MPSAFE] pcib1: at device 9.0 on pci0 pcib1: secondary bus 5 pcib1: subordinate bus 5 pcib1: I/O decode 0xf000-0xfff pcib1: memory decode 0xd8000000-0xd80fffff pcib1: prefetched decode 0xfff00000-0xfffff pcib1: Subtractively decoded bridge. ACPI: Found matching pin for 0.7.INTA at func 0: 21 pci_link17: BIOS IRQ 21 for 0.7.INTA is invalid ACPI: Found matching pin for 0.8.INTA at func 0: 22 pci_link18: BIOS IRQ 22 for 0.8.INTA is invalid ACPI: Found matching pin for 0.10.INTA at func 0: 23 pci_link18: BIOS IRQ 23 for 0.10.INTA is invalid pci5: on pcib1 pci5: physical bus=5 found-> vendor=0x173b, dev=0x03ea, revid=0x15 bus=5, slot=7, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x02b0, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x40 (16000 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 powerspec 2 supports D0 D3 current D0 MSI supports 8 messages, 64 bit map[10]: type 1, range 64, base d8000000, size 16, enabled pcib1: (null) requested memory range 0xd8000000-0xd800ffff: good pcib1: matched entry for 5.7.INTA (src \\_SB_.PCI0.APC2:0) pci_link17: Picked IRQ 17 with weight 0 pcib1: slot 7 INTA routed to irq 17 via \\_SB_.PCI0.APC2 bge0: mem 0xd8000000-0xd800ffff irq 17 at device 7.0 on pci5 bge0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xd8000000 miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge0: bpf attached bge0: Ethernet address: 00:09:5b:8e:63:2f bge0: [MPSAFE] nve0: port 0xb000-0xb007 mem 0xd8100000-0xd8100fff irq 23 at device 10.0 on pci0 nve0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xd8100000 nve0: Ethernet address 00:13:d4:36:79:07 miibus1: on nve0 ukphy0: on miibus1 ukphy0: OUI 0x005043, model 0x000c, rev. 2 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto nve0: bpf attached nve0: Ethernet address: 00:13:d4:36:79:07 nve0: [GIANT-LOCKED] pcib2: at device 11.0 on pci0 pcib2: secondary bus 4 pcib2: subordinate bus 4 pcib2: I/O decode 0xf000-0xfff pcib2: memory decode 0xfff00000-0xfffff pcib2: prefetched decode 0xfff00000-0xfffff pcib2: could not get PCI interrupt routing table for \\_SB_.PCI0.XVR3 - AE_NOT_FOUND pci4: on pcib2 pci4: physical bus=4 pcib3: at device 12.0 on pci0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0xf000-0xfff pcib3: memory decode 0xfff00000-0xfffff pcib3: prefetched decode 0xfff00000-0xfffff pcib3: could not get PCI interrupt routing table for \\_SB_.PCI0.XVR2 - AE_NOT_FOUND pci3: on pcib3 pci3: physical bus=3 pcib4: at device 13.0 on pci0 pcib4: secondary bus 2 pcib4: subordinate bus 2 pcib4: I/O decode 0xf000-0xfff pcib4: memory decode 0xfff00000-0xfffff pcib4: prefetched decode 0xfff00000-0xfffff pcib4: could not get PCI interrupt routing table for \\_SB_.PCI0.XVR1 - AE_NOT_FOUND pci2: on pcib4 pci2: physical bus=2 pcib5: at device 14.0 on pci0 pcib5: secondary bus 1 pcib5: subordinate bus 1 pcib5: I/O decode 0xf000-0xfff pcib5: memory decode 0xd0000000-0xd7ffffff pcib5: prefetched decode 0xc0000000-0xcfffffff pcib5: could not get PCI interrupt routing table for \\_SB_.PCI0.XVR0 - AE_NOT_FOUND pci1: on pcib5 pci1: physical bus=1 found-> vendor=0x10de, dev=0x0141, revid=0xa2 bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type 1, range 32, base d0000000, size 26, enabled pcib5: (null) requested memory range 0xd0000000-0xd3ffffff: good map[14]: type 3, range 64, base c0000000, size 28, enabled pcib5: (null) requested memory range 0xc0000000-0xcfffffff: good map[1c]: type 1, range 64, base d4000000, size 24, enabled pcib5: (null) requested memory range 0xd4000000-0xd4ffffff: good pcib0: matched entry for 0.14.INTA (src \\_SB_.PCI0.APC3:0) pci_link18: Picked IRQ 18 with weight 0 pcib0: slot 14 INTA routed to irq 18 via \\_SB_.PCI0.APC3 pcib5: slot 0 INTA is routed to irq 18 pci1: at device 0.0 (no driver attached) acpi_tz0: on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: ic_type 90 part_id 80 fdc0: [MPSAFE] fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: irq maps: 0x829 0x839 0x829 0x829 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A ppc0: using extended I/O port range ppc0: ECP SPP ECP+EPP SPP ppc0: port 0x378-0x37f,0x778-0x77b irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 plip0: bpf attached lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 psmcpnp0: irq 12 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: flags 0x1 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:0x1, flags:0x1d0000 atkbd0: [GIANT-LOCKED] psm0: current command byte:0047 psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4-00, 5 buttons psm0: config:00000000, flags:00000008, packet size:4 psm0: syncmask:08, syncbits:00 atkbdc: atkbdc0 already exists; skipping it fdc: fdc0 already exists; skipping it ppc: ppc0 already exists; skipping it sio: sio0 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete ex_isa_identify() ahc_isa_probe 0: ioport 0xc00 alloc failed ahc_isa_probe 4: ioport 0x4c00 alloc failed ahc_isa_probe 13: ioport 0xdc00 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 0xc0000-0xcefff,0xd0000-0xd3fff pnpid ORM0000 on isa0 fb: new array size 4 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0x8a9 0x8a9 0x8a9 0x8a9 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 isa_probe_children: probing PnP devices Device configuration finished. Reducing kern.maxvnodes 132689 -> 100000 procfs registered linprocfs registered lapic: Divisor 2, Frequency 100515310 hz Timecounter "TSC" frequency 2412375335 Hz quality -100 Timecounters tick every 1.000 msec Linux ELF exec handler installed lo0: bpf attached ata1-master: pio=PIO4 wdma=WDMA2 udma=UDMA66 cable=80 wire acd0: setting PIO4 on nVidia nForce4 chip acd0: setting UDMA66 on nVidia nForce4 chip acd0: DVDR drive at ata1 as master acd0: read 6890KB/s (6890KB/s) write 6890KB/s (6890KB/s), 1419KB buffer, UDMA66 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: CDR, CDRW, DVDR, DVDRAM, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad8: 286188MB at ata4-master SATA150 ad8: 586114704 sectors [581463C/16H/63S] 16 sectors/interrupt 1 depth queue ad8: nVidia check1 failed ad8: Adaptec check1 failed ad8: LSI (v3) check1 failed ad8: LSI (v2) check1 failed ad8: FreeBSD check1 failed ata1-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad10: 286188MB at ata5-master SATA150 ad10: 586114704 sectors [581463C/16H/63S] 16 sectors/interrupt 1 depth queue ad10: nVidia check1 failed ad10: Adaptec check1 failed ad10: LSI (v3) check1 failed ad10: LSI (v2) check1 failed ad10: FreeBSD check1 failed pcm0: measured ac97 link rate at 47996 Hz, will use 48000 Hz ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00040010 LDR: 0x02000000 DFR: 0x0fffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00000000 err: 0x00010000 pcm: 0x00010000 ioapic0: routing intpin 1 (ISA IRQ 1) to cluster 0 ioapic0: routing intpin 4 (ISA IRQ 4) to cluster 0 ioapic0: routing intpin 6 (ISA IRQ 6) to cluster 0 ioapic0: routing intpin 7 (ISA IRQ 7) to cluster 0 ioapic0: routing intpin 9 (ISA IRQ 9) to cluster 0 ioapic0: routing intpin 12 (ISA IRQ 12) to cluster 0 ioapic0: routing intpin 14 (ISA IRQ 14) to cluster 0 ioapic0: routing intpin 15 (ISA IRQ 15) to cluster 0 ioapic0: routing intpin 17 (PCI IRQ 17) to cluster 0 ioapic0: routing intpin 20 (PCI IRQ 20) to cluster 0 ioapic0: routing intpin 21 (PCI IRQ 21) to cluster 0 ioapic0: routing intpin 22 (PCI IRQ 22) to cluster 0 ioapic0: routing intpin 23 (PCI IRQ 23) to cluster 0 GEOM: new disk ad8 GEOM: new disk ad10 Trying to mount root from ufs:/dev/ad8s1a start_init: trying /sbin/init nve0: link state changed to UP splash: image decoder found: daemon_saver bge0: link state changed to UP ----Next_Part(Sat_Sep_17_15_14_08_2005_164)---- From owner-freebsd-current@FreeBSD.ORG Sat Sep 17 07:00:10 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 58EEC16A41F for ; Sat, 17 Sep 2005 07:00:10 +0000 (GMT) (envelope-from chris@haakonia.hitnet.rwth-aachen.de) Received: from ms-dienst.rz.rwth-aachen.de (ms-2.rz.RWTH-Aachen.DE [134.130.3.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9F7F43D46 for ; Sat, 17 Sep 2005 07:00:09 +0000 (GMT) (envelope-from chris@haakonia.hitnet.rwth-aachen.de) Received: from r220-1 (r220-1.rz.RWTH-Aachen.DE [134.130.3.31]) by ms-dienst.rz.rwth-aachen.de (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IMY007PF8S7MJ@ms-dienst.rz.rwth-aachen.de> for freebsd-current@freebsd.org; Sat, 17 Sep 2005 09:00:08 +0200 (MEST) Received: from relay.rwth-aachen.de ([134.130.3.1]) by r220-1 (MailMonitor for SMTP v1.2.2 ) ; Sat, 17 Sep 2005 09:00:07 +0200 (MEST) Received: from bigboss.hitnet.rwth-aachen.de (bigspace.hitnet.RWTH-Aachen.DE [137.226.181.2]) by relay.rwth-aachen.de (8.13.3/8.13.3/1) with ESMTP id j8H707Zj029685; Sat, 17 Sep 2005 09:00:07 +0200 (MEST) Received: from moria.hitnet.rwth-aachen.de ([137.226.181.149] helo=haakonia.hitnet.rwth-aachen.de) by bigboss.hitnet.rwth-aachen.de with esmtp (Exim 3.35 #1 (Debian)) id 1EGWgB-0000Sf-00; Sat, 17 Sep 2005 09:00:07 +0200 Received: by haakonia.hitnet.rwth-aachen.de (Postfix, from userid 1001) id F3E132843F; Sat, 17 Sep 2005 08:59:36 +0200 (CEST) Date: Sat, 17 Sep 2005 08:59:36 +0200 From: Christian Brueffer In-reply-to: <432B069E.8000104@samsco.org> To: Scott Long Message-id: <20050917065936.GD1151@unixpages.org> MIME-version: 1.0 Content-type: multipart/signed; boundary=pY3vCvL1qV+PayAL; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-disposition: inline User-Agent: Mutt/1.5.9i X-Operating-System: FreeBSD 6.0-BETA4 X-PGP-Key: http://people.FreeBSD.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D References: <1126683752.4306.6.camel@massimo.datacode.it> <4327DC81.7040903@samsco.org> <70e8236f050916092979979613@mail.gmail.com> <432B069E.8000104@samsco.org> Cc: joao.barros@gmail.com, Massimo , freebsd-current@freebsd.org Subject: Re: raid framework from OpenBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Sep 2005 07:00:10 -0000 --pY3vCvL1qV+PayAL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 16, 2005 at 11:53:34AM -0600, Scott Long wrote: > Joao Barros wrote: > >On 9/14/05, Scott Long wrote: > > > >>Massimo wrote: > >> > >>>I would like to know what do you think about new OpenBSD raid framework > >>>management. > >>>http://marc.theaimsgroup.com/?l=3Dopenbsd-misc&m=3D112630095818062 > >>> > >>>Doesn't it seems good stuff which is good for consideration? > >>> > >>>Regards. > >> > >>Creating a unified management tool for multiple RAID architectures has > >>been a Holy Grail for at least 10 years, if not longer. It's > >>deceptively hard, though. While it sounds straight-forward and is > >>relatively easy to do for 1 or 2 architectures, the vast differences in > >>how different architectures work makes it quickly turn into a huge mess. > >>This is especially true when it comes to topology discovery and > >>management and asynchronous event notification. Often times the only > >>course is to degrade to a very simple, lowest common denominator > >>interface, which then starts to limit the usefulness of the tool. I've > >>been involved in several professional projects in exactly this area, and > >>it simply is very, very hard to do well. The OpenBSD work looks > >>interesting, but unless they can demostrate useful operation on more > >>than 1 or 2 architectures, it's not terribly impressive. That's not to > >>say that it can't be done and be a success, but the amount of required > >>effort should not be underestimated. It's relatively easy to come up > >>with a framework and implement one architecture module in it, then tell > >>everyone else to simply add more modules. > >> > >>Also, it's not clear from the email whether the tool has to be manually > >>told to rescan and look for changes in the state of the array (not just > >>SES/SAFTE changes of the component drives). Displaying status on demand > >>is fine, but what admin sits in front of their terminal and refreshes > >>their monitoring apps every 5 seconds? The key is to have a an event > >>notification pipeline that can collect events in near real time, filter > >>them in a configurable way, and send out email/pager alerts when > >>appropriate. Also, what does this mean for a datacenter full of > >>machines that need to be monitored? Does a remote terminal session need > >>to be opened on each one in order for monitoring to work? > >> > >>But, even if this particular work degrades into only being a tool for > >>AMI (I assume they mean MegaRAID) controllers, it's still useful and I > >>give them credit for doing it. > > > > > >Having an amr I'm most interested in this, as I guess more people are. > >Given that there is "customer" interest, my question is: is there > >interest from you in this, having it imported to FreeBSD? > >I've looked at the code and I wouldn't mind starting to work on this. > > > >-- > >Joao Barros >=20 > Give it a try if you're interested. >=20 FYI, here's a kerneltrap.org article about it. Looks certainly interesting. http://kerneltrap.org/node/5649 - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --pY3vCvL1qV+PayAL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFDK77YbHYXjKDtmC0RAvvCAJ0Tqes/ouf8Ih9umRzmnXZwrJ7AYQCfYyLU SVNQ9aVfgLoRa0h0SiQ2UHQ= =AQrt -----END PGP SIGNATURE----- --pY3vCvL1qV+PayAL-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 17 08:28:50 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC8CB16A41F for ; Sat, 17 Sep 2005 08:28:50 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA97D43D45 for ; Sat, 17 Sep 2005 08:28:49 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: (qmail 62051 invoked by uid 89); 17 Sep 2005 08:27:24 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 17 Sep 2005 08:27:24 -0000 Date: Sat, 17 Sep 2005 10:28:46 +0200 From: Oliver Lehmann To: joseph.koshy@gmail.com Message-Id: <20050917102846.7bf26a56.lehmann@ans-netz.de> In-Reply-To: <84dead7205091619435c12b528@mail.gmail.com> References: <20050914194612.15692485.lehmann@ans-netz.de> <20050914222013.178dc4dc.lehmann@ans-netz.de> <84dead72050914135239514c49@mail.gmail.com> <20050915000053.448f251b.lehmann@ans-netz.de> <84dead7205091500152a7c25d1@mail.gmail.com> <20050915172005.072f4bdf.lehmann@ans-netz.de> <20050915181238.54b16b4b.lehmann@ans-netz.de> <84dead720509160921732e7f96@mail.gmail.com> <20050916184911.38e2739a.lehmann@ans-netz.de> <20050916225219.73b53cd0.lehmann@ans-netz.de> <84dead7205091619435c12b528@mail.gmail.com> X-Mailer: Sylpheed version 2.0.1 (GTK+ 2.6.10; amd64-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: low(er) disk performance with sched_4bsd then with sched_ule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Sep 2005 08:28:50 -0000 Joseph Koshy wrote: > ol> Wow, that update to BETA4 did the trick! While running > ol> SCHED_4BSD: > > Fantastic! What is the profile like with the new 4BSD kernel? http://pofo.de/tmp/gprof.4bsd.3 -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-current@FreeBSD.ORG Sat Sep 17 11:31:35 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6EC3B16A420 for ; Sat, 17 Sep 2005 11:31:35 +0000 (GMT) (envelope-from b_bonev@mail.orbitel.bg) Received: from smtp.orbitel.bg (smtp.orbitel.bg [195.24.32.22]) by mx1.FreeBSD.org (Postfix) with SMTP id 46DE043D48 for ; Sat, 17 Sep 2005 11:31:33 +0000 (GMT) (envelope-from b_bonev@mail.orbitel.bg) Received: (qmail 18323 invoked from network); 17 Sep 2005 11:31:32 -0000 Received: from unknown (HELO localhost) (10.0.0.4) by smtp.orbitel.bg with SMTP; 17 Sep 2005 11:31:32 -0000 Received: from smtp.orbitel.bg ([10.0.0.3]) by localhost (sof-rv2.orbitel.bg [10.0.0.4]) (amavisd-new, port 10024) with ESMTP id 23893-82; Sat, 17 Sep 2005 14:31:32 +0300 (EEST) Received: from server (unknown [83.228.34.40]) by smtp.orbitel.bg (Postfix) with ESMTP id 8EBE0A5CC0A; Sat, 17 Sep 2005 14:31:31 +0300 (EEST) From: "B. Bonev" To: Date: Sat, 17 Sep 2005 14:31:27 +0200 Organization: ORAC Ltd. Message-ID: <000001c5bb83$b9cbd3a0$4700000a@server> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Virus-Scanned: by amavisd-new at orbitel.bg Cc: freebsd-stable@freebsd.org Subject: BETA4: Panic and can't cleanup filesystem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Sep 2005 11:31:35 -0000 When trying to unmount my flash drive with force (#umount -f /flash) = machine hardlocked. After restart, when fsck-ing in background, computer panicked. Machine is SMP 2x500MHz PIII with Asus P2B-DS motherboard cvsuped and updated to RELENG_6 (BETA4) on 14 september with SHED_ULE = and PREEMPTION panic is written on hand: panic: handle_written_inodeblock: live inodedep cpuid=3D0 KDB: enter: panic [thread pid3 tid 100033] stopped at kdb_enter+0x2b:nop db> where Tracing pid 3 tid 100033 td 0xc15d17d0 kdb_enter(c062b964) at kdb_enter+0x2b panic(c063a716,0,2,0,0) at panic+0x127 handle_written_inodeblock(c1809a00,cbc1a738) at handle_written_inodeblock+0x533 softdep_disk_write_complete(cbc1a738) at = softdep_disk_write_complete+0xb6 bufdone(cbc1a738) at bufdone+0x160 g_vfs_done(c1825ad4) at g_vfs_done+0x8a biodone(c1825ad4,d42e8cc4,0,c062632c,1ea) at biodone+0x57 g_io_shedule_up(c15d17d0) at g_io_shedule_up+0xb5 g_up_procbody(0,d42e8d38,0,c04be5c0,0) at g_up_procbody+0x5a fork_exit(c04be5c0,0,d42e8d38 at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1,eip=3D0,esp=3D0xd42e8d6c,ebp=3D0 --- db>show alllocks Process 3 (g_up) thread 0xc15d17d0 (100033) exclusive sleep mutex SoftdepLock r=3D0 (0xc06dbda0) locked @ /usr/src/sys/ufs/ffs/ffs_softdep.c:4075 exclusive sleep mutex g_xup r=3D0 (0xd42e8cc4) locked @ /usr/src/sys/geom/geom_io.c:490 Process 31 (irq20:acpi0) thread 0xc15cd320 (100021) exclusive sleep mutex acpica subsystem lock r=3D0 (0xc15c0280) locked @ /usr/src/sys/modules/acpi/../../../dev/acpica/Osd/Osdynch.c:361 db> panic Dump... after restart, system stoped and entered in single mode with = inconsistency in /var after fsck, there was message: BAD SUPERBLOCK: VALUES IN SUPERBLOCK DISAGREE WITH THOSE IN FIRST = ALTERNATE then search for SUPERBLOCK failed, and fsck don't have option -b... tried to mount all filesystems and got another panic: # /var: bad dir ino 2 at offset 0: mangled entry panic: ufs_dirbad: bad dir cpuid=3D0 KDB: enter: panic [thread pid 133 tid 100063] stoped at kdb_enter+0x2b: nop db>where Tracing pid 133 tid 100063 td 0xc18554000 kdb_enter(c062b964) at kdb_enter+0x2b panic(c063b64c,c1829800,da96c904,c059eb66,c18866b4) at panic+0x127 ufs_dirbad(c18866b4,0,c063b606,c1854000,0) at ufs_dirbad+0x3a ufs_lookup(da96c92c) at ufs_lookup+0x36a VOP_CACHEDLOOKUP_APV(c066fd80,da96c92c) at VOP_CACHEDLOOKUP_APV+0x87 lookup(da96cbcc,c0515064,0,c1854000,c06bc7c0) at lookup+0x3d6 namei(da96cbcc,c062cf75,267,c1854000,da96ca68) at namei+0x35a vn_open_cred(da96cbcc,da96cccc,0,c15c9a80,3) at vn_open_cred+0x277 vn_open(da96cbcc,da96cccc,0,3,c062cf75) at vn_open+0x1e kern_open(c185400,28065e40,0,1,0) at kern_open+0xb6 open(c185400,da96cd04,3,1,296) at open+0x1a syscall(3b,3b,3b,28070000,80486b1) at syscall+0x27f xint0x80_syscall() at xint0x80_syscall+0x1f --- syscall(5,FreeBSD ELF32,open), eip=3D0x28054e67,esp=3D0xbfbfebcc,ebp=3D0xbfbfec78 --- With every restart, system going in single mode. What can i do to clean = /var filesystem and to debug these panics? Any help are welcome... --=20 I am using the free version of SPAMfighter for private users. It has removed 162 spam emails to date. Paying users do not have this message in their emails. Try www.SPAMfighter.com for free now! From owner-freebsd-current@FreeBSD.ORG Sat Sep 17 11:50:22 2005 Return-Path: X-Original-To: Freebsd-current@FreeBSD.org Delivered-To: Freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7123D16A41F for ; Sat, 17 Sep 2005 11:50:22 +0000 (GMT) (envelope-from sos@FreeBSD.org) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC4FE43D45 for ; Sat, 17 Sep 2005 11:50:21 +0000 (GMT) (envelope-from sos@FreeBSD.org) Received: from [194.192.25.136] (mac.deepcore.dk [194.192.25.136]) by spider.deepcore.dk (8.13.4/8.13.3) with ESMTP id j8HBoRIi039395; Sat, 17 Sep 2005 13:50:27 +0200 (CEST) (envelope-from sos@FreeBSD.org) In-Reply-To: <432B2985.50302@fastmail.fm> References: <1126047871.687.1.camel@localhost> <4328D0F7.2090501@fastmail.fm> <2B22BF98-3FF4-4BE5-B8FF-56BB07CDB4D9@FreeBSD.org> <432B2985.50302@fastmail.fm> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= Date: Sat, 17 Sep 2005 13:50:11 +0200 To: Patrick Bowen X-Mailer: Apple Mail (2.734) X-mail-scanned: by DeepCore Virus & Spam killer v1.12 Cc: Freebsd-current@FreeBSD.org Subject: Re: ATA error on 6.0-BETA4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Sep 2005 11:50:22 -0000 On 16/09/2005, at 22:22, Patrick Bowen wrote: > S=F8ren Schmidt wrote: >> On 15/09/2005, at 3:40, Patrick Bowen wrote: >>> I've notice the same behaviour on my Dell C600. I've attached =20 >>> verbose dmesg's for -current and 5.4. When I boot 5.4 the CD-RW =20 >>> is found and I have no problems using it for either reading or =20 >>> writing. I hope they're useful for you. >> OK, please try the below patch and let me know if that helps any. >>> I'd like to say that I have the greatest respect for *all* of =20 >>> you that work at making FreeBSD the great OS that it is. I just =20 >>> wonder where you find the time to work on it, what with your day =20= >>> jobs, family responsibilities and all... >> I guess we have understanding environments and need for less =20 >> sleep than usual :) >> >> Index: ata-lowlevel.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/sys/dev/ata/ata-lowlevel.c,v >> retrieving revision 1.71 >> diff -u -r1.71 ata-lowlevel.c >> --- ata-lowlevel.c 14 Sep 2005 12:45:06 -0000 1.71 >> +++ ata-lowlevel.c 15 Sep 2005 07:35:41 -0000 >> @@ -278,7 +278,7 @@ >> /* if read data get it */ >> if (request->flags & ATA_R_READ) { >> - if (ata_wait(ch, atadev, (ATA_S_READY | =20 >> ATA_S_DRQ)) < 0) { >> + if (ata_wait(ch, atadev, ATA_S_DRQ) < 0) { >> device_printf(request->dev, >> "timeout waiting for read DRQ\n"); >> request->result =3D EIO; >> >> >> S=F8ren Schmidt >> sos@FreeBSD.org >> >> >> >> >> > S=F8ren: > > Outstanding! The drive is now recognized at boot, I can read and =20 > write CD's, and even listen to audio CD's. It all seems to work! =20 > Such a small change had a huge impact. Good, I'll get this committed ASAP when I have a little more testing =20 done. > If you don't mind, what exactly was the purpose for making the =20 > change (other than to make things work)? ATAPI devices doesn't always set the READY flag, the reason being =20 that they should not be picked up as ATA devices back when there was =20 systems that didn't know about ATAPI. ATA mkIII originally did the identify by polling the device so this =20 wasn't used. Later I changed things to use the generic request =20 processing logic but newer encountered this problem on any of the =20 devices I routinely test with. Now I've found an old ATAPI cdrom that =20= exhibits this behavior and added it to the pool of "must test these" =20 device :) S=F8ren Schmidt sos@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Sep 16 22:58:00 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD21616A41F for ; Fri, 16 Sep 2005 22:58:00 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DE1C43D45 for ; Fri, 16 Sep 2005 22:58:00 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 0F9662E5A; Fri, 16 Sep 2005 17:58:00 -0500 (CDT) Date: Fri, 16 Sep 2005 17:58:00 -0500 To: Jayton Garnett Message-ID: <20050916225800.GA29223@soaustin.net> References: <4329DC37.4090305@codegurus.org> <47d0403c0509151529177cf5cc@mail.gmail.com> <432B3100.5030409@codegurus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <432B3100.5030409@codegurus.org> User-Agent: Mutt/1.5.9i From: linimon@lonesome.com (Mark Linimon) X-Mailman-Approved-At: Sat, 17 Sep 2005 13:08:42 +0000 Cc: freebsd-current@freebsd.org, minimarmot@gmail.com Subject: Re: making custom kernel module with ndiscvt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2005 22:58:00 -0000 On Fri, Sep 16, 2005 at 09:54:24PM +0100, Jayton Garnett wrote: > I am using 5.4Release (with custom kernel) and there are no manual > entries for ndisgen nor are there any applications by the name of ndisgen. man ndisgen HISTORY The ndisgen utility first appeared in FreeBSD 6.0. Unfortunately the 6.0 manpages on www.freebsd.org don't seem to have this yet. mcl From owner-freebsd-current@FreeBSD.ORG Sat Sep 17 09:51:25 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A3EDD16A41F; Sat, 17 Sep 2005 09:51:25 +0000 (GMT) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe13.swip.net [212.247.155.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0F7843D45; Sat, 17 Sep 2005 09:51:24 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: Y1QAsIk9O44SO+J/q9KNyQ== Received: from mp-217-137-127.daxnet.no ([193.217.137.127] verified) by mailfe13.swip.net (CommuniGate Pro SMTP 4.3.4) with ESMTP id 21620517; Sat, 17 Sep 2005 11:51:22 +0200 From: Hans Petter Selasky To: freebsd-usb@freebsd.org Date: Sat, 17 Sep 2005 11:52:22 +0200 User-Agent: KMail/1.7 References: <17166.21317.705489.47055@grasshopper.cs.duke.edu> <20050902.103259.08238152.fujita@soum.co.jp> <20050917.151408.46626816.fujita@soum.co.jp> In-Reply-To: <20050917.151408.46626816.fujita@soum.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509171152.23745.hselasky@c2i.net> X-Mailman-Approved-At: Sat, 17 Sep 2005 13:08:42 +0000 Cc: freebsd-current@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: MAXMEM ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hselasky@c2i.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Sep 2005 09:51:25 -0000 On Saturday 17 September 2005 08:14, FUJITA Kazutoshi wrote: > Hi, > > I have AMD64 -CURRENT box. > Motherboard is ASUS A8N-E(chipset is nForce4). > It has 4GB Memory. This might indicate that your hardware does not support 4GB addressing. In the file "/sys/dev/usb/usb_mem.c", change "BUS_SPACE_MAXADDR_32BIT" into "BUS_SPACE_MAXADDR_32BIT/2". > > There is some trouble with GENERIC kernel, > but specifying MAXMEM, such as > > options MAXMEM=(2*1024*1024) > ^^^ remove this option from your kernel config file. Recompile kernel and see what happens. You might also want to change this in the other drivers in question, and see if it makes any difference. --HPS From owner-freebsd-current@FreeBSD.ORG Sat Sep 17 13:19:14 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77DE316A41F for ; Sat, 17 Sep 2005 13:19:14 +0000 (GMT) (envelope-from dandee@hellteam.net) Received: from pipa.profix.cz (ruprt.hosting4u.cz [82.208.25.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0061343D94 for ; Sat, 17 Sep 2005 13:18:49 +0000 (GMT) (envelope-from dandee@hellteam.net) Received: from localhost (localhost [127.0.0.1]) by pipa.profix.cz (Postfix) with ESMTP id 513824E705 for ; Sat, 17 Sep 2005 15:18:51 +0200 (CEST) Received: from pipa.profix.cz ([127.0.0.1]) by localhost (pipa [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24130-05 for ; Sat, 17 Sep 2005 15:18:51 +0200 (CEST) Received: from gandalf (unknown [80.95.121.105]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by pipa.profix.cz (Postfix) with ESMTP id D9EE14E704 for ; Sat, 17 Sep 2005 15:18:50 +0200 (CEST) From: =?us-ascii?Q?Daniel_Dvorak?= To: Date: Sat, 17 Sep 2005 15:18:46 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcW7ilVgKwCReBU6SEic/bQrnzzCXg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Message-Id: <20050917131850.D9EE14E704@pipa.profix.cz> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at profix.cz Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: DFS in atheros chipsets X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dandee@volny.cz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Sep 2005 13:19:14 -0000 Hi Sam, let me ask you directly about Dynamic Frequency System in short DFS in atheros chipsets. As you know ETSI enforced changing in 802.11a and named as 802.11h, main difference are TPC and DFS (mitigation techniques EN 301 893 ). In atheros driver TPC there is, so it is okay, but correct me I do not see any code about DFS. Perhaps for dfs it is needed to publish new version of HAL, which it can work with DFS. DFS is the last obstacle to expand 5GHz wireless devices on market in Europe. Any comments ? Thank you so much. Dan _____ avast! Antivirus : Odchozi zprava cista. Virova databaze (VPS): 0537-2, 16.09.2005 Testovano: 17.9.2005 15:18:46 avast! - copyright (c) 1988-2005 ALWIL Software. From owner-freebsd-current@FreeBSD.ORG Sat Sep 17 13:27:53 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F3FF16A41F for ; Sat, 17 Sep 2005 13:27:53 +0000 (GMT) (envelope-from dandee@hellteam.net) Received: from pipa.profix.cz (ruprt.hosting4u.cz [82.208.25.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9E7143D48 for ; Sat, 17 Sep 2005 13:27:52 +0000 (GMT) (envelope-from dandee@hellteam.net) Received: from localhost (localhost [127.0.0.1]) by pipa.profix.cz (Postfix) with ESMTP id D55BC4E705 for ; Sat, 17 Sep 2005 15:27:55 +0200 (CEST) Received: from pipa.profix.cz ([127.0.0.1]) by localhost (pipa [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24130-06 for ; Sat, 17 Sep 2005 15:27:55 +0200 (CEST) Received: from gandalf (unknown [80.95.121.105]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by pipa.profix.cz (Postfix) with ESMTP id EE2E24E704 for ; Sat, 17 Sep 2005 15:27:53 +0200 (CEST) From: =?us-ascii?Q?Daniel_Dvorak?= To: Date: Sat, 17 Sep 2005 15:27:44 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcW7i5ZgISq6DJnYQoOcyHRMMEGuqg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Message-Id: <20050917132753.EE2E24E704@pipa.profix.cz> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at profix.cz Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: DFS in atheros chipstets X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dandee@volny.cz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Sep 2005 13:27:53 -0000 In privious e-mail a I meant Dynamic Frequency Selection no System, I am sorry. :) Dan _____ avast! Antivirus : Odchozi zprava cista. Virova databaze (VPS): 0537-2, 16.09.2005 Testovano: 17.9.2005 15:27:44 avast! - copyright (c) 1988-2005 ALWIL Software. From owner-freebsd-current@FreeBSD.ORG Sat Sep 17 17:04:34 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1118016A41F for ; Sat, 17 Sep 2005 17:04:34 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0C9E43D46 for ; Sat, 17 Sep 2005 17:04:33 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.200] ([10.0.0.200]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j8HH4V6j068234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 Sep 2005 10:04:32 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <432C4E49.8020600@errno.com> Date: Sat, 17 Sep 2005 10:11:37 -0700 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050327) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dandee@volny.cz References: <20050917131850.D9EE14E704@pipa.profix.cz> In-Reply-To: <20050917131850.D9EE14E704@pipa.profix.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: DFS in atheros chipsets X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Sep 2005 17:04:34 -0000 Daniel Dvorak wrote: > Hi Sam, > > let me ask you directly about Dynamic Frequency System in short DFS in > atheros chipsets. As you know ETSI enforced changing in 802.11a and named as > 802.11h, main difference are TPC and DFS (mitigation techniques EN 301 893 > ). > > In atheros driver TPC there is, so it is okay, but correct me I do not see > any code about DFS. Perhaps for dfs it is needed to publish new version of > HAL, which it can work with DFS. > > DFS is the last obstacle to expand 5GHz wireless devices on market in > Europe. There will be DFS support in the next hal. No ETA; I'm taking a break from FreeBSD wireless stuff right now. Sam From owner-freebsd-current@FreeBSD.ORG Sat Sep 17 17:15:36 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 854A616A41F for ; Sat, 17 Sep 2005 17:15:36 +0000 (GMT) (envelope-from arwuah@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC9C843D45 for ; Sat, 17 Sep 2005 17:15:35 +0000 (GMT) (envelope-from arwuah@gmail.com) Received: by xproxy.gmail.com with SMTP id i31so159143wxd for ; Sat, 17 Sep 2005 10:15:34 -0700 (PDT) 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; b=p/hkzhajs8AilnZL+7BwgFqB/ZPjzJYuIDtEYrA9nn/gPMQBIb+7nwHYvAepgSKXv6l7668AsyNpIM9SBsxaporcLWiOSL3a2t8r9gCaWuEYza0Lizy2LszzmT/Ojtf0QsXKp0m7o7dUQapgXLio0q49Av2LPOmuVWlbyCP+ifo= Received: by 10.70.92.12 with SMTP id p12mr571847wxb; Sat, 17 Sep 2005 10:15:34 -0700 (PDT) Received: by 10.70.118.7 with HTTP; Sat, 17 Sep 2005 10:15:34 -0700 (PDT) Message-ID: <9c6409a70509171015417ceed3@mail.gmail.com> Date: Sat, 17 Sep 2005 13:15:34 -0400 From: Arwuah _ To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_25069_15977819.1126977334885" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: 6.0-BETA4 Fatal Trap:12 (doing dhclient iwi0) on ThinkPad T43P X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: arwuah@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Sep 2005 17:15:36 -0000 ------=_Part_25069_15977819.1126977334885 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline When executing dhclient iwi0 to obtain a new wireless address on my ThinkPa= d=20 T43P-2668H2U my system instantly panics with: ... 1st 0xc2204b68 iwi0 (network driver)@/usr/src/sys/dev/iwi/if_iwi.c:1532 2nd 0xc07d4cc0 Giant (Giant)@/usr/src/sys/vm/vm_contig.c:567 Fatal Trap 12: page fault while in kernel mode ... On 6.0-BETA3 I do not have this problem and I compiled with the same option= s=20 included within this email. Intel Wireless works fine without any problems= =20 with 6.0-BETA3, but with BETA4 the machine chokes. Please let me know if you require any more information. Thank You, -Arwuah Attached Files: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. dmesg.today // dmesg=20 2. GUS.kernel // My Kernel config file 3. send-pr //The send-pr file. ------=_Part_25069_15977819.1126977334885 Content-Type: application/octet-stream; name=dmesg.today Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dmesg.today" Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.0-BETA4 #5: Mon Sep 12 00:45:20 EDT 2005 root@gus.mydomain.com:/usr/obj/usr/src/sys/GUS WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) M processor 2.13GHz (2128.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6d8 Stepping = 8 Features=0xafe9fbff Features2=0x180 AMD Features=0x100000 real memory = 938278912 (894 MB) avail memory = 908926976 (866 MB) ACPI APIC Table: ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi_ec0: port 0x62,0x66 on acpi0 acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi0: Power Button (fixed) pci_link0: irq 3 on acpi0 pci_link1: irq 4 on acpi0 pci_link2: irq 5 on acpi0 pci_link3: irq 6 on acpi0 pci_link4: irq 10 on acpi0 pci_link5: irq 11 on acpi0 pci_link6: irq 5 on acpi0 pci_link7: irq 11 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_perf0: on cpu0 acpi_throttle0: on cpu0 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) pcib2: irq 20 at device 28.0 on pci0 pci2: on pcib2 bge0: mem 0xa8200000-0xa820ffff irq 16 at device 0.0 on pci2 miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge0: Ethernet address: 00:11:25:49:c2:e3 pcib3: irq 22 at device 28.2 on pci0 pci3: on pcib3 uhci0: port 0x1800-0x181f irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1820-0x183f irq 17 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 18 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 uhci3: port 0x1860-0x187f irq 19 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xa8000000-0xa80003ff irq 19 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered pcib4: at device 30.0 on pci0 pci4: on pcib4 cbb0: mem 0xa8400000-0xa8400fff irq 16 at device 0.0 on pci4 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 iwi0: mem 0xa8401000-0xa8401fff irq 21 at device 2.0 on pci4 iwi0: Ethernet address: 00:12:f0:4c:80:fa pci0: at device 30.2 (no driver attached) pci0: at device 30.3 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x18c0-0x18cf at device 31.2 on pci0 atapci0: failed to enable memory mapping! ata0: on atapci0 ata1: on atapci0 pci0: at device 31.3 (no driver attached) acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 8250 or not responding battery0: on acpi0 acpi_acad0: on acpi0 pmtimer0 on isa0 orm0: at iomem 0xdc000-0xdffff on isa0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> 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 ugen0: STMicroelectronics Biometric Coprocessor, rev 1.00/0.01, addr 2 Timecounter "TSC" frequency 2128017939 Hz quality 800 Timecounters tick every 1.000 msec ad0: 57231MB at ata0-master UDMA100 acd0: DVDR at ata1-master UDMA33 Trying to mount root from ufs:/dev/ad0s3a iwi0: Please load firmware ------=_Part_25069_15977819.1126977334885 Content-Type: application/octet-stream; name=GUS.kernel Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="GUS.kernel" # GUS -- Generic kernel configuration file for FreeBSD/i386 # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # $FreeBSD: src/sys/i386/conf/GUS,v 1.429.2.1 2005/07/18 12:23:41 kensmith Exp $ machine i386 cpu I686_CPU ident GUS # To statically compile in device wiring instead of /boot/device.hints #hints "GUS.hints" # Default places to look for devices. makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols #options SCHED_ULE # ULE scheduler options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFS_ROOT # NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_GPT # GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. options ADAPTIVE_GIANT # Giant mutex is adaptive. # Debugging for use in -current options KDB # Enable kernel debugger support. options DDB # Support DDB. options GDB # Support remote GDB. options INVARIANTS # Enable calls of extra sanity checking options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS options WITNESS # Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed # To make an SMP kernel, the next two lines are needed options SMP # Symmetric MultiProcessor Kernel device apic # I/O APIC # Bus support. Do not remove isa, even if you have no isa slots device isa device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc # Enable this for the pcvt (VT220 compatible) console driver #device vt #options XSERVER # support for X server on a vt console #options FAT_CURSOR # start with block cursor device agp # support several AGP chipsets # Floating point support - do not disable. device npx # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. device pmtimer # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support device cbb # cardbus (yenta) bridge device pccard # PC Card (16-bit) bus device cardbus # CardBus (32-bit) bus # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to the sio and/or ppc drivers): #device puc # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device bge # Broadcom BCM570xx Gigabit Ethernet # Wireless NIC cards device wlan # 802.11 support device iwi # Intel # Pseudo devices. device loop # Network loopback device mem # Memory and kernel memory devices device io # I/O device device random # Entropy device device ether # Ethernet support device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse device ural # Ralink Technology RT2500USB wireless NICs device urio # Diamond Rio 500 MP3 player device uscanner # Scanners # USB Ethernet, requires miibus device aue # ADMtek USB Ethernet device axe # ASIX Electronics USB Ethernet device cdce # Generic USB over Ethernet device cue # CATC USB Ethernet device kue # Kawasaki LSI USB Ethernet device rue # RealTek RTL8150 USB Ethernet # FireWire support device firewire # FireWire bus code device sbp # SCSI over FireWire (Requires scbus and da) device fwe # Ethernet over FireWire (non-standard!) ------=_Part_25069_15977819.1126977334885 Content-Type: application/octet-stream; name=send-pr Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="send-pr" To: FreeBSD-gnats-submit@freebsd.org From: Samuel A. Winful Reply-To: arwuah@gmail.com Cc: X-send-pr-version: 3.113 X-GNATS-Notify: >Submitter-Id: current-users >Originator: Samuel A. Winful >Organization: None >Confidential: no >Synopsis: Page fault executing 'dhclient iwi0' in 6.0-BETA4 >Severity: serious >Priority: medium >Category: i386 >Class: sw-bug >Release: FreeBSD 6.0-BETA4 i386 >Environment: System: FreeBSD gus.mydomain.com 6.0-BETA4 FreeBSD 6.0-BETA4 #6: Fri Sep 16 22:22:00 EDT 2005 root@gus.mydomain.com:/usr/obj/usr/src/sys/GUS i386 CPU: Intel(R) Pentium(R) M processor 2.13GHz (2128.02-MHz 686-class CPU) OS: FreeBSD 6.0-BETA4 #6: Fri Sep 16 22:22:00 EDT 2005 Origin = "GenuineIntel" Id = 0x6d8 Stepping = 8 Features=0xafe9fbff >Description: Simply executing: dhclient iwi0 causes a Fatal Trap 12: page fault while in kernel mode with the following error: 1st: 0xc2204b68 iwi0 (network driver) @ /usr/src/sys/dev/iwi/if_iwi.c:1532 2nd: 0xc07d4cc0 Giant (Giant) @ /usr/src/sys/vm/vm_contig.c:567 ... Stoped at db_reada_bytest 0x40: movzbl 0(%edx), %eax >How-To-Repeat: cvsup to 6.0-BETA4 on a ThinkPad T43P-H2U with iwi (Intel(R) PRO/Wireless 2200BG ) compiled into the kernel. The make.conf file looks as follows: ---snip--snip--- .ifdef USE_ICC CC=icc CXX=icpc .endif .if ${CC:T} == "icc" CFLAGS= -O3 -align -tpp7 -mcpu=i686 -march=i686 -xW .else CFLAGS+= ${PROG:C/.+/-fomit-frame-pointer/} CXXFLAGS+= ${PROG_CXX:C/.+/-fomit-frame-pointer/} .endif CPUTYPE?=i686 NO_CPU_CFLAGS=yes NO_CPU_COPTFLAGS=yes NO_ATM=yes NO_INET6=yes COPTFLAGS+= -pipe -march=i686 -fomit-frame-pointer -O -DNDEBUG -DNODEBUG NO_PROFILE=yes OBJFORMAT=elf KERNCONF=GUS ---snip--snip--- >Fix: Do not know of any at this time. ------=_Part_25069_15977819.1126977334885-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 17 20:46:16 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 249F516A41F for ; Sat, 17 Sep 2005 20:46:16 +0000 (GMT) (envelope-from sullrich@gmail.com) Received: from qproxy.gmail.com (qproxy.gmail.com [72.14.204.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C4E643D45 for ; Sat, 17 Sep 2005 20:46:15 +0000 (GMT) (envelope-from sullrich@gmail.com) Received: by qproxy.gmail.com with SMTP id e11so119480qbe for ; Sat, 17 Sep 2005 13:46:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MJIygrPiU0R+n7+ZQovMRrBQWBTwA7L79/J95S886tMhTlOds3NO2vL1i350E/NmYNb4OZTx/J7mCmwzFI64ts2fN8yUrpPOnWnVuNieJaY7+3ZqS37/WdoWsTMrr1HXIRpXcR4lKytN+LA1bSZ7SnshMLjR9/UM3Epx1JX0RsI= Received: by 10.65.11.14 with SMTP id o14mr12889qbi; Sat, 17 Sep 2005 13:46:13 -0700 (PDT) Received: by 10.64.184.1 with HTTP; Sat, 17 Sep 2005 13:46:13 -0700 (PDT) Message-ID: Date: Sat, 17 Sep 2005 16:46:13 -0400 From: Scott Ullrich To: "s.g." In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1918533620.20050908000805@theconcept.ru> Cc: freebsd-current@freebsd.org Subject: Re: Re[2]: Can't load kernel errors (with wierd bios messages) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sullrich@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Sep 2005 20:46:16 -0000 On 9/7/05, Scott Ullrich wrote: > # cat /usr/src/sys/boot/i386/loader/../../common/module.c | wc -l > 961 Just for the archives, I have tracked down why this happens but am not completely sure of the cause. Somehow loader.rc was over 2 megs in size. After trimming the file back down to size and adding back the necessary bits everything works fine. Very strange. Scott From owner-freebsd-current@FreeBSD.ORG Sat Sep 17 21:33:47 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 20D3D16A41F for ; Sat, 17 Sep 2005 21:33:47 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B90743D45 for ; Sat, 17 Sep 2005 21:33:44 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.4/8.13.4) with ESMTP id j8HLXh59010227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 Sep 2005 17:33:43 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id j8HLXcRK098467; Sat, 17 Sep 2005 17:33:38 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17196.35762.395155.325627@grasshopper.cs.duke.edu> Date: Sat, 17 Sep 2005 17:33:38 -0400 (EDT) To: joseph.koshy@gmail.com In-Reply-To: <20050917102846.7bf26a56.lehmann@ans-netz.de> References: <20050914194612.15692485.lehmann@ans-netz.de> <20050914222013.178dc4dc.lehmann@ans-netz.de> <84dead72050914135239514c49@mail.gmail.com> <20050915000053.448f251b.lehmann@ans-netz.de> <84dead7205091500152a7c25d1@mail.gmail.com> <20050915172005.072f4bdf.lehmann@ans-netz.de> <20050915181238.54b16b4b.lehmann@ans-netz.de> <84dead720509160921732e7f96@mail.gmail.com> <20050916184911.38e2739a.lehmann@ans-netz.de> <20050916225219.73b53cd0.lehmann@ans-netz.de> <84dead7205091619435c12b528@mail.gmail.com> <20050917102846.7bf26a56.lehmann@ans-netz.de> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: current@freebsd.org Subject: Re: low(er) disk performance with sched_4bsd then with sched_ule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Sep 2005 21:33:47 -0000 Oliver Lehmann writes: > Joseph Koshy wrote: > > > ol> Wow, that update to BETA4 did the trick! While running > > ol> SCHED_4BSD: > > > > Fantastic! What is the profile like with the new 4BSD kernel? > > http://pofo.de/tmp/gprof.4bsd.3 I don't know the disk codepath very well, but the samples look a little suspect. We're copying a lot of data into and out of the kernel, so I would expect the majority of non disk wait time would be spent simply copying out the zero-filled pages, and copying them back in (AFAIK, dd uses read/write). Where is the time spent in read, write, uiomove, bcopy? What about ionode allocations, etc? And why do things like g_bsd_modify and g_bsd_ioctl rank so high? Aren't those only used when dealing with disklabels? BTW, I *love* that we've got access to the hw counters, and an easy way to do low-overhead profiling of the kernel. Drew