From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 01:54:24 2005 Return-Path: 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 4183B16A4CE for ; Sun, 10 Apr 2005 01:54:24 +0000 (GMT) Received: from web54003.mail.yahoo.com (web54003.mail.yahoo.com [206.190.36.227]) by mx1.FreeBSD.org (Postfix) with SMTP id A0C1B43D46 for ; Sun, 10 Apr 2005 01:54:21 +0000 (GMT) (envelope-from spamrefuse@yahoo.com) Received: (qmail 57350 invoked by uid 60001); 10 Apr 2005 01:54:20 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=R31y0fU7QN3L6IkVRaxls/ckvY01barDmdzLro0XufopXPvNomnWjnnKPVKLY5bezQGqBn5WkzHA1YdVVXTCVz38dE0SAPE01nfrCvdiFOCWR6zKAwqlg6ZyDfz3S4WSLcBDbxTePQ8TDIspwvPc1QBrQtugLg3BvdWrwdVlYFk= ; Message-ID: <20050410015420.57348.qmail@web54003.mail.yahoo.com> Received: from [147.46.44.181] by web54003.mail.yahoo.com via HTTP; Sat, 09 Apr 2005 18:54:20 PDT Date: Sat, 9 Apr 2005 18:54:20 -0700 (PDT) From: Rob To: FreeBSD current MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: xl(4) & polling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Apr 2005 01:54:24 -0000 Ruslan Ermilov wrote: > On Mar 24, 2005 Christopher Nehren wrote: > >>On 2005-03-24, Ruslan Ermilov scribbled these >>curious markings: >> >>> Those of you wishing to try your xl(4) card under >>> polling(4) are welcome to test this patch: >> >> Can I apply this to my RELENG_5 box without making >> the machine melt? If so, I'll start testing >> immediately with my handy-dandy just-found spare >> xl (3C905-TX). I have a dual-homed router+NAT, which has two 3C905B-TX lan cards. I never have considered polling, because it was not supported for these cards; hence I have little knowledge about it. I am considering this patch on my 5.3-STABLE router. Is there a proper test I can do to verify that the polling is indeed working as expected? Thanks, Rob. PS: if this makes it into the official sources, then don't forget to also add xl(4) to the polling(4) manpage. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 02:28:13 2005 Return-Path: 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 5A64D16A4CE for ; Sun, 10 Apr 2005 02:28:13 +0000 (GMT) Received: from web54009.mail.yahoo.com (web54009.mail.yahoo.com [206.190.36.233]) by mx1.FreeBSD.org (Postfix) with SMTP id D1F5443D1F for ; Sun, 10 Apr 2005 02:28:12 +0000 (GMT) (envelope-from spamrefuse@yahoo.com) Received: (qmail 7604 invoked by uid 60001); 10 Apr 2005 02:28:12 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=fa+fvsEeJy7qSL+QP5gXOyQ003CgXCUNXlVoo2Ox1I9XZPaWRD162UNM7wrapCSg+835U2gVbYzGgweBj+JW+wL7nEhgjpyuXvu0Bhw24Hv8/oQ5NIZW0K+96MZ9ingFaX0S/OqwyipmNZ3d5Q/mwgB0skZd3HvUpoT6icIBsgY= ; Message-ID: <20050410022812.7602.qmail@web54009.mail.yahoo.com> Received: from [147.46.44.181] by web54009.mail.yahoo.com via HTTP; Sat, 09 Apr 2005 19:28:12 PDT Date: Sat, 9 Apr 2005 19:28:12 -0700 (PDT) From: Rob To: FreeBSD current MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: polling(4) manpage about -CURRENT ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Apr 2005 02:28:13 -0000 Hi, The manpage 'polling(4)' has this text: kern.polling.idle_poll Controls if polling is enabled in the idle loop. There are no reasons (other than power saving or bugs in the scheduler's handling of idle priority kernel threads) to disable this. Note that -CURRENT apparently has some problems in this respect now, so default is disabled. Is that still valid for present "-CURRENT" ? Or is the a left-over from a previous CURRENT state ? Rob. __________________________________ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 02:53:09 2005 Return-Path: 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 4B9AB16A4CE; Sun, 10 Apr 2005 02:53:09 +0000 (GMT) Received: from sana.init-main.com (104.194.138.210.bn.2iij.net [210.138.194.104]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3AB2A43D2D; Sun, 10 Apr 2005 02:53:06 +0000 (GMT) (envelope-from takawata@init-main.com) Received: from init-main.com (localhost.init-main.com [127.0.0.1]) by sana.init-main.com (8.13.1/8.13.1) with ESMTP id j3A2pLEH055107; Sun, 10 Apr 2005 11:51:22 +0900 (JST) (envelope-from takawata@init-main.com) Message-Id: <200504100251.j3A2pLEH055107@sana.init-main.com> To: jeff@freebsd.org, bp@freebsd.org From: takawata@jp.freebsd.org Date: Sun, 10 Apr 2005 11:51:21 +0900 Sender: takawata@init-main.com cc: freebsd-fs@freebsd.org cc: freebsd-current@freebsd.org Subject: smbfs bug introduced at smbfs_vnops.c:1.58 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Apr 2005 02:53:09 -0000 Hi I found the bug which is introduced at smbfs_vnops.c rev 1.58 This will make instant panic when you try to access file on mounted smbfs. This is caused by uninitialized vp. Index: smbfs_vnops.c =================================================================== RCS file: /home/ncvs/src/sys/fs/smbfs/smbfs_vnops.c,v retrieving revision 1.59 diff -u -r1.59 smbfs_vnops.c --- smbfs_vnops.c 29 Mar 2005 13:06:58 -0000 1.59 +++ smbfs_vnops.c 10 Apr 2005 02:44:04 -0000 @@ -1118,7 +1118,8 @@ return error; if (error) { /* name was found */ struct vattr vattr; - + + vp = *vpp; killit = 0; error = VOP_GETATTR(vp, &vattr, cnp->cn_cred, td); /* From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 03:20:26 2005 Return-Path: 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 7699116A4CE; Sun, 10 Apr 2005 03:20:26 +0000 (GMT) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67DF843D1D; Sun, 10 Apr 2005 03:20:23 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from beastie.frontfree.net (unknown [219.239.99.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 7304BEB0F84; Sun, 10 Apr 2005 11:20:17 +0800 (CST) Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id CC02F135376; Sun, 10 Apr 2005 11:20:15 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35430-11; Sun, 10 Apr 2005 11:20:10 +0800 (CST) Received: by beastie.frontfree.net (Postfix, from userid 1001) id 984C013273A; Sun, 10 Apr 2005 11:20:09 +0800 (CST) Date: Sun, 10 Apr 2005 11:20:09 +0800 From: Xin LI To: takawata@jp.freebsd.org Message-ID: <20050410032009.GA37675@frontfree.net> References: <200504100251.j3A2pLEH055107@sana.init-main.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ibTvN161/egqYuK8" Content-Disposition: inline In-Reply-To: <200504100251.j3A2pLEH055107@sana.init-main.com> User-Agent: Mutt/1.4.2.1i X-GPG-key-ID/Fingerprint: 0xCAEEB8C0 / 43B8 B703 B8DD 0231 B333 DC28 39FB 93A0 CAEE B8C0 X-GPG-Public-Key: http://www.delphij.net/delphij.asc X-Operating-System: FreeBSD beastie.frontfree.net 5.3-RELEASE-p2 FreeBSD 5.3-RELEASE-p2 #15: Wed Dec 15 10:43:16 CST 2004 delphij@beastie.frontfree.net:/usr/obj/usr/src/sys/BEASTIE i386 X-URL: http://www.delphij.net X-By: delphij@beastie.frontfree.net X-Location: Beijing, China X-Virus-Scanned: by amavisd-new at frontfree.net cc: freebsd-fs@freebsd.org cc: bp@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: smbfs bug introduced at smbfs_vnops.c:1.58 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Apr 2005 03:20:26 -0000 --ibTvN161/egqYuK8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Sun, Apr 10, 2005 at 11:51:21AM +0900, takawata@jp.freebsd.org wrote: > Hi I found the bug which is introduced at smbfs_vnops.c rev 1.58 >=20 > This will make instant panic when you try to access > file on mounted smbfs. >=20 > This is caused by uninitialized vp. Committed, thanks! Cheers, --=20 Xin LI http://www.delphij.net/ See complete headers for GPG key and other information. --ibTvN161/egqYuK8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCWJtp/cVsHxFZiIoRAkYbAJ9VmN+W5KjxwykT1nqC80smMDzJowCfVx4V 1Peaqc4bHwxEaddte3bxEsc= =zqSB -----END PGP SIGNATURE----- --ibTvN161/egqYuK8-- From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 06:22:23 2005 Return-Path: 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 3E01516A4CE; Sun, 10 Apr 2005 06:22:23 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD3BB43D46; Sun, 10 Apr 2005 06:22:22 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id BFF6B72DE5; Sat, 9 Apr 2005 23:22:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id BAF0F72DE4; Sat, 9 Apr 2005 23:22:22 -0700 (PDT) Date: Sat, 9 Apr 2005 23:22:22 -0700 (PDT) From: Doug White To: John Baldwin In-Reply-To: <200504081656.51917.jhb@FreeBSD.org> Message-ID: <20050409231647.Y74901@carver.gumbysoft.com> References: <20050406233405.O47071@carver.gumbysoft.com> <200504081656.51917.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@FreeBSD.org Subject: Re: Potential source of interrupt aliasing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Apr 2005 06:22:23 -0000 On Fri, 8 Apr 2005, John Baldwin wrote: > > A quick hack would be to blacklist intpin 16 on the first IOAPIC and bump > > any PCI devices that ACPI says are claiming that interrupt. I don't know > > how difficult this is to do with ACPI. How to handle this for ATPIC mode > > is a little difficult since the boot interrupt either gets routed to IRQ9 > > or ends up as a stray on IRQ7 (on my SCB2 at least -- other boards may > > vary). > > You can't just move APIC interrupts around. They are physically wired that > way. ATPIC mode won't matter. If there is a way to disable this in > hardware, then it needs to be done in the _PIC method of the BIOS for ACPI. > I don't think there's any way to allow for this for non-ACPI though as the > MPTable spec only mentions the IMCR which these boards don't implement. I didn't think so, at least in the general case. It may be possible to reprogram ICH registers to have usb use other INT lines if they're coming up through SERIRQ and aren't physically wired to the pin, but I haven't dug through the docs for that. For fun, I put together this one-liner to at least test the theory: http://people.freebsd.org/~dwhite/intr_machdep.c.20050409.patch This makes the aliased interrupts go away at the cost of hitting sched_lock for each ithread interrupt. I'm trying to dream up a way of telling if the ithread is active or scheduled so we don't need to bump it again with setrunqueue(). I think I can use the it_need sparkplug to at least save mutex grabs on interrupts that fire much faster than their ithread handlers cycle. I'd like better granularity, though, but I'm not sure that setting a flag that is cleared just before mi_switch() in ithread_loop() and set just after won't race against an interrupt checking it to see if it needs to setrunqueue() the ithread. Maybe clear the flag before trying to grab sched_lock? I'm also not sure how much this change affects system performance. I guess I should hit up rwatson for some info on MUTEX_PROFILING. :) -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 09:10:39 2005 Return-Path: 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 CD62716A4CE for ; Sun, 10 Apr 2005 09:10:39 +0000 (GMT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8516843D2F for ; Sun, 10 Apr 2005 09:10:38 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DKYPz-0007cg-H8 for freebsd-current@freebsd.org; Sun, 10 Apr 2005 11:07:47 +0200 Received: from dhcp193.ifado.de ([195.253.22.193]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Apr 2005 11:07:47 +0200 Received: from wb by dhcp193.ifado.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Apr 2005 11:07:47 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: "Wilhelm B. Kloke" Date: Sun, 10 Apr 2005 09:07:36 +0000 (UTC) Organization: InstArbPhysUniDo Lines: 139 Message-ID: References: <20050406233405.O47071@carver.gumbysoft.com> <200504081656.51917.jhb@FreeBSD.org> <20050409231647.Y74901@carver.gumbysoft.com> X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: dhcp193.ifado.de User-Agent: slrn/0.9.8.0 (FreeBSD) Cache-Post-Path: vestein!unknown@yorikke X-Cache: nntpcache 3.0.1 (see http://www.nntpcache.org/) Sender: news Subject: Re: Potential source of interrupt aliasing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Apr 2005 09:10:39 -0000 Doug White schrieb: > On Fri, 8 Apr 2005, John Baldwin wrote: > > For fun, I put together this one-liner to at least test the theory: > > http://people.freebsd.org/~dwhite/intr_machdep.c.20050409.patch As I have found a problem which could be related to this, I tried your patch. For my problems, it made things not better, possibly worse. Now the description of my problem: I have got a NVidia Quadro card, which I want to use in active stereo mode. This worked approximately well on my older K6 system. Now I have upgraded to K8 (amd64). As NVidia does not supply amd64 drivers till now, I have installed an i386 FreeBSD-5.4 on the machine. I get interrupt rates above 85 on the irq11 line. Before patching up to 200, after patching more than 1000. I suspect that the warnings about $PIR may be related to my problem. Here is the dmesg (with your patch): 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 5.4-PRERELEASE #6: Sun Apr 10 10:49:37 CEST 2005 wb@wbk2:/home/src-5.3/sys/i386/compile/WBK Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 Processor 3000+ (1808.81-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x10ff0 Stepping = 0 Features=0x78bfbff AMD Features=0xe0500000 real memory = 1073676288 (1023 MB) avail memory = 1041125376 (992 MB) MPTable: ioapic0: Assuming intbase of 0 ioapic0 irqs 0-23 on motherboard npx0: on motherboard npx0: INT 16 interface cpu0 on motherboard pcib0: pcibus 0 on motherboard pir0: on motherboard pci0: on pcib0 $PIR: No matching entry for 0.1.INTA $PIR: No matching entry for 0.2.INTA $PIR: No matching entry for 0.2.INTB $PIR: No matching entry for 0.2.INTC $PIR: No matching entry for 0.5.INTA $PIR: No matching entry for 0.6.INTA $PIR: No matching entry for 0.10.INTA agp0: mem 0xe0000000-0xe7ffffff at device 0.0 on pci0 agp0: Unable to find NVIDIA Memory Controller 1. device_attach: agp0 attach returned 19 isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) ohci0: mem 0xfc003000-0xfc003fff irq 9 at device 2.0 on pci0 usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 4 ports with 4 removable, self powered ohci1: mem 0xfc004000-0xfc004fff irq 9 at device 2.1 on pci0 usb1: OHCI version 1.0, legacy support usb1: on ohci1 usb1: USB revision 1.0 uhub1: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 4 ports with 4 removable, self powered pci0: at device 2.2 (no driver attached) pci0: at device 5.0 (no driver attached) pci0: at device 6.0 (no driver attached) atapci0: port 0xf000-0xf00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 8.0 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 atapci1: port 0xdc00-0xdc0f,0xb70-0xb73,0x970-0x977,0xbf0-0xbf3,0x9f0-0x9f7 irq 11 at device 10.0 on pci0 ata2: channel #0 on atapci1 ata3: channel #1 on atapci1 pcib1: at device 11.0 on pci0 pci1: on pcib1 $PIR: ROUTE_INTERRUPT failed. nvidia0: mem 0xf0000000-0xf007ffff,0xe8000000-0xefffffff,0xf8000000-0xf8ffffff irq 11 at device 0.0 on pci1 pcib2: at device 14.0 on pci0 pci2: on pcib2 pcib2: unable to route slot 14 INTA skc0: port 0x9000-0x90ff mem 0xfb000000-0xfb003fff irq 19 at device 11.0 on pci2 skc0: Marvell Yukon Lite Gigabit Ethernet rev. A3(0x7) sk0: on skc0 sk0: Ethernet address: 00:0f:ea:5c:67:4a miibus0: on sk0 e1000phy0: on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto atapci2: port 0xa400-0xa40f,0xa000-0xa003,0x9c00-0x9c07,0x9800-0x9803,0x9400-0x9407 mem 0xfb009000-0xfb0091ff irq 17 at device 13.0 on pci2 ata4: channel #0 on atapci2 ata5: channel #1 on atapci2 fwohci0: mem 0xfb004000-0xfb007fff,0xfb008000-0xfb0087ff irq 5 at device 14.0 on pci2 fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:0f:ea:56:00:59:77:0a fwohci0: invalid speed 7 (fixed to 3). fwohci0: Phy 1394a available S800, 3 ports. fwohci0: Link S800, max_rec 4096 bytes. firewire0: on fwohci0 fwohci0: Initiate bus reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) fwohci0: phy int orm0: at iomem 0xd2000-0xd2fff,0xd0000-0xd17ff,0xc0000-0xcefff on isa0 pmtimer0 on isa0 atkbdc0: at port 0x64,0x60 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 unknown: can't assign resources (port) unknown: can't assign resources (irq) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) Timecounter "TSC" frequency 1808812877 Hz quality 800 Timecounters tick every 10.000 msec acd0: DVDR at ata0-master UDMA33 ad4: 152626MB [310098/16/63] at ata2-master UDMA33 Mounting root from ufs:/dev/ad4s4g -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 09:24:30 2005 Return-Path: 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 6C9E616A4CE; Sun, 10 Apr 2005 09:24:30 +0000 (GMT) Received: from wrzx28.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9872343D2F; Sun, 10 Apr 2005 09:24:29 +0000 (GMT) (envelope-from q@uni.de) Received: from wrzx34.rz.uni-wuerzburg.de (wrzx34.rz.uni-wuerzburg.de [132.187.3.34]) by wrzx28.rz.uni-wuerzburg.de (Postfix) with ESMTP id 50497D8143; Sun, 10 Apr 2005 11:24:28 +0200 (CEST) Received: from virusscan (localhost [127.0.0.1]) by wrzx34.rz.uni-wuerzburg.de (Postfix) with ESMTP id 3252CA790C; Sun, 10 Apr 2005 11:24:28 +0200 (CEST) Received: from wrzx28.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by wrzx34.rz.uni-wuerzburg.de (Postfix) with ESMTP id 0D350A77E2; Sun, 10 Apr 2005 11:24:28 +0200 (CEST) Received: from frodo.galgenberg.net (wwsx14.win-screen.uni-wuerzburg.de [132.187.253.14]) by wrzx28.rz.uni-wuerzburg.de (Postfix) with ESMTP id 2A130D8143; Sun, 10 Apr 2005 11:24:27 +0200 (CEST) Received: from coyote.q.local (gb-21-237.galgenberg.net [172.16.21.237]) by frodo.galgenberg.net (8.13.1/8.13.1) with ESMTP id j3A9ORrh030329; Sun, 10 Apr 2005 11:24:27 +0200 (CEST) (envelope-from q@uni.de) Received: from roadrunner.q.local (roadrunner.q.local [192.168.0.148]) by coyote.q.local (8.13.1/8.13.1) with ESMTP id j3A9OQrY015207; Sun, 10 Apr 2005 11:24:26 +0200 (CEST) (envelope-from q@uni.de) Received: from roadrunner.q.local (localhost [127.0.0.1]) by roadrunner.q.local (8.13.3/8.13.1) with ESMTP id j3A9OPmc001715; Sun, 10 Apr 2005 11:24:25 +0200 (CEST) (envelope-from q@uni.de) Received: (from q@localhost) by roadrunner.q.local (8.13.3/8.13.1/Submit) id j3A9OH9d001714; Sun, 10 Apr 2005 11:24:17 +0200 (CEST) (envelope-from q@uni.de) Date: Sun, 10 Apr 2005 11:24:17 +0200 From: Ulrich Spoerlein To: takawata@jp.freebsd.org Message-ID: <20050410092417.GA774@galgenberg.net> Mail-Followup-To: takawata@jp.freebsd.org, jeff@freebsd.org, bp@freebsd.org, freebsd-fs@freebsd.org, freebsd-current@freebsd.org References: <200504100251.j3A2pLEH055107@sana.init-main.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mYCpIKhGyMATD0i+" Content-Disposition: inline In-Reply-To: <200504100251.j3A2pLEH055107@sana.init-main.com> User-Agent: Mutt/1.5.8i X-Virus-Scanned: by amavisd-new (Rechenzentrum Universitaet Wuerzburg) cc: freebsd-fs@freebsd.org cc: bp@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: smbfs bug introduced at smbfs_vnops.c:1.58 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Apr 2005 09:24:30 -0000 --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, 10.04.2005 at 11:51:21 +0900, takawata@jp.freebsd.org wrote: > This is caused by uninitialized vp. The compiler should warn about this. But something fishy is going on ... foo.c: int main(void) { int a; a+=3D1; return (0); } % gcc -O -W -Wall -Wuninitialized -Winit-self foo.c % icc -Wbrief -Wall foo.c foo.c(3): remark #592: variable "a" is used before its value is set % tdfc2 -Wall foo.c >/dev/null "foo.c", line 2: Warning: [ISO C90 6.6.2]: Variable 'a' may be used without being set. "foo.c", line 4: Warning: [ISO C90 6.6.2]: Variable 'a' not used since previous assignment. % lint -i foo.c foo.c(3): warning: a may be used before set [158] % splint foo.c foo.c: (in function main) foo.c:3:3: Variable a used before definition Any magical flags for gcc I'm missing? Ulrich Sp=F6rlein --=20 PGP Key ID: F0DB9F44 Encrypted mail welcome! Fingerprint: F1CE D062 0CA9 ADE3 349B 2FE8 980A C6B5 F0DB 9F44 Ok, which part of "Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn." didn't you understand? --mYCpIKhGyMATD0i+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCWPDBmArGtfDbn0QRAlv6AKC77uh+sjX194oE+bKlqP4Vu7mCnQCdE6e+ jtlhJSlW7079+S6308/3i24= =Z3PH -----END PGP SIGNATURE----- --mYCpIKhGyMATD0i+-- From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 11:09:02 2005 Return-Path: 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 23FB716A4CE; Sun, 10 Apr 2005 11:09:02 +0000 (GMT) Received: from bremen.shuttle.de (bremen.shuttle.de [194.95.249.251]) by mx1.FreeBSD.org (Postfix) with ESMTP id C98B143D2F; Sun, 10 Apr 2005 11:09:00 +0000 (GMT) (envelope-from schweikh@schweikhardt.net) Received: by bremen.shuttle.de (Postfix, from userid 10) id DBBD23B8C3; Sun, 10 Apr 2005 13:08:58 +0200 (CEST) Received: from hal9000.schweikhardt.net (localhost [127.0.0.1]) j3AB8aD2003502; Sun, 10 Apr 2005 13:08:36 +0200 (CEST) (envelope-from schweikh@hal9000.schweikhardt.net) Received: (from schweikh@localhost) by hal9000.schweikhardt.net (8.13.3/8.13.3/Submit) id j3AB8aMK003501; Sun, 10 Apr 2005 13:08:36 +0200 (CEST) (envelope-from schweikh) Date: Sun, 10 Apr 2005 13:08:36 +0200 From: Jens Schweikhardt To: takawata@jp.freebsd.org, jeff@freebsd.org, bp@freebsd.org, freebsd-fs@freebsd.org, freebsd-current@freebsd.org Message-ID: <20050410110836.GA1355@schweikhardt.net> References: <200504100251.j3A2pLEH055107@sana.init-main.com> <20050410092417.GA774@galgenberg.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050410092417.GA774@galgenberg.net> User-Agent: Mutt/1.5.9i Subject: Re: smbfs bug introduced at smbfs_vnops.c:1.58 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Apr 2005 11:09:02 -0000 On Sun, Apr 10, 2005 at 11:24:17AM +0200, Ulrich Spoerlein wrote: # On Sun, 10.04.2005 at 11:51:21 +0900, takawata@jp.freebsd.org wrote: # > This is caused by uninitialized vp. # # The compiler should warn about this. But something fishy is going on ... # # foo.c: # int main(void) { # int a; # a+=1; # return (0); # } Not so fishy. No warning because -O completely optimizes 'a' away. Try this instead: $ cat foo.c int main(void) { int a; a+=1; return a; } $ gcc -O -W -Wall -Wuninitialized -Winit-self foo.c foo.c: In function `main': foo.c:2: warning: 'a' might be used uninitialized in this function Regards, Jens -- Jens Schweikhardt http://www.schweikhardt.net/ SIGSIG -- signature too long (core dumped) From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 11:12:05 2005 Return-Path: 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 E343816A4CE; Sun, 10 Apr 2005 11:12:05 +0000 (GMT) Received: from dlb139.neoplus.adsl.tpnet.pl (dln55.neoplus.adsl.tpnet.pl [83.24.43.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11C0E43D2D; Sun, 10 Apr 2005 11:12:05 +0000 (GMT) (envelope-from w@dln55.neoplus.adsl.tpnet.pl) Received: from dln55.neoplus.adsl.tpnet.pl (w@localhost [127.0.0.1]) j3ABC3Uv006255; Sun, 10 Apr 2005 13:12:03 +0200 (CEST) (envelope-from w@dln55.neoplus.adsl.tpnet.pl) Received: (from w@localhost)j3ABC3Zg006254; Sun, 10 Apr 2005 13:12:03 +0200 (CEST) (envelope-from w) Date: Sun, 10 Apr 2005 13:12:02 +0200 From: Wiktor Niesiobedzki To: current@freebsd.org Message-ID: <20050410111202.GA5980@dln55.neoplus.adsl.tpnet.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i cc: sos@freebsd.org Subject: ATA MkIII - Hang after resume solution X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Apr 2005 11:12:06 -0000 Hi, I think I found solution to the problem, that after MkIII disks does not reinit. Solution is simple: --- /usr/src/sys/dev/ata/ata-pci.c Fri Apr 8 11:37:47 2005 +++ /tmp/ata-pci.c Sun Apr 10 13:09:48 2005 @@ -599,8 +599,8 @@ DEVMETHOD(device_attach, ata_pcichannel_attach), DEVMETHOD(device_detach, ata_pcichannel_detach), DEVMETHOD(device_shutdown, bus_generic_shutdown), - DEVMETHOD(device_suspend, bus_generic_suspend), - DEVMETHOD(device_resume, bus_generic_resume), + DEVMETHOD(device_suspend, ata_suspend), + DEVMETHOD(device_resume, ata_resume), /* ATA methods */ DEVMETHOD(ata_setmode, ata_pcichannel_setmode), This is rollback of changes introduced by MkIII. After that change suspend/resume works again. Can anybody review this? Cheers, Wiktor Niesiobedzki From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 11:46:02 2005 Return-Path: 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 49C8D16A4CE; Sun, 10 Apr 2005 11:46:02 +0000 (GMT) Received: from mail.eecs.harvard.edu (bowser.eecs.harvard.edu [140.247.60.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB10D43D2F; Sun, 10 Apr 2005 11:46:01 +0000 (GMT) (envelope-from ellard@eecs.harvard.edu) Received: from localhost (localhost.eecs.harvard.edu [127.0.0.1]) by mail.eecs.harvard.edu (Postfix) with ESMTP id 2AF0354C865; Sun, 10 Apr 2005 07:45:51 -0400 (EDT) Received: from mail.eecs.harvard.edu ([127.0.0.1]) by localhost (bowser.eecs.harvard.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68484-04; Sun, 10 Apr 2005 07:45:51 -0400 (EDT) Received: by mail.eecs.harvard.edu (Postfix, from userid 465) id E3F1C54C66F; Sun, 10 Apr 2005 07:45:50 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.eecs.harvard.edu (Postfix) with ESMTP id E12F754C543; Sun, 10 Apr 2005 07:45:50 -0400 (EDT) Date: Sun, 10 Apr 2005 07:45:50 -0400 (EDT) From: Daniel Ellard To: Ulrich Spoerlein In-Reply-To: <20050410092417.GA774@galgenberg.net> Message-ID: <20050410074009.N66651@bowser.eecs.harvard.edu> References: <200504100251.j3A2pLEH055107@sana.init-main.com> <20050410092417.GA774@galgenberg.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at eecs.harvard.edu X-Mailman-Approved-At: Sun, 10 Apr 2005 11:48:43 +0000 cc: freebsd-fs@freebsd.org cc: bp@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: smbfs bug introduced at smbfs_vnops.c:1.58 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Apr 2005 11:46:02 -0000 On Sun, 10 Apr 2005, Ulrich Spoerlein wrote: > Date: Sun, 10 Apr 2005 11:24:17 +0200 > From: Ulrich Spoerlein > To: takawata@jp.freebsd.org > Cc: freebsd-fs@freebsd.org, bp@freebsd.org, jeff@freebsd.org, > freebsd-current@freebsd.org > Subject: Re: smbfs bug introduced at smbfs_vnops.c:1.58 > > On Sun, 10.04.2005 at 11:51:21 +0900, takawata@jp.freebsd.org wrote: > > This is caused by uninitialized vp. > > The compiler should warn about this. But something fishy is going on ... > > foo.c: > int main(void) { > int a; > a+=1; > return (0); > } > > % gcc -O -W -Wall -Wuninitialized -Winit-self foo.c Certainly this is undesireable, but from what I can tell this happens because "a" is a dead variable and removed. (Look at the asm output and you'll see what I mean.) So it's debatable whether this is a bug. If you change the -O to -g, then the code for "a" is not removed -- but there's still no warning. I think this is a bug, because if the expression wasn't an innocuous a+=1 it could be a real problem if the variable wasn't removed. But people will also argue about this.. -Dan From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 12:03:41 2005 Return-Path: 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 D3A2416A4CE; Sun, 10 Apr 2005 12:03:41 +0000 (GMT) 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 1B7A143D1D; Sun, 10 Apr 2005 12:03:41 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.13.3/8.13.3) with ESMTP id j3AC3cX4015081; Sun, 10 Apr 2005 14:03:38 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <425915B9.3000606@DeepCore.dk> Date: Sun, 10 Apr 2005 14:02:01 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Wiktor Niesiobedzki References: <20050410111202.GA5980@dln55.neoplus.adsl.tpnet.pl> In-Reply-To: <20050410111202.GA5980@dln55.neoplus.adsl.tpnet.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-mail-scanned: by DeepCore Virus & Spam killer v1.12 cc: current@FreeBSD.ORG cc: sos@FreeBSD.ORG Subject: Re: ATA MkIII - Hang after resume solution X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Apr 2005 12:03:41 -0000 Wiktor Niesiobedzki wrote: > Hi, >=20 > I think I found solution to the problem, that after MkIII disks does no= t > reinit. Solution is simple: >=20 > --- /usr/src/sys/dev/ata/ata-pci.c Fri Apr 8 11:37:47 2005 > +++ /tmp/ata-pci.c Sun Apr 10 13:09:48 2005 > @@ -599,8 +599,8 @@ > DEVMETHOD(device_attach, ata_pcichannel_attach), > DEVMETHOD(device_detach, ata_pcichannel_detach), > DEVMETHOD(device_shutdown, bus_generic_shutdown), > - DEVMETHOD(device_suspend, bus_generic_suspend), > - DEVMETHOD(device_resume, bus_generic_resume), > + DEVMETHOD(device_suspend, ata_suspend), > + DEVMETHOD(device_resume, ata_resume), > =20 > /* ATA methods */ > DEVMETHOD(ata_setmode, ata_pcichannel_setmode), >=20 > This is rollback of changes introduced by MkIII. After that change > suspend/resume works again. >=20 > Can anybody review this? I'll look into this and try to find out when/how this got changed. Looks like a good catch though! thanks! --=20 -S=F8ren From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 12:04:48 2005 Return-Path: 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 654A116A4CE; Sun, 10 Apr 2005 12:04:48 +0000 (GMT) Received: from tensor.xs4all.nl (tensor.xs4all.nl [194.109.160.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id B785643D2F; Sun, 10 Apr 2005 12:04:47 +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 0474622867; Sun, 10 Apr 2005 14:04:44 +0200 (CEST) Date: Sun, 10 Apr 2005 14:04:23 +0200 From: Dimitry Andric X-Priority: 3 (Normal) Message-ID: <1892195662.20050410140423@andric.com> To: Daniel Ellard In-Reply-To: <20050410074009.N66651@bowser.eecs.harvard.edu> References: <200504100251.j3A2pLEH055107@sana.init-main.com> <20050410092417.GA774@galgenberg.net> <20050410074009.N66651@bowser.eecs.harvard.edu> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="----------1291C69219E9F339" cc: freebsd-fs@freebsd.org cc: bp@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: smbfs bug introduced at smbfs_vnops.c:1.58 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Apr 2005 12:04:48 -0000 ------------1291C69219E9F339 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On 2005-04-10 at 13:45:50 Daniel Ellard wrote: >> int main(void) { >> int a; >> a+=1; >> return (0); >> } [snip] > If you change the -O to -g, then the code for "a" is not > removed -- but there's still no warning. I think this is > a bug, because if the expression wasn't an innocuous a+=1 > it could be a real problem if the variable wasn't removed. The idea here is that gcc sees that the value of a is never used, and therefore it doesn't have to warn. (Whether you agree with this, or not, is more of a political or philosophical question. ;) But as soon as you actually *do* something with a's value afterwards, it will start to complain. IOW, if you change main into: int main(void) { int a; a += 1; a++; //...bunch of other operations on a... ++a; a *= 3; return 0; } and gcc will still issue no warning. However, add one actual *use* of a: extern void f(int i); int main(void) { int a; a += 1; f(a); return 0; } and you'll get the warning you want... :) ------------1291C69219E9F339 Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.0 (MingW32) iD8DBQFCWRZHsF6jCi4glqMRAlQwAKCcHtIlJkcR3rdp2N99qz6JimAGLwCcDisx Xiqm/Q0yy9TeULi2QHQnwts= =hO98 -----END PGP MESSAGE----- ------------1291C69219E9F339-- From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 12:28:48 2005 Return-Path: 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 DE95E16A4CE for ; Sun, 10 Apr 2005 12:28:48 +0000 (GMT) Received: from email.aon.at (warsl404pip7.highway.telekom.at [195.3.96.91]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD4CD43D48 for ; Sun, 10 Apr 2005 12:28:47 +0000 (GMT) (envelope-from shoesoft@gmx.net) Received: (qmail 7869 invoked from network); 10 Apr 2005 12:28:11 -0000 Received: from m106p003.dipool.highway.telekom.at ([62.46.3.35]) (envelope-sender ) by smarthub76.highway.telekom.at (qmail-ldap-1.03) with SMTP for ; 10 Apr 2005 12:28:11 -0000 From: Stefan Ehmann To: Wiktor Niesiobedzki In-Reply-To: <20050410111202.GA5980@dln55.neoplus.adsl.tpnet.pl> References: <20050410111202.GA5980@dln55.neoplus.adsl.tpnet.pl> Content-Type: text/plain Date: Sun, 10 Apr 2005 14:28:43 +0200 Message-Id: <1113136123.1530.3.camel@taxman.pepperland> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit cc: current@freebsd.org cc: sos@freebsd.org Subject: Re: ATA MkIII - Hang after resume solution X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Apr 2005 12:28:49 -0000 On Sun, 2005-04-10 at 13:12 +0200, Wiktor Niesiobedzki wrote: > Hi, > > I think I found solution to the problem, that after MkIII disks does not > reinit. Solution is simple: > > --- /usr/src/sys/dev/ata/ata-pci.c Fri Apr 8 11:37:47 2005 > +++ /tmp/ata-pci.c Sun Apr 10 13:09:48 2005 > @@ -599,8 +599,8 @@ > DEVMETHOD(device_attach, ata_pcichannel_attach), > DEVMETHOD(device_detach, ata_pcichannel_detach), > DEVMETHOD(device_shutdown, bus_generic_shutdown), > - DEVMETHOD(device_suspend, bus_generic_suspend), > - DEVMETHOD(device_resume, bus_generic_resume), > + DEVMETHOD(device_suspend, ata_suspend), > + DEVMETHOD(device_resume, ata_resume), > > /* ATA methods */ > DEVMETHOD(ata_setmode, ata_pcichannel_setmode), > > This is rollback of changes introduced by MkIII. After that change > suspend/resume works again. > > Can anybody review this? This causes a kernel panic in ata_reinit for me. (no detailed info available since the computer freezes hard at that point) From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 12:44:45 2005 Return-Path: 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 7155B16A4CE; Sun, 10 Apr 2005 12:44:45 +0000 (GMT) Received: from mail.eecs.harvard.edu (bowser.eecs.harvard.edu [140.247.60.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id D664743D54; Sun, 10 Apr 2005 12:44:44 +0000 (GMT) (envelope-from ellard@eecs.harvard.edu) Received: from localhost (localhost.eecs.harvard.edu [127.0.0.1]) by mail.eecs.harvard.edu (Postfix) with ESMTP id 59EB654C9FB; Sun, 10 Apr 2005 08:44:44 -0400 (EDT) Received: from mail.eecs.harvard.edu ([127.0.0.1]) by localhost (bowser.eecs.harvard.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77977-09; Sun, 10 Apr 2005 08:44:44 -0400 (EDT) Received: by mail.eecs.harvard.edu (Postfix, from userid 465) id 17DE054C9A0; Sun, 10 Apr 2005 08:44:44 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.eecs.harvard.edu (Postfix) with ESMTP id 14E5154C993; Sun, 10 Apr 2005 08:44:44 -0400 (EDT) Date: Sun, 10 Apr 2005 08:44:44 -0400 (EDT) From: Daniel Ellard To: Dimitry Andric In-Reply-To: <1892195662.20050410140423@andric.com> Message-ID: <20050410082945.H66651@bowser.eecs.harvard.edu> References: <200504100251.j3A2pLEH055107@sana.init-main.com> <20050410074009.N66651@bowser.eecs.harvard.edu> <1892195662.20050410140423@andric.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at eecs.harvard.edu X-Mailman-Approved-At: Sun, 10 Apr 2005 12:55:34 +0000 cc: freebsd-fs@freebsd.org cc: bp@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: smbfs bug introduced at smbfs_vnops.c:1.58 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Apr 2005 12:44:45 -0000 On Sun, 10 Apr 2005, Dimitry Andric wrote: > > If you change the -O to -g, then the code for "a" is not > > removed -- but there's still no warning. I think this is > > a bug, because if the expression wasn't an innocuous a+=1 > > it could be a real problem if the variable wasn't removed. > > The idea here is that gcc sees that the value of a is never used, and > therefore it doesn't have to warn. (Whether you agree with this, or > not, is more of a political or philosophical question. ;) But as soon > as you actually *do* something with a's value afterwards, it will > start to complain. Well, I guess have to give an example... int main(void) { int a; int b[1]; a = b[a * 10000]; /* Uses the value of a. */ return (0); } If you compile this with -O, then the "a = " line is optimized away, and the deref of some random piece of memory goes away. If you compile this without the -O then now you have a deref to something whose address depends on an uninitialized variable. Sorry, that's bad. At least the gcc folk now do detect this old chestnut: { int a; a /= 0; } which was used to provoke arguments in compiler classes for many years. (Optimized, nothing happens. Unoptimized, a division-by-zero error happens...) My philosophy is that the compiler should warn you about things in the un-optimized, un-transformed code (because that's where I put my bugs -- if I've written code that has no effect, that's probably not what I meant). I'd rather get extraneous warnings than miss something. Of course, everyone is welcome to their own philosophy. (But how politics enter into this, I don't want to know.) -Dan From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 13:21:43 2005 Return-Path: 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 9E61016A4CE; Sun, 10 Apr 2005 13:21:43 +0000 (GMT) Received: from wrzx28.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id A5DFF43D3F; Sun, 10 Apr 2005 13:21:42 +0000 (GMT) (envelope-from q@uni.de) Received: from wrzx34.rz.uni-wuerzburg.de (wrzx34.rz.uni-wuerzburg.de [132.187.3.34]) by wrzx28.rz.uni-wuerzburg.de (Postfix) with ESMTP id BC7F9D8408; Sun, 10 Apr 2005 15:21:41 +0200 (CEST) Received: from virusscan (localhost [127.0.0.1]) by wrzx34.rz.uni-wuerzburg.de (Postfix) with ESMTP id A2265AC592; Sun, 10 Apr 2005 15:21:41 +0200 (CEST) Received: from wrzx28.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by wrzx34.rz.uni-wuerzburg.de (Postfix) with ESMTP id 6AF2EA77E2; Sun, 10 Apr 2005 15:21:41 +0200 (CEST) Received: from frodo.galgenberg.net (wwsx14.win-screen.uni-wuerzburg.de [132.187.253.14]) by wrzx28.rz.uni-wuerzburg.de (Postfix) with ESMTP id 4D117D8408; Sun, 10 Apr 2005 15:21:38 +0200 (CEST) Received: from coyote.q.local (gb-21-237.galgenberg.net [172.16.21.237]) by frodo.galgenberg.net (8.13.1/8.13.1) with ESMTP id j3ADLc9H010232; Sun, 10 Apr 2005 15:21:38 +0200 (CEST) (envelope-from q@uni.de) Received: from roadrunner.q.local (roadrunner.q.local [192.168.0.148]) by coyote.q.local (8.13.1/8.13.1) with ESMTP id j3ADLbrQ016229; Sun, 10 Apr 2005 15:21:37 +0200 (CEST) (envelope-from q@uni.de) Received: from roadrunner.q.local (localhost [127.0.0.1]) by roadrunner.q.local (8.13.3/8.13.1) with ESMTP id j3ADLbTF012473; Sun, 10 Apr 2005 15:21:37 +0200 (CEST) (envelope-from q@uni.de) Received: (from q@localhost) by roadrunner.q.local (8.13.3/8.13.1/Submit) id j3ADLZpa012472; Sun, 10 Apr 2005 15:21:35 +0200 (CEST) (envelope-from q@uni.de) Date: Sun, 10 Apr 2005 15:21:35 +0200 From: Ulrich Spoerlein To: Daniel Ellard Message-ID: <20050410132135.GB774@galgenberg.net> Mail-Followup-To: Daniel Ellard , takawata@jp.freebsd.org, freebsd-fs@freebsd.org, bp@freebsd.org, jeff@freebsd.org, freebsd-current@freebsd.org References: <200504100251.j3A2pLEH055107@sana.init-main.com> <20050410092417.GA774@galgenberg.net> <20050410074009.N66651@bowser.eecs.harvard.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7ZAtKRhVyVSsbBD2" Content-Disposition: inline In-Reply-To: <20050410074009.N66651@bowser.eecs.harvard.edu> User-Agent: Mutt/1.5.8i X-Virus-Scanned: by amavisd-new (Rechenzentrum Universitaet Wuerzburg) cc: freebsd-fs@freebsd.org cc: bp@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: smbfs bug introduced at smbfs_vnops.c:1.58 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Apr 2005 13:21:43 -0000 --7ZAtKRhVyVSsbBD2 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, 10.04.2005 at 07:45:50 -0400, Daniel Ellard wrote: > Certainly this is undesireable, but from what I can tell this > happens because "a" is a dead variable and removed. (Look at > the asm output and you'll see what I mean.) So it's debatable > whether this is a bug. >=20 > If you change the -O to -g, then the code for "a" is not > removed -- but there's still no warning. I think this is > a bug, because if the expression wasn't an innocuous a+=3D1 > it could be a real problem if the variable wasn't removed. > But people will also argue about this.. You are right, using something like this: #include int main(void) { int a,b; a+=3D1; b=3D1+a; printf("%d\n", b); return (0); } I get a warning: % cc -O -W -Wall -Wuninitialized foo.c foo.c: In function `main': foo.c:3: warning: 'a' might be used uninitialized in this function Sorry for the noise then. /me needs to learn asm some day. Ulrich Sp=F6rlein --=20 PGP Key ID: F0DB9F44 Encrypted mail welcome! Fingerprint: F1CE D062 0CA9 ADE3 349B 2FE8 980A C6B5 F0DB 9F44 Ok, which part of "Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn." didn't you understand? --7ZAtKRhVyVSsbBD2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCWShfmArGtfDbn0QRAiE8AJ9+UpRfN2zL4Pgj9lvXsDx8LLQKcACgxgv6 6mXAFnU8+XSLDHhh8FL2YqY= =KQlv -----END PGP SIGNATURE----- --7ZAtKRhVyVSsbBD2-- From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 13:48:41 2005 Return-Path: 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 0D00D16A4CE for ; Sun, 10 Apr 2005 13:48:41 +0000 (GMT) Received: from wrzx35.rz.uni-wuerzburg.de (wrzx35.rz.uni-wuerzburg.de [132.187.3.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2948843D1D for ; Sun, 10 Apr 2005 13:48:40 +0000 (GMT) (envelope-from q@uni.de) Received: from wrzx34.rz.uni-wuerzburg.de (wrzx34.rz.uni-wuerzburg.de [132.187.3.34]) by wrzx35.rz.uni-wuerzburg.de (Postfix) with ESMTP id CDC8EE105E; Sun, 10 Apr 2005 15:48:38 +0200 (CEST) Received: from virusscan (localhost [127.0.0.1]) by wrzx34.rz.uni-wuerzburg.de (Postfix) with ESMTP id ADAACA79DE; Sun, 10 Apr 2005 15:48:38 +0200 (CEST) Received: from wrzx28.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by wrzx34.rz.uni-wuerzburg.de (Postfix) with ESMTP id 86BF5A77E2; Sun, 10 Apr 2005 15:48:38 +0200 (CEST) Received: from frodo.galgenberg.net (wwsx14.win-screen.uni-wuerzburg.de [132.187.253.14]) by wrzx28.rz.uni-wuerzburg.de (Postfix) with ESMTP id 6CD47D8498; Sun, 10 Apr 2005 15:48:38 +0200 (CEST) Received: from coyote.q.local (gb-21-237.galgenberg.net [172.16.21.237]) by frodo.galgenberg.net (8.13.1/8.13.1) with ESMTP id j3ADmcsa019898; Sun, 10 Apr 2005 15:48:38 +0200 (CEST) (envelope-from q@uni.de) Received: from roadrunner.q.local (roadrunner.q.local [192.168.0.148]) by coyote.q.local (8.13.1/8.13.1) with ESMTP id j3ADmcv2016324; Sun, 10 Apr 2005 15:48:38 +0200 (CEST) (envelope-from q@uni.de) Received: from roadrunner.q.local (localhost [127.0.0.1]) by roadrunner.q.local (8.13.3/8.13.1) with ESMTP id j3ADmc2S012982; Sun, 10 Apr 2005 15:48:38 +0200 (CEST) (envelope-from q@uni.de) Received: (from q@localhost) by roadrunner.q.local (8.13.3/8.13.1/Submit) id j3ADmbJZ012981; Sun, 10 Apr 2005 15:48:37 +0200 (CEST) (envelope-from q@uni.de) Date: Sun, 10 Apr 2005 15:48:37 +0200 From: Ulrich Spoerlein To: Jens Schweikhardt Message-ID: <20050410134837.GC774@galgenberg.net> Mail-Followup-To: Jens Schweikhardt , freebsd-current@freebsd.org References: <200504100251.j3A2pLEH055107@sana.init-main.com> <20050410092417.GA774@galgenberg.net> <20050410110836.GA1355@schweikhardt.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="z4+8/lEcDcG5Ke9S" Content-Disposition: inline In-Reply-To: <20050410110836.GA1355@schweikhardt.net> User-Agent: Mutt/1.5.8i X-Virus-Scanned: by amavisd-new (Rechenzentrum Universitaet Wuerzburg) cc: freebsd-current@freebsd.org Subject: Re: smbfs bug introduced at smbfs_vnops.c:1.58 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Apr 2005 13:48:41 -0000 --z4+8/lEcDcG5Ke9S Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, 10.04.2005 at 13:08:36 +0200, Jens Schweikhardt wrote: > # The compiler should warn about this. But something fishy is going on ... > #=20 > # foo.c: > # int main(void) { > # int a; > # a+=3D1; > # return (0); > # } >=20 > Not so fishy. No warning because -O completely optimizes 'a' away. Try > this instead: >=20 > $ cat foo.c > int main(void) { > int a; > a+=3D1; > return a; > } > $ gcc -O -W -Wall -Wuninitialized -Winit-self foo.c > foo.c: In function `main': > foo.c:2: warning: 'a' might be used uninitialized in this function True, but the compiler should warn about bogus source code, even if the resulting object code (depending on optmiziation flags) is valid. IMHO Let's get back to the bug in smbfs_vnops.c, did the compiler issue a warning? Ulrich Sp=F6rlein --=20 PGP Key ID: F0DB9F44 Encrypted mail welcome! Fingerprint: F1CE D062 0CA9 ADE3 349B 2FE8 980A C6B5 F0DB 9F44 Ok, which part of "Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn." didn't you understand? --z4+8/lEcDcG5Ke9S Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCWS61mArGtfDbn0QRAt04AKCVUoCrJ+WV40dYYLkw/7ckoVxmSQCfdmHv ZqgR9tVrIromvkolqdfnzLI= =FSaw -----END PGP SIGNATURE----- --z4+8/lEcDcG5Ke9S-- From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 14:40:46 2005 Return-Path: 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 96E6616A4CE for ; Sun, 10 Apr 2005 14:40:46 +0000 (GMT) Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00F9F43D2D for ; Sun, 10 Apr 2005 14:40:46 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from herbelot.dyndns.org (unknown [82.227.159.103]) by postfix3-1.free.fr (Postfix) with ESMTP id 2A603173496 for ; Sun, 10 Apr 2005 16:40:45 +0200 (CEST) Received: from diversion.herbelot.nom (diversion.herbelot.nom [192.168.2.6]) by herbelot.dyndns.org (8.13.0/8.13.0) with ESMTP id j3AEeWek012872; Sun, 10 Apr 2005 16:40:37 +0200 (CEST) From: Thierry Herbelot To: current@freebsd.org Date: Sun, 10 Apr 2005 16:40:21 +0200 User-Agent: KMail/1.8 X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504101640.23906.thierry@herbelot.com> cc: bzeeb+freebsd+lor@zabbadoz.net Subject: new LOR report X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: thierry@herbelot.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, 10 Apr 2005 14:40:46 -0000 This LOR also seems not to have been reported : [SNIP multi-user boot dmesg] ..... SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad0s1a lock order reversal 1st 0xc095cce0 vm page queue mutex (vm page queue mutex) @ /usr/src/sys/kern/vfs_bio.c:1485 2nd 0xc1569d6c vnode interlock (vnode interlock) @ /usr/src/sys/kern/vfs_subr.c:1989 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c0911fe8,c0910aa8,c089cf68) at kdb_backtrace+0x29 witness_checkorder(c1569d6c,9,c0842b5f,7c5) at witness_checkorder+0x550 _mtx_lock_flags(c1569d6c,0,c0842b5f,7c5,c105cce4) at _mtx_lock_flags+0x5b vdrop(c1569cf0) at vdrop+0x1d vm_page_remove(c130fa98,c130fa98) at vm_page_remove+0xd4 vm_page_free_toq(c130fa98,c130fa98,40,c130fa98,c8e038ec) at vm_page_free_toq+0x90 vm_page_free(c130fa98,c130fa98) at vm_page_free+0x15 vfs_vmio_release(c44e7a10) at vfs_vmio_release+0x9b brelse(c44e7a10,c135c180,1,c0613134,0) at brelse+0x485 ffs_mountfs(c1569cf0,c154ec00,c135e480,c15111f0,0) at ffs_mountfs+0x555 ffs_mount(c154ec00,c135e480,0,0,c156a000) at ffs_mount+0x9ad vfs_domount(c135e480,c1511b80,c1520870,4001,c1511500) at vfs_domount+0x589 vfs_donmount(c135e480,4001,c8e03c30,c1557380,6) at vfs_donmount+0xce kernel_mount(c15110a0,4001,c8e03c98,c8e03cc4,c066a416) at kernel_mount+0x6d kernel_vmount(4001,c08425dd,c1520840,c08425e4,c083d857) at kernel_vmount+0x37 vfs_mountroot_try(c1520710,c08362bc,204,c135dde4,c05f5074) at vfs_mountroot_try+0xd2 vfs_mountroot(c135dde4,c135e480,25d,c135e480,c8e03d08) at vfs_mountroot+0x18f start_init(0,c8e03d48,0,c05f5074,0) at start_init+0x4b fork_exit(c05f5074,0,c8e03d48) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xc8e03d7c, ebp = 0 --- Pre-seeding PRNG: kickstart. .... with : FreeBSD 6.0-CURRENT #581: Sun Apr 10 15:28:58 CEST 2005 XXX@YYY:/usr/obj/usr/src/sys/GENERIC TfH From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 15:00:42 2005 Return-Path: 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 A0BAF16A512 for ; Sun, 10 Apr 2005 15:00:42 +0000 (GMT) Received: from mailout10.sul.t-online.com (mailout10.sul.t-online.com [194.25.134.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E7ED243D45 for ; Sun, 10 Apr 2005 15:00:41 +0000 (GMT) (envelope-from mike@reifenberger.com) Received: from fwd16.aul.t-online.de by mailout10.sul.t-online.com with smtp id 1DKdvS-00016h-04; Sun, 10 Apr 2005 17:00:38 +0200 Received: from fw.reifenberger.com (ExSFDqZSZeUQ1kLKvUU8u2JNsxSsq6fLnFU5Qo4OqlKi8Cvo38g5r6@[62.158.171.84]) by fwd16.sul.t-online.de with esmtp id 1DKdvP-0x68gq0; Sun, 10 Apr 2005 17:00:35 +0200 Received: from localhost (mike@localhost)j3AF0YXk038260 for ; Sun, 10 Apr 2005 17:00:34 +0200 (CEST) (envelope-from mike@reifenberger.com) X-Authentication-Warning: fw.reifenberger.com: mike owned process doing -bs Date: Sun, 10 Apr 2005 17:00:34 +0200 (CEST) From: Michael Reifenberger To: FreeBSD-Current Message-ID: <20050410164959.G38200@fw.reifenberger.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-ID: ExSFDqZSZeUQ1kLKvUU8u2JNsxSsq6fLnFU5Qo4OqlKi8Cvo38g5r6@t-dialin.net X-TOI-MSGID: 3b5dafa4-595a-4eed-baea-87156e6d5685 Subject: SATA with new ata code doesn't work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Apr 2005 15:00:42 -0000 Hi, after upgrading to the latest -current, my ASUS A8V deluxe board doesn't boot because its missing the ad0/ad1 devices. These are WD SATA disks hanging on: atapci0: port 0xd000-0xd007,0xc800-0xc803,0xc400-0xc407,0xc000-0xc 003,0xb800-0xb80f,0xb400-0xb4ff irq 20 at device 15.0 on pci0 ata2: channel #0 on atapci0 ata3: channel #1 on atapci0 and get usually probed as: acd0: DVDR at ata1-master UDMA33 ad0: 70911MB [144073/16/63] at ata2-master SATA150 ad1: 70911MB [144073/16/63] at ata3-master SATA150 Is this a known problem? Any additional information needed? Bye/2 --- Michael Reifenberger, Business Development Manager SAP-Basis, Plaut Consulting Comp: Michael.Reifenberger@plaut.de | Priv: Michael@Reifenberger.com http://www.plaut.de | http://www.Reifenberger.com From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 17:05:14 2005 Return-Path: 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 721CF16A4CE; Sun, 10 Apr 2005 17:05:14 +0000 (GMT) Received: from dlb139.neoplus.adsl.tpnet.pl (dln55.neoplus.adsl.tpnet.pl [83.24.43.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BEBF43D2D; Sun, 10 Apr 2005 17:05:13 +0000 (GMT) (envelope-from w@dln55.neoplus.adsl.tpnet.pl) Received: from dln55.neoplus.adsl.tpnet.pl (w@localhost [127.0.0.1]) j3AH5CUv013891; Sun, 10 Apr 2005 19:05:12 +0200 (CEST) (envelope-from w@dln55.neoplus.adsl.tpnet.pl) Received: (from w@localhost)j3AH5CQD013890; Sun, 10 Apr 2005 19:05:12 +0200 (CEST) (envelope-from w) Date: Sun, 10 Apr 2005 19:05:11 +0200 From: Wiktor Niesiobedzki To: Stefan Ehmann Message-ID: <20050410170511.GA13812@dln55.neoplus.adsl.tpnet.pl> References: <20050410111202.GA5980@dln55.neoplus.adsl.tpnet.pl> <1113136123.1530.3.camel@taxman.pepperland> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1113136123.1530.3.camel@taxman.pepperland> User-Agent: Mutt/1.4.2.1i cc: current@freebsd.org cc: sos@freebsd.org Subject: Re: ATA MkIII - Hang after resume solution X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Apr 2005 17:05:14 -0000 On Sun, Apr 10, 2005 at 02:28:43PM +0200, Stefan Ehmann wrote: > > This causes a kernel panic in ata_reinit for me. (no detailed info > available since the computer freezes hard at that point) > I've some questions: 1. Did suspend/resume work before Mk III? 2. Did suspend/resume work after Mk III? 3. Can you provide any information about hardware you're running? Cheers, Wiktor Niesiobedzki From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 17:10:39 2005 Return-Path: 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 66E8616A4CE; Sun, 10 Apr 2005 17:10:39 +0000 (GMT) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2513243D1F; Sun, 10 Apr 2005 17:10:39 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 8D52C5DA0; Sun, 10 Apr 2005 13:10:38 -0400 (EDT) Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85577-01; Sun, 10 Apr 2005 13:10:36 -0400 (EDT) Received: from [192.168.1.3] (pool-68-161-53-96.ny325.east.verizon.net [68.161.53.96]) by pi.codefab.com (Postfix) with ESMTP id 378895C85; Sun, 10 Apr 2005 13:10:36 -0400 (EDT) Message-ID: <42595E04.60705@mac.com> Date: Sun, 10 Apr 2005 13:10:28 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050319 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Ellard References: <200504100251.j3A2pLEH055107@sana.init-main.com> <20050410074009.N66651@bowser.eecs.harvard.edu> <1892195662.20050410140423@andric.com> <20050410082945.H66651@bowser.eecs.harvard.edu> In-Reply-To: <20050410082945.H66651@bowser.eecs.harvard.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at codefab.com cc: freebsd-fs@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: smbfs bug introduced at smbfs_vnops.c:1.58 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Apr 2005 17:10:39 -0000 Daniel Ellard wrote: > On Sun, 10 Apr 2005, Dimitry Andric wrote: [ ... ] > At least the gcc folk now do detect this old chestnut: > > { > int a; > > a /= 0; > } > > which was used to provoke arguments in compiler > classes for many years. (Optimized, nothing happens. > Unoptimized, a division-by-zero error happens...) Great example. If the optimized code fails to generate a division-by-zero error here, the optimizer is buggy. (I won't quote Aho, Sethi, and Ullman again.... :-) -- -Chuck From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 17:49:42 2005 Return-Path: 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 4A1CB16A4CF; Sun, 10 Apr 2005 17:49:42 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id B629D43D49; Sun, 10 Apr 2005 17:49:41 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.3/8.13.1) with ESMTP id j3AHncbR004938; Sun, 10 Apr 2005 13:49:38 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.3/8.13.1/Submit) id j3AHncA2004937; Sun, 10 Apr 2005 13:49:38 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Sun, 10 Apr 2005 13:49:38 -0400 From: David Schultz To: Chuck Swiger Message-ID: <20050410174938.GA4842@VARK.MIT.EDU> Mail-Followup-To: Chuck Swiger , Daniel Ellard , freebsd-fs@FreeBSD.ORG, freebsd-current@FreeBSD.ORG References: <200504100251.j3A2pLEH055107@sana.init-main.com> <20050410074009.N66651@bowser.eecs.harvard.edu> <1892195662.20050410140423@andric.com> <20050410082945.H66651@bowser.eecs.harvard.edu> <42595E04.60705@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42595E04.60705@mac.com> cc: freebsd-fs@FreeBSD.ORG cc: Daniel Ellard cc: freebsd-current@FreeBSD.ORG Subject: Re: smbfs bug introduced at smbfs_vnops.c:1.58 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Apr 2005 17:49:42 -0000 On Sun, Apr 10, 2005, Chuck Swiger wrote: > Daniel Ellard wrote: > >On Sun, 10 Apr 2005, Dimitry Andric wrote: > [ ... ] > >At least the gcc folk now do detect this old chestnut: > > > > { > > int a; > > > > a /= 0; > > } > > > >which was used to provoke arguments in compiler > >classes for many years. (Optimized, nothing happens. > >Unoptimized, a division-by-zero error happens...) > > Great example. > > If the optimized code fails to generate a division-by-zero error here, the > optimizer is buggy. (I won't quote Aho, Sethi, and Ullman again.... :-) gcc's optimizer is notoriously bad with side-effects like this, particularly for floating-point code. The C99 standard requires that the compiler support the FENV_ACCESS pragma to tell the compiler that (among other things) it must not optimize away arithmetic that may generate an exception as a side-effect, but gcc doesn't implement it. Worse yet, gcc defaults to assuming that it *is* allowed to optimize such arithmetic operations away, even in expressions such as '1.0 / 0.0' where it's clear what the programmer wanted to happen. A number of routines in libm don't work properly at -O2 as a result of this, and in several places we play tricks such as declaring variables to be volatile or 'long double' just to trick the optimizer. IIRC, Steve Moshier wrote some gcc patches to fix this, but nobody ever committed them... From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 18:04:55 2005 Return-Path: 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 698DB16A4CE for ; Sun, 10 Apr 2005 18:04:55 +0000 (GMT) Received: from av9-1-sn4.m-sp.skanova.net (av9-1-sn4.m-sp.skanova.net [81.228.10.108]) by mx1.FreeBSD.org (Postfix) with ESMTP id F269543D39 for ; Sun, 10 Apr 2005 18:04:53 +0000 (GMT) (envelope-from ertr1013@student.uu.se) Received: by av9-1-sn4.m-sp.skanova.net (Postfix, from userid 502) id CE16537E4C; Sun, 10 Apr 2005 20:04:52 +0200 (CEST) Received: from smtp4-2-sn4.m-sp.skanova.net (smtp4-2-sn4.m-sp.skanova.net [81.228.10.180]) by av9-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id C03E737E42 for ; Sun, 10 Apr 2005 20:04:52 +0200 (CEST) Received: from falcon.midgard.homeip.net (h201n1fls24o1048.bredband.comhem.se [212.181.162.201]) by smtp4-2-sn4.m-sp.skanova.net (Postfix) with SMTP id 521B737E43 for ; Sun, 10 Apr 2005 20:04:51 +0200 (CEST) Received: (qmail 1026 invoked by uid 1001); 10 Apr 2005 18:04:50 -0000 Date: Sun, 10 Apr 2005 20:04:50 +0200 From: Erik Trulsson To: Chuck Swiger Message-ID: <20050410180450.GA963@falcon.midgard.homeip.net> Mail-Followup-To: Chuck Swiger , Daniel Ellard , freebsd-fs@freebsd.org, freebsd-current@freebsd.org References: <200504100251.j3A2pLEH055107@sana.init-main.com> <20050410074009.N66651@bowser.eecs.harvard.edu> <1892195662.20050410140423@andric.com> <20050410082945.H66651@bowser.eecs.harvard.edu> <42595E04.60705@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42595E04.60705@mac.com> User-Agent: Mutt/1.5.9i cc: freebsd-fs@freebsd.org cc: Daniel Ellard cc: freebsd-current@freebsd.org Subject: Re: smbfs bug introduced at smbfs_vnops.c:1.58 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Apr 2005 18:04:55 -0000 On Sun, Apr 10, 2005 at 01:10:28PM -0400, Chuck Swiger wrote: > Daniel Ellard wrote: > >On Sun, 10 Apr 2005, Dimitry Andric wrote: > [ ... ] > >At least the gcc folk now do detect this old chestnut: > > > > { > > int a; > > > > a /= 0; > > } > > > >which was used to provoke arguments in compiler > >classes for many years. (Optimized, nothing happens. > >Unoptimized, a division-by-zero error happens...) > > Great example. > > If the optimized code fails to generate a division-by-zero error here, the > optimizer is buggy. Not at all. Division by zero means undefined behaviour (at least in C.) Undefined behaviour means *anything* may happen - including no error happening. A compiler optimizing away the division-by-zero is perfectly correct in doing so. (It is also perfectly correct to not optimize away the error.) > (I won't quote Aho, Sethi, and Ullman again.... :-) No, please don't - especially since that quote you are so fond of isn't *quite* correct - an optimizer is allowed to change the output of a program as long as the new output is also correct according to the language specification. (Language specifications often do not specify every detail, with the result that for a given program it can be the case that more than one output can be correct. In C any instance of undefined behaviour in a program means that *no* aspect of the program is defined and therefore all different outputs will be equally correct.) -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 18:27:38 2005 Return-Path: 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 913CA16A4CE for ; Sun, 10 Apr 2005 18:27:38 +0000 (GMT) Received: from rdsmtp.iglou.com (rdsmtp.iglou.com [192.107.41.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5427043D1D for ; Sun, 10 Apr 2005 18:27:38 +0000 (GMT) (envelope-from dlevitch@iglou.com) Received: from [192.107.41.8] (helo=iglou2.iglou.com) by rdsmtp.iglou.com with esmtp (8.12.5/8.12.5) id 1DKh9l-0005pg-JW for current@freebsd.org; Sun, 10 Apr 2005 14:27:37 -0400 Received: from [192.107.41.17] (helo=shell1) by iglou2.iglou.com with esmtp (8.12.5/8.12.5) id 1DKh9l-0004SS-7m for current@freebsd.org; Sun, 10 Apr 2005 14:27:37 -0400 Date: Sun, 10 Apr 2005 14:27:37 -0400 (EDT) From: Darrel X-X-Sender: dlevitch@shell1 To: current@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Originating-IP: 192.107.41.17 X-IgLou-Customer: verified Subject: gnome upgrade on GENERIC i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Apr 2005 18:27:38 -0000 Can I delete all of the files in /var/tmp? I am not sure if any of them are necessary: epiphany f-prot gconfd installkernel orbit packlists- several temproot vi.recover Darrel From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 18:43:31 2005 Return-Path: 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 B031416A4CE; Sun, 10 Apr 2005 18:43:31 +0000 (GMT) Received: from gate.bitblocks.com (bitblocks.com [209.204.185.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69CF243D1D; Sun, 10 Apr 2005 18:43:31 +0000 (GMT) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost [127.0.0.1]) by gate.bitblocks.com (8.13.3/8.13.1) with ESMTP id j3AIhUh0046427; Sun, 10 Apr 2005 11:43:31 -0700 (PDT) (envelope-from bakul@bitblocks.com) Message-Id: <200504101843.j3AIhUh0046427@gate.bitblocks.com> To: Bruce Evans In-reply-to: Your message of "Mon, 11 Apr 2005 03:55:31 +1000." <20050411032601.S55302@delplex.bde.org> Date: Sun, 10 Apr 2005 11:43:30 -0700 From: Bakul Shah cc: freebsd-fs@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: smbfs bug introduced at smbfs_vnops.c:1.58 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Apr 2005 18:43:31 -0000 > A similar example with "double a;" is more interesting. This also > gives undefined behaviour (C99 6.5.5[#5]). However, this is bogus if > there is a floating point infinity. C99 has support for IEEE floating > point and it is clearly intended that the behaviour of 1.0/0.0 is to > give +Inf and raise the divide-by-zero exception, but I couldn't see > anywhere in the C99 draft n869.txt where this is spelled out (raising of > the divide-by-zero exception is spelled out for lots of math functions > but doesn't seem to be mentioned for plain division). This is indirectly spelled out in draft n2764.txt in annex F: F.3 Operators and functions [#1] C operators and functions provide IEC 60559 required and recommended facilities as listed below. -- The +, -, *, and / operators provide the IEC 60559 add, subtract, multiply, and divide operations. IEC 60599 (aka IEEE754) clearly states the behavior for divide by zero. 6.5.5 does say x/0 is undefined but if __STDC_IEC_559__ is defined then IEEE behavior is expected. I haven't checked gassy-c (gcc) for conformance. From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 18:49:01 2005 Return-Path: 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 8DBF716A4CE for ; Sun, 10 Apr 2005 18:49:01 +0000 (GMT) Received: from email.aon.at (warsl404pip7.highway.telekom.at [195.3.96.91]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69A4E43D2F for ; Sun, 10 Apr 2005 18:49:00 +0000 (GMT) (envelope-from shoesoft@gmx.net) Received: (qmail 23431 invoked from network); 10 Apr 2005 18:48:58 -0000 Received: from m106p003.dipool.highway.telekom.at ([62.46.3.35]) (envelope-sender ) by smarthub73.highway.telekom.at (qmail-ldap-1.03) with SMTP for ; 10 Apr 2005 18:48:58 -0000 From: Stefan Ehmann To: Wiktor Niesiobedzki In-Reply-To: <20050410170511.GA13812@dln55.neoplus.adsl.tpnet.pl> References: <20050410111202.GA5980@dln55.neoplus.adsl.tpnet.pl> <1113136123.1530.3.camel@taxman.pepperland> <20050410170511.GA13812@dln55.neoplus.adsl.tpnet.pl> Content-Type: text/plain Date: Sun, 10 Apr 2005 20:49:01 +0200 Message-Id: <1113158941.1530.31.camel@taxman.pepperland> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit cc: current@freebsd.org cc: sos@freebsd.org Subject: Re: ATA MkIII - Hang after resume solution X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Apr 2005 18:49:01 -0000 On Sun, 2005-04-10 at 19:05 +0200, Wiktor Niesiobedzki wrote: > On Sun, Apr 10, 2005 at 02:28:43PM +0200, Stefan Ehmann wrote: > > > > This causes a kernel panic in ata_reinit for me. (no detailed info > > available since the computer freezes hard at that point) > > > I've some questions: > 1. Did suspend/resume work before Mk III? Yes (with apic disabled only though). > 2. Did suspend/resume work after Mk III? No, get ad0: TIMEOUT - READ_DMA retrying (2 retries left) LBA=7499 and then it hangs. > 3. Can you provide any information about hardware you're running? It's a Toshiba M30-X notebook, dmesg can be found here: http://stud4.tuwien.ac.at/~e0125637/fbsd/dmesg http://stud4.tuwien.ac.at/~e0125637/fbsd/dmesg.verbose When booting in verbose mode I see this on resume: Some lines of: ata0: stat0=0x80 err=0x80 lsb=0x80 msb=0x80 And finally before the panic: ata0: reset tp2 stat0=80 stat1=80 devices=0x0 Thanks, Stefan Ehmann From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 19:06:58 2005 Return-Path: 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 A93CB16A4CE; Sun, 10 Apr 2005 19:06:58 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id F300643D41; Sun, 10 Apr 2005 19:06:57 +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 j3AJ6vKq065505; Sun, 10 Apr 2005 15:06:57 -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 j3AJ6vCw015169; Sun, 10 Apr 2005 15:06:57 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 366107306E; Sun, 10 Apr 2005 15:06:57 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050410190657.366107306E@freebsd-current.sentex.ca> Date: Sun, 10 Apr 2005 15:06:57 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on clamscanner1 X-Virus-Status: Clean Subject: [current tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2005 19:06:58 -0000 TB --- 2005-04-10 17:48:12 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-10 17:48:12 - starting CURRENT tinderbox run for powerpc/powerpc TB --- 2005-04-10 17:48:12 - checking out the source tree TB --- 2005-04-10 17:48:12 - cd /home/tinderbox/CURRENT/powerpc/powerpc TB --- 2005-04-10 17:48:12 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-10 17:54:55 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-10 17:54:55 - cd /home/tinderbox/CURRENT/powerpc/powerpc/src TB --- 2005-04-10 17:54:55 - /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-04-10 19:03:13 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-10 19:03:13 - cd /home/tinderbox/CURRENT/powerpc/powerpc/src TB --- 2005-04-10 19:03:13 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Apr 10 19:03:13 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 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/powerpc/powerpc/src/sys -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/altq -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/pf -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Wno-error /tinderbox/CURRENT/powerpc/powerpc/src/sys/powerpc/powermac/uninorth.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 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/powerpc/powerpc/src/sys -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/altq -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/pf -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Wno-error /tinderbox/CURRENT/powerpc/powerpc/src/sys/powerpc/psim/iobus.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 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/powerpc/powerpc/src/sys -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/altq -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/pf -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Wno-error /tinderbox/CURRENT/powerpc/powerpc/src/sys/powerpc/psim/ata_iobus.c /tinderbox/CURRENT/powerpc/powerpc/src/sys/powerpc/psim/ata_iobus.c: In function `ata_iobus_alloc_resource': /tinderbox/CURRENT/powerpc/powerpc/src/sys/powerpc/psim/ata_iobus.c:171: error: `ATA_ALTADDR_RID' undeclared (first use in this function) /tinderbox/CURRENT/powerpc/powerpc/src/sys/powerpc/psim/ata_iobus.c:171: error: (Each undeclared identifier is reported only once /tinderbox/CURRENT/powerpc/powerpc/src/sys/powerpc/psim/ata_iobus.c:171: error: for each function it appears in.) /tinderbox/CURRENT/powerpc/powerpc/src/sys/powerpc/psim/ata_iobus.c:174: error: `ATA_ALTIOSIZE' undeclared (first use in this function) *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/obj/powerpc/tinderbox/CURRENT/powerpc/powerpc/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. TB --- 2005-04-10 19:06:57 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-10 19:06:57 - ERROR: failed to build generic kernel TB --- 2005-04-10 19:06:57 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 19:13:24 2005 Return-Path: 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 B2B3E16A4CE for ; Sun, 10 Apr 2005 19:13:24 +0000 (GMT) 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 F26B143D2F for ; Sun, 10 Apr 2005 19:13:23 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.13.3/8.13.3) with ESMTP id j3AJDJmb019844; Sun, 10 Apr 2005 21:13:19 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <42597A6D.8080801@DeepCore.dk> Date: Sun, 10 Apr 2005 21:11:41 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Reifenberger References: <20050410164959.G38200@fw.reifenberger.com> In-Reply-To: <20050410164959.G38200@fw.reifenberger.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-mail-scanned: by DeepCore Virus & Spam killer v1.12 cc: FreeBSD-Current Subject: Re: SATA with new ata code doesn't work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Apr 2005 19:13:24 -0000 Michael Reifenberger wrote: > Hi, > after upgrading to the latest -current, my ASUS A8V deluxe > board doesn't boot because its missing the ad0/ad1 devices. > These are WD SATA disks hanging on: >=20 > atapci0: port=20 > 0xd000-0xd007,0xc800-0xc803,0xc400-0xc407,0xc000-0xc=20 > 003,0xb800-0xb80f,0xb400-0xb4ff irq 20 at device 15.0 on pci0 > ata2: channel #0 on atapci0 > ata3: channel #1 on atapci0 >=20 > and get usually probed as: >=20 > acd0: DVDR at ata1-master UDMA33 > ad0: 70911MB [144073/16/63] at ata2-maste= r=20 > SATA150 > ad1: 70911MB [144073/16/63] at ata3-maste= r=20 > SATA150 >=20 > Is this a known problem? Yes, the problem is that the alloc_resource fails on the last resource=20 (0xb4000-0xb4ff) for some unknown reason. I've given up finding this remotely and have ordered a VIA based=20 motherboard that I'm picking up tomorrow, then I'm sure I can have fix=20 ready soon... --=20 -S=F8ren From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 19:25:33 2005 Return-Path: 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 49A6316A4CE for ; Sun, 10 Apr 2005 19:25:33 +0000 (GMT) Received: from mailout11.sul.t-online.com (mailout11.sul.t-online.com [194.25.134.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 994FB43D1D for ; Sun, 10 Apr 2005 19:25:32 +0000 (GMT) (envelope-from mike@reifenberger.com) Received: from fwd35.aul.t-online.de by mailout11.sul.t-online.com with smtp id 1DKi3n-000800-01; Sun, 10 Apr 2005 21:25:31 +0200 Received: from fw.reifenberger.com (bKdvwmZS8ePEMHoYC99uZpAV+XnJvT+jRPppDP6RAak9ekK6yjm+Y1@[62.158.171.84]) by fwd35.sul.t-online.de with esmtp id 1DKi3i-0hSYF60; Sun, 10 Apr 2005 21:25:26 +0200 Received: from localhost (mike@localhost)j3AJPHOT025069; Sun, 10 Apr 2005 21:25:17 +0200 (CEST) (envelope-from mike@reifenberger.com) X-Authentication-Warning: fw.reifenberger.com: mike owned process doing -bs Date: Sun, 10 Apr 2005 21:25:17 +0200 (CEST) From: Michael Reifenberger To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= In-Reply-To: <42597A6D.8080801@DeepCore.dk> Message-ID: <20050410212444.H25065@fw.reifenberger.com> References: <20050410164959.G38200@fw.reifenberger.com> <42597A6D.8080801@DeepCore.dk> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-608160226-1113161117=:25065" X-ID: bKdvwmZS8ePEMHoYC99uZpAV+XnJvT+jRPppDP6RAak9ekK6yjm+Y1@t-dialin.net X-TOI-MSGID: 813b1242-6129-461e-9faf-abdadf95c38d cc: FreeBSD-Current Subject: Re: SATA with new ata code doesn't work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Apr 2005 19:25:33 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-608160226-1113161117=:25065 Content-Type: TEXT/PLAIN; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT On Sun, 10 Apr 2005, [ISO-8859-1] Søren Schmidt wrote: ... >> Is this a known problem? > > Yes, the problem is that the alloc_resource fails on the last resource > (0xb4000-0xb4ff) for some unknown reason. > I've given up finding this remotely and have ordered a VIA based motherboard > that I'm picking up tomorrow, then I'm sure I can have fix ready soon... > Ok. Thanks! Bye/2 --- Michael Reifenberger, Business Development Manager SAP-Basis, Plaut Consulting Comp: Michael.Reifenberger@plaut.de | Priv: Michael@Reifenberger.com http://www.plaut.de | http://www.Reifenberger.com --0-608160226-1113161117=:25065-- From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 19:27:49 2005 Return-Path: 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 F068316A4CE for ; Sun, 10 Apr 2005 19:27:48 +0000 (GMT) Received: from mail22.sea5.speakeasy.net (mail22.sea5.speakeasy.net [69.17.117.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 97DD543D53 for ; Sun, 10 Apr 2005 19:27:48 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 24488 invoked from network); 10 Apr 2005 19:27:48 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 10 Apr 2005 19:27:47 -0000 Received: from slimer.baldwin.cx (slimer.baldwin.cx [192.168.0.16]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j3AJRggs006229; Sun, 10 Apr 2005 15:27:42 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Doug White Date: Sun, 10 Apr 2005 15:23:56 -0400 User-Agent: KMail/1.8 References: <20050406233405.O47071@carver.gumbysoft.com> <200504081656.51917.jhb@FreeBSD.org> <20050409231647.Y74901@carver.gumbysoft.com> In-Reply-To: <20050409231647.Y74901@carver.gumbysoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504101523.56787.jhb@FreeBSD.org> X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: freebsd-current@FreeBSD.org Subject: Re: Potential source of interrupt aliasing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Apr 2005 19:27:49 -0000 On Sunday 10 April 2005 02:22 am, Doug White wrote: > On Fri, 8 Apr 2005, John Baldwin wrote: > > > A quick hack would be to blacklist intpin 16 on the first IOAPIC and > > > bump any PCI devices that ACPI says are claiming that interrupt. I > > > don't know how difficult this is to do with ACPI. How to handle this > > > for ATPIC mode is a little difficult since the boot interrupt either > > > gets routed to IRQ9 or ends up as a stray on IRQ7 (on my SCB2 at least > > > -- other boards may vary). > > > > You can't just move APIC interrupts around. They are physically wired > > that way. ATPIC mode won't matter. If there is a way to disable this in > > hardware, then it needs to be done in the _PIC method of the BIOS for > > ACPI. I don't think there's any way to allow for this for non-ACPI though > > as the MPTable spec only mentions the IMCR which these boards don't > > implement. > > I didn't think so, at least in the general case. It may be possible to > reprogram ICH registers to have usb use other INT lines if they're coming > up through SERIRQ and aren't physically wired to the pin, but I haven't > dug through the docs for that. > > For fun, I put together this one-liner to at least test the theory: > > http://people.freebsd.org/~dwhite/intr_machdep.c.20050409.patch Doing this should result in an instant interrupt storm since your PCI interrupts (which are level triggered) should now keep firing over and over and the machine will spend all it's time rescheduling the ithread. If it's not doing that then this is very curious. > This makes the aliased interrupts go away at the cost of hitting > sched_lock for each ithread interrupt. I'm trying to dream up a way of > telling if the ithread is active or scheduled so we don't need to bump it > again with setrunqueue(). I think I can use the it_need sparkplug to at > least save mutex grabs on interrupts that fire much faster than their > ithread handlers cycle. > > I'd like better granularity, though, but I'm not sure that setting a flag > that is cleared just before mi_switch() in ithread_loop() and set just > after won't race against an interrupt checking it to see if it needs to > setrunqueue() the ithread. Maybe clear the flag before trying to grab > sched_lock? it_need already does this. You haven't added any extra sched_locks. What've you done is change the interrupt code to never mask interrupt sources. If you aren't getting an interrupt storm on your first PCI interrupt then that is very curious indeed. Have you tried this with SMP disabled so that you only have one CPU running? It may be that due to SMP your ithread still gets a chance to run on one CPU while the other CPU is stormed with interrupt requests. Note that since storm detection is done in the ithread, this type of storm won't be detected and throttled. It also might not show up in the vmstats since we don't use atomic ops there anymore depending on whether or not the interrupt bounces between CPUs that keep overwriting the count on top of each other. > I'm also not sure how much this change affects system performance. I guess > I should hit up rwatson for some info on MUTEX_PROFILING. :) First see how the system acts with only one CPU. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 19:50:30 2005 Return-Path: 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 DBEDC16A4CE for ; Sun, 10 Apr 2005 19:50:30 +0000 (GMT) Received: from tibor.swiftdsl.com.au (tibor.swiftdsl.com.au [202.154.92.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9322A43D1F for ; Sun, 10 Apr 2005 19:50:29 +0000 (GMT) (envelope-from mv@roq.com) Received: (qmail 9370 invoked from network); 10 Apr 2005 19:57:58 -0000 Received: from unknown (HELO [10.0.0.55]) ([218.214.143.85]) (envelope-sender ) by tibor.swiftdsl.com.au (qmail-ldap-1.03) with SMTP for ; 10 Apr 2005 19:57:58 -0000 Message-ID: <42598382.5020509@roq.com> Date: Mon, 11 Apr 2005 05:50:26 +1000 From: Michael Vince User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?UTF-8?B?U8WCYXdlayDFu2Fr?= References: <787bbe1c0504070307670f5e5d@mail.gmail.com> <4255182E.1020002@centtech.com> <4142.212.12.51.89.1112874483.squirrel@212.12.51.89> <42551E94.30800@centtech.com> <787bbe1c05040705254c89fea@mail.gmail.com> In-Reply-To: <787bbe1c05040705254c89fea@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit cc: freebsd-current@freebsd.org cc: Eric Anderson cc: Marian Hettwer Subject: Re: Serial console install X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Apr 2005 19:50:31 -0000 Also I would like to make aware to the discussion IPMI which I believe in Version 2 has console support, This stuff seems to be the future of serial console, I have found it frustrating that Dell sell most of their servers with only 1 serial port, I believe there excuse is IPMI. http://people.freebsd.org/~dwhite/ipmi/ http://www.intel.com/design/servers/ipmi/ http://www.freebsdsystems.com/ipmi-tech.php Cheers, Michael SÅ‚awek Å»ak wrote: >On Apr 7, 2005 1:50 PM, Eric Anderson wrote: > > > >>You must have missed the second link - it answers your questions >> >> >completely. You can >also build your own images with whatever setup >you'd like, and/or have that image used via >PXE install. > >So the options I have are: > >1. Boot from CDROM with keyboard plugged in, wait for the beep and >press 6 blindfolded then enter boot -h. >2. Boot from floppy and flip the diskettes until the output is >directed to the serial console. >3. Build my own PXE image. > >Doh. Lots of work. I was asking for a small and very helpful change in >the boot loader. Floppies are so 1980's. Getting my butt to the server >room and plugging the keyboard in is a little better, but still far >from the convenience of putting the CD in and forgetting the problem. > >/S >_______________________________________________ >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 Sun Apr 10 20:09:10 2005 Return-Path: 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 EE49716A4CE for ; Sun, 10 Apr 2005 20:09:10 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2374143D2F for ; Sun, 10 Apr 2005 20:09:10 +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 j3AKB4qJ099616; Sun, 10 Apr 2005 23:11:04 +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 54266-03; Sun, 10 Apr 2005 23:11:33 +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 j3AKB3FT099613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 Apr 2005 23:11:04 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.3/8.13.3) id j3AK98i0043900; Sun, 10 Apr 2005 23:09:08 +0300 (EEST) (envelope-from ru) Date: Sun, 10 Apr 2005 23:09:08 +0300 From: Ruslan Ermilov To: Rob Message-ID: <20050410200908.GC30103@ip.net.ua> References: <20050410015420.57348.qmail@web54003.mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KDt/GgjP6HVcx58l" Content-Disposition: inline In-Reply-To: <20050410015420.57348.qmail@web54003.mail.yahoo.com> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: FreeBSD current Subject: Re: xl(4) & polling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Apr 2005 20:09:11 -0000 --KDt/GgjP6HVcx58l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 09, 2005 at 06:54:20PM -0700, Rob wrote: > Ruslan Ermilov wrote: > > On Mar 24, 2005 Christopher Nehren wrote: > >=20 > >>On 2005-03-24, Ruslan Ermilov scribbled these > >>curious markings: > >> > >>> Those of you wishing to try your xl(4) card under > >>> polling(4) are welcome to test this patch: > >> > >> Can I apply this to my RELENG_5 box without making > >> the machine melt? If so, I'll start testing > >> immediately with my handy-dandy just-found spare > >> xl (3C905-TX). >=20 > I have a dual-homed router+NAT, which has two > 3C905B-TX lan cards. I never have considered polling, > because it was not supported for these cards; hence I > have little knowledge about it. >=20 > I am considering this patch on my 5.3-STABLE router. > Is there a proper test I can do to verify that the > polling is indeed working as expected? >=20 Yes. The usual polling(4) test, i.e., you should get more interactivity under a high network load and polling switched on, while network performance should stay if not better than with polling off, but at least the same. > PS: if this makes it into the official sources, then > don't forget to also add xl(4) to the polling(4) > manpage. >=20 It did (last month). The manpage was also updated. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --KDt/GgjP6HVcx58l Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCWYfkqRfpzJluFF4RAru4AJ9xwhBToXpyWJ+7aDutSfOT8bAd2QCfeW/v LjinT6qo/w58MncaJ8l6XXw= =LaQ7 -----END PGP SIGNATURE----- --KDt/GgjP6HVcx58l-- From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 20:19:29 2005 Return-Path: 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 E975216A4CE for ; Sun, 10 Apr 2005 20:19:28 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4313A43D46 for ; Sun, 10 Apr 2005 20:19:28 +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 914EB46B0A for ; Sun, 10 Apr 2005 16:19:27 -0400 (EDT) Date: Sun, 10 Apr 2005 21:19:24 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Message-ID: <20050410205827.W6160@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Patch to protect per-cpu UMA caches with critical sections X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Apr 2005 20:19:29 -0000 The attached patch modifies UMA so that it uses critical sections to protect access to per-CPU caches, rather than mutexes. With the recent commit of critical section optimizations by John Baldwin, this patch should offer a small but measurable performance improvement for paths that allocate and free memory as a significant part of their workload. Examples of affected scenarios might include high performance networking, IPC, etc. John's change was an important dependency, because on uniprocessor systems, atomic operations are basically regular integer operations, and so very cheap. As such, I didn't want to replace mutexes with a more expensive critical section uperation on UP, even if it sped up SMP with critical sections cheaper than mutexes there. The change relies on the fact that critical sections cost less than mutexes -- however, the extent to which this is the case varies based on CPU type. The performance difference for Xeon P4 hardware is quite noticeable, due to the extortionate cost of disabling interrupts and atomic operations on that system. However, on PIII hardware, it should be much less noticeable, due to the (relatively) low cost of those operations. In a UDP packet send test on a dual-Xeon P4 box, sending 0-byte payload packets with netblast, I saw around a 2%-3% performance improvement on SMP, but more around a 1% improvement on UP. While this isn't a big change, these things add up. Before committing the patch, I'd like to see additional performance and stability measurements. Specific notes: - I'd like to make sure we don't see performance regressions on other workloads or hardware architectures. Because the relative costs of the important instructions here vary quite a bit by architecture, as well as based on how the kernel is compiled, there is a risk that some might see regressions. - In an earlier version of this patch, a race was introduced with INVARIANTS where-in INVARIANTS checking of free'd memory occurred after memory was returned to the cache, resulting in false positive panics. This bug has been corrected. However, testing with and without INVARIANTS would be considered helpful. - Note that, because of ordering between mutexes and critical sections, there are now some cases, when running with INVARIANTS, where the zone mutex will be acquired twice instead of once for memory free. As a result, execution with INVARIANTS may show a performance loss. UMA running without INVARIANTS doesn't acquire the zone mutex an additional time. Robert N M Watson --- //depot/vendor/freebsd/src/sys/vm/uma_core.c 2005/02/24 06:30:36 +++ //depot/user/rwatson/percpu/sys/vm/uma_core.c 2005/04/06 10:33:02 @@ -1,4 +1,5 @@ /*- + * Copyright (c) 2004-2005 Robert N. M. Watson * Copyright (c) 2004, 2005, * Bosko Milekic . All rights reserved. * Copyright (c) 2002, 2003, 2004, 2005, @@ -119,9 +120,6 @@ /* This mutex protects the keg list */ static struct mtx uma_mtx; -/* These are the pcpu cache locks */ -static struct mtx uma_pcpu_mtx[MAXCPU]; - /* Linked list of boot time pages */ static LIST_HEAD(,uma_slab) uma_boot_pages = LIST_HEAD_INITIALIZER(&uma_boot_pages); @@ -384,48 +382,19 @@ zone_timeout(uma_zone_t zone) { uma_keg_t keg; - uma_cache_t cache; u_int64_t alloc; - int cpu; keg = zone->uz_keg; alloc = 0; /* - * Aggregate per cpu cache statistics back to the zone. - * - * XXX This should be done in the sysctl handler. - * - * I may rewrite this to set a flag in the per cpu cache instead of - * locking. If the flag is not cleared on the next round I will have - * to lock and do it here instead so that the statistics don't get too - * far out of sync. - */ - if (!(keg->uk_flags & UMA_ZFLAG_INTERNAL)) { - for (cpu = 0; cpu <= mp_maxid; cpu++) { - if (CPU_ABSENT(cpu)) - continue; - CPU_LOCK(cpu); - cache = &zone->uz_cpu[cpu]; - /* Add them up, and reset */ - alloc += cache->uc_allocs; - cache->uc_allocs = 0; - CPU_UNLOCK(cpu); - } - } - - /* Now push these stats back into the zone.. */ - ZONE_LOCK(zone); - zone->uz_allocs += alloc; - - /* * Expand the zone hash table. * * This is done if the number of slabs is larger than the hash size. * What I'm trying to do here is completely reduce collisions. This * may be a little aggressive. Should I allow for two collisions max? */ - + ZONE_LOCK(zone); if (keg->uk_flags & UMA_ZONE_HASH && keg->uk_pages / keg->uk_ppera >= keg->uk_hash.uh_hashsize) { struct uma_hash newhash; @@ -613,6 +582,10 @@ /* * Drains the per cpu caches for a zone. * + * NOTE: This may only be called while the zone is being turn down, and not + * during normal operation. This is necessary in order that we do not have + * to migrate CPUs to drain the per-CPU caches. + * * Arguments: * zone The zone to drain, must be unlocked. * @@ -626,12 +599,20 @@ int cpu; /* - * We have to lock each cpu cache before locking the zone + * XXX: It is safe to not lock the per-CPU caches, because we're + * tearing down the zone anyway. I.e., there will be no further use + * of the caches at this point. + * + * XXX: It would good to be able to assert that the zone is being + * torn down to prevent improper use of cache_drain(). + * + * XXX: We lock the zone before passing into bucket_cache_drain() as + * it is used elsewhere. Should the tear-down path be made special + * there in some form? */ for (cpu = 0; cpu <= mp_maxid; cpu++) { if (CPU_ABSENT(cpu)) continue; - CPU_LOCK(cpu); cache = &zone->uz_cpu[cpu]; bucket_drain(zone, cache->uc_allocbucket); bucket_drain(zone, cache->uc_freebucket); @@ -644,11 +625,6 @@ ZONE_LOCK(zone); bucket_cache_drain(zone); ZONE_UNLOCK(zone); - for (cpu = 0; cpu <= mp_maxid; cpu++) { - if (CPU_ABSENT(cpu)) - continue; - CPU_UNLOCK(cpu); - } } /* @@ -828,7 +804,8 @@ &flags, wait); if (mem == NULL) { if (keg->uk_flags & UMA_ZONE_OFFPAGE) - uma_zfree_internal(keg->uk_slabzone, slab, NULL, 0); + uma_zfree_internal(keg->uk_slabzone, slab, NULL, + SKIP_NONE); ZONE_LOCK(zone); return (NULL); } @@ -1643,10 +1620,6 @@ #ifdef UMA_DEBUG printf("Initializing pcpu cache locks.\n"); #endif - /* Initialize the pcpu cache lock set once and for all */ - for (i = 0; i <= mp_maxid; i++) - CPU_LOCK_INIT(i); - #ifdef UMA_DEBUG printf("Creating slab and hash zones.\n"); #endif @@ -1793,6 +1766,9 @@ uma_cache_t cache; uma_bucket_t bucket; int cpu; +#ifdef INVARIANTS + int count; +#endif int badness; /* This is the fast path allocation */ @@ -1827,12 +1803,33 @@ } } + /* + * If possible, allocate from the per-CPU cache. There are two + * requirements for safe access to the per-CPU cache: (1) the thread + * accessing the cache must not be preempted or yield during access, + * and (2) the thread must not migrate CPUs without switching which + * cache it accesses. We rely on a critical section to prevent + * preemption and migration. We release the critical section in + * order to acquire the zone mutex if we are unable to allocate from + * the current cache; when we re-acquire the critical section, we + * must detect and handle migration if it has occurred. + */ +#ifdef INVARIANTS + count = 0; +#endif zalloc_restart: + critical_enter(); cpu = PCPU_GET(cpuid); - CPU_LOCK(cpu); cache = &zone->uz_cpu[cpu]; zalloc_start: +#ifdef INVARIANTS + count++; + KASSERT(count < 10, ("uma_zalloc_arg: count == 10")); +#endif +#if 0 + critical_assert(); +#endif bucket = cache->uc_allocbucket; if (bucket) { @@ -1845,12 +1842,12 @@ KASSERT(item != NULL, ("uma_zalloc: Bucket pointer mangled.")); cache->uc_allocs++; + critical_exit(); #ifdef INVARIANTS ZONE_LOCK(zone); uma_dbg_alloc(zone, NULL, item); ZONE_UNLOCK(zone); #endif - CPU_UNLOCK(cpu); if (zone->uz_ctor != NULL) { if (zone->uz_ctor(item, zone->uz_keg->uk_size, udata, flags) != 0) { @@ -1880,7 +1877,33 @@ } } } + /* + * Attempt to retrieve the item from the per-CPU cache has failed, so + * we must go back to the zone. This requires the zone lock, so we + * must drop the critical section, then re-acquire it when we go back + * to the cache. Since the critical section is released, we may be + * preempted or migrate. As such, make sure not to maintain any + * thread-local state specific to the cache from prior to releasing + * the critical section. + */ + critical_exit(); ZONE_LOCK(zone); + critical_enter(); + cpu = PCPU_GET(cpuid); + cache = &zone->uz_cpu[cpu]; + bucket = cache->uc_allocbucket; + if (bucket != NULL) { + if (bucket != NULL && bucket->ub_cnt > 0) { + ZONE_UNLOCK(zone); + goto zalloc_start; + } + bucket = cache->uc_freebucket; + if (bucket != NULL && bucket->ub_cnt > 0) { + ZONE_UNLOCK(zone); + goto zalloc_start; + } + } + /* Since we have locked the zone we may as well send back our stats */ zone->uz_allocs += cache->uc_allocs; cache->uc_allocs = 0; @@ -1904,8 +1927,8 @@ ZONE_UNLOCK(zone); goto zalloc_start; } - /* We are no longer associated with this cpu!!! */ - CPU_UNLOCK(cpu); + /* We are no longer associated with this CPU. */ + critical_exit(); /* Bump up our uz_count so we get here less */ if (zone->uz_count < BUCKET_MAX) @@ -2228,10 +2251,10 @@ uma_bucket_t bucket; int bflags; int cpu; - enum zfreeskip skip; +#ifdef INVARIANTS + int count; +#endif - /* This is the fast path free */ - skip = SKIP_NONE; keg = zone->uz_keg; #ifdef UMA_DEBUG_ALLOC_1 @@ -2240,25 +2263,50 @@ CTR2(KTR_UMA, "uma_zfree_arg thread %x zone %s", curthread, zone->uz_name); + if (zone->uz_dtor) + zone->uz_dtor(item, keg->uk_size, udata); +#ifdef INVARIANTS + ZONE_LOCK(zone); + if (keg->uk_flags & UMA_ZONE_MALLOC) + uma_dbg_free(zone, udata, item); + else + uma_dbg_free(zone, NULL, item); + ZONE_UNLOCK(zone); +#endif /* * The race here is acceptable. If we miss it we'll just have to wait * a little longer for the limits to be reset. */ - if (keg->uk_flags & UMA_ZFLAG_FULL) goto zfree_internal; - if (zone->uz_dtor) { - zone->uz_dtor(item, keg->uk_size, udata); - skip = SKIP_DTOR; - } - +#ifdef INVARIANTS + count = 0; +#endif + /* + * If possible, free to the per-CPU cache. There are two + * requirements for safe access to the per-CPU cache: (1) the thread + * accessing the cache must not be preempted or yield during access, + * and (2) the thread must not migrate CPUs without switching which + * cache it accesses. We rely on a critical section to prevent + * preemption and migration. We release the critical section in + * order to acquire the zone mutex if we are unable to free to the + * current cache; when we re-acquire the critical section, we must + * detect and handle migration if it has occurred. + */ zfree_restart: + critical_enter(); cpu = PCPU_GET(cpuid); - CPU_LOCK(cpu); cache = &zone->uz_cpu[cpu]; zfree_start: +#ifdef INVARIANTS + count++; + KASSERT(count < 10, ("uma_zfree_arg: count == 10")); +#endif +#if 0 + critical_assert(); +#endif bucket = cache->uc_freebucket; if (bucket) { @@ -2272,15 +2320,7 @@ ("uma_zfree: Freeing to non free bucket index.")); bucket->ub_bucket[bucket->ub_cnt] = item; bucket->ub_cnt++; -#ifdef INVARIANTS - ZONE_LOCK(zone); - if (keg->uk_flags & UMA_ZONE_MALLOC) - uma_dbg_free(zone, udata, item); - else - uma_dbg_free(zone, NULL, item); - ZONE_UNLOCK(zone); -#endif - CPU_UNLOCK(cpu); + critical_exit(); return; } else if (cache->uc_allocbucket) { #ifdef UMA_DEBUG_ALLOC @@ -2304,9 +2344,32 @@ * * 1) The buckets are NULL * 2) The alloc and free buckets are both somewhat full. + * + * We must go back the zone, which requires acquiring the zone lock, + * which in turn means we must release and re-acquire the critical + * section. Since the critical section is released, we may be + * preempted or migrate. As such, make sure not to maintain any + * thread-local state specific to the cache from prior to releasing + * the critical section. */ - + critical_exit(); ZONE_LOCK(zone); + critical_enter(); + cpu = PCPU_GET(cpuid); + cache = &zone->uz_cpu[cpu]; + if (cache->uc_freebucket != NULL) { + if (cache->uc_freebucket->ub_cnt < + cache->uc_freebucket->ub_entries) { + ZONE_UNLOCK(zone); + goto zfree_start; + } + if (cache->uc_allocbucket != NULL && + (cache->uc_allocbucket->ub_cnt < + cache->uc_freebucket->ub_cnt)) { + ZONE_UNLOCK(zone); + goto zfree_start; + } + } bucket = cache->uc_freebucket; cache->uc_freebucket = NULL; @@ -2328,8 +2391,8 @@ cache->uc_freebucket = bucket; goto zfree_start; } - /* We're done with this CPU now */ - CPU_UNLOCK(cpu); + /* We are no longer associated with this CPU. */ + critical_exit(); /* And the zone.. */ ZONE_UNLOCK(zone); @@ -2353,27 +2416,9 @@ /* * If nothing else caught this, we'll just do an internal free. */ - zfree_internal: + uma_zfree_internal(zone, item, udata, SKIP_DTOR); -#ifdef INVARIANTS - /* - * If we need to skip the dtor and the uma_dbg_free in - * uma_zfree_internal because we've already called the dtor - * above, but we ended up here, then we need to make sure - * that we take care of the uma_dbg_free immediately. - */ - if (skip) { - ZONE_LOCK(zone); - if (keg->uk_flags & UMA_ZONE_MALLOC) - uma_dbg_free(zone, udata, item); - else - uma_dbg_free(zone, NULL, item); - ZONE_UNLOCK(zone); - } -#endif - uma_zfree_internal(zone, item, udata, skip); - return; } @@ -2655,7 +2700,7 @@ slab->us_flags = flags | UMA_SLAB_MALLOC; slab->us_size = size; } else { - uma_zfree_internal(slabzone, slab, NULL, 0); + uma_zfree_internal(slabzone, slab, NULL, SKIP_NONE); } return (mem); @@ -2666,7 +2711,7 @@ { vsetobj((vm_offset_t)slab->us_data, kmem_object); page_free(slab->us_data, slab->us_size, slab->us_flags); - uma_zfree_internal(slabzone, slab, NULL, 0); + uma_zfree_internal(slabzone, slab, NULL, SKIP_NONE); } void @@ -2743,6 +2788,7 @@ int cachefree; uma_bucket_t bucket; uma_cache_t cache; + u_int64_t alloc; cnt = 0; mtx_lock(&uma_mtx); @@ -2766,15 +2812,9 @@ LIST_FOREACH(z, &zk->uk_zones, uz_link) { if (cnt == 0) /* list may have changed size */ break; - if (!(zk->uk_flags & UMA_ZFLAG_INTERNAL)) { - for (cpu = 0; cpu <= mp_maxid; cpu++) { - if (CPU_ABSENT(cpu)) - continue; - CPU_LOCK(cpu); - } - } ZONE_LOCK(z); cachefree = 0; + alloc = 0; if (!(zk->uk_flags & UMA_ZFLAG_INTERNAL)) { for (cpu = 0; cpu <= mp_maxid; cpu++) { if (CPU_ABSENT(cpu)) @@ -2784,9 +2824,12 @@ cachefree += cache->uc_allocbucket->ub_cnt; if (cache->uc_freebucket != NULL) cachefree += cache->uc_freebucket->ub_cnt; - CPU_UNLOCK(cpu); + alloc += cache->uc_allocs; + cache->uc_allocs = 0; } } + alloc += z->uz_allocs; + LIST_FOREACH(bucket, &z->uz_full_bucket, ub_link) { cachefree += bucket->ub_cnt; } @@ -2797,7 +2840,7 @@ zk->uk_maxpages * zk->uk_ipers, (zk->uk_ipers * (zk->uk_pages / zk->uk_ppera)) - totalfree, totalfree, - (unsigned long long)z->uz_allocs); + (unsigned long long)alloc); ZONE_UNLOCK(z); for (p = offset + 12; p > offset && *p == ' '; --p) /* nothing */ ; --- //depot/vendor/freebsd/src/sys/vm/uma_int.h 2005/02/16 21:50:29 +++ //depot/user/rwatson/percpu/sys/vm/uma_int.h 2005/03/15 19:57:24 @@ -342,16 +342,6 @@ #define ZONE_LOCK(z) mtx_lock((z)->uz_lock) #define ZONE_UNLOCK(z) mtx_unlock((z)->uz_lock) -#define CPU_LOCK_INIT(cpu) \ - mtx_init(&uma_pcpu_mtx[(cpu)], "UMA pcpu", "UMA pcpu", \ - MTX_DEF | MTX_DUPOK) - -#define CPU_LOCK(cpu) \ - mtx_lock(&uma_pcpu_mtx[(cpu)]) - -#define CPU_UNLOCK(cpu) \ - mtx_unlock(&uma_pcpu_mtx[(cpu)]) - /* * Find a slab within a hash table. This is used for OFFPAGE zones to lookup * the slab structure. From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 20:56:12 2005 Return-Path: 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 842CA16A4CE for ; Sun, 10 Apr 2005 20:56:12 +0000 (GMT) Received: from bremen.shuttle.de (bremen.shuttle.de [194.95.249.251]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA0FE43D1D for ; Sun, 10 Apr 2005 20:56:11 +0000 (GMT) (envelope-from schweikh@schweikhardt.net) Received: by bremen.shuttle.de (Postfix, from userid 10) id AECB83B937; Sun, 10 Apr 2005 22:56:10 +0200 (CEST) Received: from hal9000.schweikhardt.net (localhost [127.0.0.1]) j3AHGHZp064899 for ; Sun, 10 Apr 2005 19:16:17 +0200 (CEST) (envelope-from schweikh@hal9000.schweikhardt.net) Received: (from schweikh@localhost) by hal9000.schweikhardt.net (8.13.3/8.13.3/Submit) id j3AHGHDQ064898 for freebsd-current@freebsd.org; Sun, 10 Apr 2005 19:16:17 +0200 (CEST) (envelope-from schweikh) Date: Sun, 10 Apr 2005 19:16:17 +0200 From: Jens Schweikhardt To: freebsd-current@freebsd.org Message-ID: <20050410171617.GB1355@schweikhardt.net> References: <200504100251.j3A2pLEH055107@sana.init-main.com> <20050410092417.GA774@galgenberg.net> <20050410110836.GA1355@schweikhardt.net> <20050410134837.GC774@galgenberg.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050410134837.GC774@galgenberg.net> User-Agent: Mutt/1.5.9i Subject: Re: smbfs bug introduced at smbfs_vnops.c:1.58 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Apr 2005 20:56:12 -0000 ... # > $ cat foo.c # > int main(void) { # > int a; # > a+=1; # > return a; # > } # > $ gcc -O -W -Wall -Wuninitialized -Winit-self foo.c # > foo.c: In function `main': # > foo.c:2: warning: 'a' might be used uninitialized in this function # # True, but the compiler should warn about bogus source code, even if the # resulting object code (depending on optmiziation flags) is valid. Yes, but this type of warning needs data flow analysis, which IIRC is documented to need at least -O1. So I suspect the original code may have been compiled without optimization. Regards, Jens -- Jens Schweikhardt http://www.schweikhardt.net/ SIGSIG -- signature too long (core dumped) From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 22:09:19 2005 Return-Path: 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 14FA416A4CE for ; Sun, 10 Apr 2005 22:09:19 +0000 (GMT) Received: from mail-out.iptelecom.net.ua (mail-out.iptelecom.net.ua [212.9.224.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 263A243D41 for ; Sun, 10 Apr 2005 22:09:18 +0000 (GMT) (envelope-from vkushnir@i.kiev.ua) Received: from h219.241.159.dialup.iptcom.net ([213.159.241.219]:52223 "EHLO kushnir1.kiev.ua" ident: "NO-IDENT-SERVICE[2]" whoson: "vkushnir") by pechkin.iptelecom.net.ua with ESMTP id S360661AbVDJWJQ (INRCPT ); Mon, 11 Apr 2005 01:09:16 +0300 Received: from kushnir1.kiev.ua (kushnir1.kiev.ua [10.0.0.1]) by kushnir1.kiev.ua (8.13.3/8.13.3) with ESMTP id j3AM9DFn003966 for ; Mon, 11 Apr 2005 01:09:13 +0300 (EEST) (envelope-from vkushnir@i.kiev.ua) Date: Mon, 11 Apr 2005 01:09:13 +0300 (EEST) From: Vladimir Kushnir X-X-Sender: vkushnir@kushnir1.kiev.ua To: current@freebsd.org Message-ID: <20050411004706.I2914@kushnir1.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: -CURRENT and ptsname() again X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Apr 2005 22:09:19 -0000 Hello, It definitely looks like posix_openpt (perhaps) and ptsname/grantpt (most probably) do not work as they should under -CURRENT. Examples: mc (misc/mc) reports: subshell.c: couldn't open master side of pty pty_open_master: Permission denied KDE (at least CVS, but it's pty handling did not change recently) complaints about chown The simplest example: #include #include #include #include #include main() { int pty_master; char *master_name, *slave_name; struct stat sb; pty_master = posix_openpt(O_RDWR | O_NOCTTY); fstat(pty_master, &sb); if (grantpt (pty_master) < 0) { printf("Fail: grantpt\n"); } if (unlockpt (pty_master) < 0) { printf("Fail: unlocktpt\n"); } master_name = devname(sb.st_rdev, S_IFCHR); slave_name = ptsname (pty_master); printf("Open master: /dev/%s, slave: %s\n", master_name, slave_name); close (pty_master); return 0; } gives an absurd output: ~> ./ptytest Fail: grantpt Open master: /dev/ptyp0, slave: /dev/ttysu ^^^^^^^^^^ grantpt() here also fails. This is fairly recent -CURRENT: FreeBSD kushnir1.kiev.ua 6.0-CURRENT FreeBSD 6.0-CURRENT #6: Sat Apr 9 23:17:34 EEST 2005 root@:/usr/obj/usr/src/sys/KUSHNIR i386 Sorry, cannot fix it myself Redards, Vladimir From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 22:15:37 2005 Return-Path: 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 3BD4416A4CE for ; Sun, 10 Apr 2005 22:15:37 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id E09B843D46 for ; Sun, 10 Apr 2005 22:15:36 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id D4AB372DDD; Sun, 10 Apr 2005 15:15:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id D2DBD72DD4; Sun, 10 Apr 2005 15:15:36 -0700 (PDT) Date: Sun, 10 Apr 2005 15:15:36 -0700 (PDT) From: Doug White To: "Wilhelm B. Kloke" In-Reply-To: Message-ID: <20050410151401.O82708@carver.gumbysoft.com> References: <20050406233405.O47071@carver.gumbysoft.com> <200504081656.51917.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: Potential source of interrupt aliasing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Apr 2005 22:15:37 -0000 On Sun, 10 Apr 2005, Wilhelm B. Kloke wrote: > Doug White schrieb: > > On Fri, 8 Apr 2005, John Baldwin wrote: > > > > For fun, I put together this one-liner to at least test the theory: > > > > http://people.freebsd.org/~dwhite/intr_machdep.c.20050409.patch > > As I have found a problem which could be related to this, I tried your patch. > For my problems, it made things not better, possibly worse. Don't use my patch. It will cause lockups under load. I suspect that the underlying issue is related to storming issues in PIC mode, but I'd rather try to fix it in APIC mode first. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 22:56:16 2005 Return-Path: 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 1F0D416A4CE; Sun, 10 Apr 2005 22:56:16 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD25943D3F; Sun, 10 Apr 2005 22:56:15 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id B291C72DE5; Sun, 10 Apr 2005 15:56:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id AD3AA72DE4; Sun, 10 Apr 2005 15:56:15 -0700 (PDT) Date: Sun, 10 Apr 2005 15:56:15 -0700 (PDT) From: Doug White To: John Baldwin In-Reply-To: <200504101523.56787.jhb@FreeBSD.org> Message-ID: <20050410152946.W82708@carver.gumbysoft.com> References: <20050406233405.O47071@carver.gumbysoft.com> <200504081656.51917.jhb@FreeBSD.org> <200504101523.56787.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@FreeBSD.org Subject: Re: Potential source of interrupt aliasing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Apr 2005 22:56:16 -0000 On Sun, 10 Apr 2005, John Baldwin wrote: > > For fun, I put together this one-liner to at least test the theory: > > > > http://people.freebsd.org/~dwhite/intr_machdep.c.20050409.patch > > Doing this should result in an instant interrupt storm since your PCI > interrupts (which are level triggered) should now keep firing over and over > and the machine will spend all it's time rescheduling the ithread. If it's > not doing that then this is very curious. Causing the storm was partly the point. I wanted to find a way to weather it as cheaply as possible until the ithread would get run. > > This makes the aliased interrupts go away at the cost of hitting > > sched_lock for each ithread interrupt. I'm trying to dream up a way of > > telling if the ithread is active or scheduled so we don't need to bump it > > again with setrunqueue(). I think I can use the it_need sparkplug to at > > least save mutex grabs on interrupts that fire much faster than their > > ithread handlers cycle. > > > > I'd like better granularity, though, but I'm not sure that setting a flag > > that is cleared just before mi_switch() in ithread_loop() and set just > > after won't race against an interrupt checking it to see if it needs to > > setrunqueue() the ithread. Maybe clear the flag before trying to grab > > sched_lock? > > it_need already does this. You haven't added any extra sched_locks. What've > you done is change the interrupt code to never mask interrupt sources. If > you aren't getting an interrupt storm on your first PCI interrupt then that > is very curious indeed. Have you tried this with SMP disabled so that you > only have one CPU running? It may be that due to SMP your ithread still gets > a chance to run on one CPU while the other CPU is stormed with interrupt > requests. Note that since storm detection is done in the ithread, this type > of storm won't be detected and throttled. It also might not show up in the > vmstats since we don't use atomic ops there anymore depending on whether or > not the interrupt bounces between CPUs that keep overwriting the count on top > of each other. I think you're right in the SMP case -- if one CPU gets bogged down another can get the ithread to bail it out. For the UP case, turning on INVARIANTS+WITNESS+!WITNESS_SKIPSPIN causes a lockup as the IOAPIC vectors are unmasked before the other CPUs are started on Scott's WV2. A traceback shows softclock's ithread running and taking an interrupt from em1, which is assumably triggering over and over since softclock can't seem to get out of its ithread. The debugging options and the constant interrupts slow it down so much that it isn't cycling fully before softclock fires again (or thats what it looks like). Adding a mi_switch() in the callout_lock drop/pickup didn't seem to help. Adding a bypass of setrunqueue() in ithread_schedule() if it_need is set also had no impact. I haven't tried things with PREEMPTION. I'm also taking suggestions for other places to try to mask interrupts. I pondered pulling the vector from the IDT, but that generates a trap. I don't think there's anything we can do in the LAPIC thats anything less than disabling interrupts entirely. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 00:12:12 2005 Return-Path: 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 EA8C116A4CE; Mon, 11 Apr 2005 00:12:12 +0000 (GMT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F61843D3F; Mon, 11 Apr 2005 00:12:12 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) j3B0CC0e046728; Sun, 10 Apr 2005 17:12:12 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id j3B0CCZQ046727; Sun, 10 Apr 2005 17:12:12 -0700 (PDT) (envelope-from dillon) Date: Sun, 10 Apr 2005 17:12:12 -0700 (PDT) From: Matthew Dillon Message-Id: <200504110012.j3B0CCZQ046727@apollo.backplane.com> To: Doug White References: <20050406233405.O47071@carver.gumbysoft.com> <200504081656.51917.jhb@FreeBSD.org> <20050410152946.W82708@carver.gumbysoft.com> cc: freebsd-current@freebsd.org Subject: Re: Potential source of interrupt aliasing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 00:12:13 -0000 A couple of things don't click here. First, unless this 'boot interrupt' IRQ is pointing to an APIC vector that is initialized to point at the softclock there is no way the softclock ithread could be involved. I'm not saying that it isn't running away, just that the boot interrupt business is probably not the cause. This boot interrupt thingy kinda sounds like a red herring. Secondly, you HAVE to mask the APIC vector in the interrupt service routine if the service routine is going to schedule an ithread. There's no choice... it HAS to be done because the ISR isn't capable of clearing the originating interrupt from the device... the interrupt thread has to do that. *BUT* it *IS* possible that the wrong APIC vector is being masked (and not because of an interrupt alias, but because the actual hard interrupt is misrouted). I've seen this occur numerous times. What happens is that a device generates an mis-routed interrupt which causes the interrupt handler for an UNRELATED device to run. It runs to completion but since the device it thought interrupted was not the device that actually interrupted, the interrupt on the actual originating device never gets cleared so the moment the ithread completes and unmasks that APIC vector, the APIC issues another interrupt. The result is that the ithread is constantly running. Misrouted interrupts are a serious problem. They seem to be caused by the BIOS or ACPI getting confused about how bridges are wired... when multiple devices route an interrupt through the same pin on a bridge and one is routed, the BIOS or ACPI gets seriously confused about the second device and may believe that the second device can be routed to a different IRQ when, in fact, it can't. You wind up with one of the two devices on the wrong IRQ. This problem is exasperated when the BIOS routes some of the devices for use by the BIOS (such as for PXE booting), or to handle a USB keyboard, or something of that sort. -Matt From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 00:52:27 2005 Return-Path: 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 6A91B16A4CE; Mon, 11 Apr 2005 00:52:27 +0000 (GMT) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DD6243D39; Mon, 11 Apr 2005 00:52:24 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.12.11/8.12.10) with ESMTP id j3B0qEIf043030; Mon, 11 Apr 2005 10:22:15 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Mon, 11 Apr 2005 10:21:54 +0930 User-Agent: KMail/1.8 References: <84dead72050408235974f03b68@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5060877.b2DkfxlNh4"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504111022.06861.doconnor@gsoft.com.au> X-Spam-Score: -1.7 () IN_REP_TO,PGP_SIGNATURE_2,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) cc: Darrel cc: freebsd-questions@freebsd.org Subject: Re: can't cd to /usr/obj/usr/src/sys/BIGD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 00:52:27 -0000 --nextPart5060877.b2DkfxlNh4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I've redirected this to freebsd-questions which is more relevant. On Sat, 9 Apr 2005 17:01, Darrel wrote: > make buildworld > exit > script /var/tmp/bk.out > make buildkernel KERNCONF=3DBIGD > exit Did these succeed? You didn't cd into /usr/src first so I don't see how they can have worked.. > - Rebooted to single user > fsck -p Why run fsck? > mount -u / > mount -a -t ufs mount -a is fine here (unless you have NFS in fstab) > swapon -a > make installkernel KERNCONF=3DBIGD > error code don't know how to make bsd.README You aren't in /usr/src? Did you read the handbook on this stuff? =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart5060877.b2DkfxlNh4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBCWco25ZPcIHs/zowRAuGoAKCF/goQGhh01hpbX/D5gWWW53ySiQCfbY0r cHSrFnLbGovqLYPRW1SZS4o= =r7vj -----END PGP SIGNATURE----- --nextPart5060877.b2DkfxlNh4-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 01:05:44 2005 Return-Path: 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 A56B516A4CE; Mon, 11 Apr 2005 01:05:44 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4983A43D48; Mon, 11 Apr 2005 01:05:44 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 3CCD572DDD; Sun, 10 Apr 2005 18:05:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 3736672DD4; Sun, 10 Apr 2005 18:05:44 -0700 (PDT) Date: Sun, 10 Apr 2005 18:05:44 -0700 (PDT) From: Doug White To: Matthew Dillon In-Reply-To: <200504110012.j3B0CCZQ046727@apollo.backplane.com> Message-ID: <20050410172818.D82708@carver.gumbysoft.com> References: <20050406233405.O47071@carver.gumbysoft.com> <200504081656.51917.jhb@FreeBSD.org> <20050410152946.W82708@carver.gumbysoft.com> <200504110012.j3B0CCZQ046727@apollo.backplane.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: Potential source of interrupt aliasing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 01:05:44 -0000 On Sun, 10 Apr 2005, Matthew Dillon wrote: > A couple of things don't click here. > > First, unless this 'boot interrupt' IRQ is pointing to an APIC vector > that is initialized to point at the softclock there is no way the > softclock ithread could be involved. I'm not saying that it isn't > running away, just that the boot interrupt business is probably not > the cause. This boot interrupt thingy kinda sounds like a red herring. softclock is the poor innocent bystander. Any ithread would do. As long as its something that prevents other ithreads from being scheduled. Thats still an experiment in progress, though, so don't get too hung up on it. > Secondly, you HAVE to mask the APIC vector in the interrupt service > routine if the service routine is going to schedule an ithread. There's > no choice... it HAS to be done because the ISR isn't capable of clearing > the originating interrupt from the device... the interrupt thread has to > do that. Or acknowledge the interrupt in the hardware before scheduling the ithread via a routine provided by the driver. > *BUT* it *IS* possible that the wrong APIC vector is being masked (and > not because of an interrupt alias, but because the actual hard interrupt > is misrouted). I don't think this is the case. Somehow the vector would have to get corrupted during this function call, which is line 609 in src/sys/i386/i386/local_apic.c: isrc = intr_lookup_source(apic_idt_to_irq(frame.if_vec)); which reduces to an array lookup with an offset index. apic_idt_to_irq(), with the asserts and range checks removed, is: return (vector - APIC_IO_INTS); And intr_lookup_source is: return (interrupt_sources[vector]); I would expect much wider aliasing or stray interrupt problems if this was occuring. > I've seen this occur numerous times. What happens is > that a device generates an mis-routed interrupt which causes the > interrupt handler for an UNRELATED device to run. It runs to completion > but since the device it thought interrupted was not the device that > actually interrupted, the interrupt on the actual originating device > never gets cleared so the moment the ithread completes and unmasks that > APIC vector, the APIC issues another interrupt. The result is that the > ithread is constantly running. > > Misrouted interrupts are a serious problem. They seem to be caused by > the BIOS or ACPI getting confused about how bridges are wired... when > multiple devices route an interrupt through the same pin on a bridge > and one is routed, the BIOS or ACPI gets seriously confused about > the second device and may believe that the second device can be routed > to a different IRQ when, in fact, it can't. You wind up with one of > the two devices on the wrong IRQ. This problem is exasperated when > the BIOS routes some of the devices for use by the BIOS (such as for > PXE booting), or to handle a USB keyboard, or something of that sort. I'm convinced these "misrouted interrupts" are sourcing from the boot interrupt functionality. You don't route interrupts in APIC mode; its a flat space. All of the APIC entries stack together as if they were one gigantic IOAPIC that every PCI device's INTx lines were attached to. This is the System Interrupts model described in the ACPI specification. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 02:31:24 2005 Return-Path: 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 DD9C316A4CE; Mon, 11 Apr 2005 02:31:24 +0000 (GMT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7838F43D1D; Mon, 11 Apr 2005 02:31:24 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) j3B2VO0e047362; Sun, 10 Apr 2005 19:31:24 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id j3B2VOYr047361; Sun, 10 Apr 2005 19:31:24 -0700 (PDT) (envelope-from dillon) Date: Sun, 10 Apr 2005 19:31:24 -0700 (PDT) From: Matthew Dillon Message-Id: <200504110231.j3B2VOYr047361@apollo.backplane.com> To: Doug White References: <20050406233405.O47071@carver.gumbysoft.com> <200504081656.51917.jhb@FreeBSD.org> <20050410152946.W82708@carver.gumbysoft.com> <20050410172818.D82708@carver.gumbysoft.com> cc: freebsd-current@freebsd.org Subject: Re: Potential source of interrupt aliasing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 02:31:25 -0000 :Or acknowledge the interrupt in the hardware before scheduling the :ithread via a routine provided by the driver. There are two things that need to be acknowledged. (1) The APIC needs to be EOI'd to clear the interrupt so the APIC can deliver the next interrupt. If you don't do this, ALL interrupt sources stop working. (2) The actual device is asserting a level interrupt. Just EOI'ing the interrupt the APIC delivers does not turn off the interrupt. The APIC will see that the device is still asserting the interrupt and immediately generate another event. The actual device has to deassert the interrupt, but this means that you generally have to process the events from the device to accomplish that. You often can't process these events in the hard interrupt vector handling function (otherwise they'd simply be FAST interrupts, but since they aren't they need the interrupt thread's context to be properly processed). This means that you can't deassert the interrupt from the device source at the time you get the hardware interrupt. Since the device interrupt cannot be deasserted at the time the actual interrupt occurs the only thing you can do is mask the interrupt in the APIC so the APIC stops dispatching it. The interrupt thread is then responsible for unmasking the interrupt in the APIC after it has finished processing the events from the device(s) and presumably cleared the interrupt at its source. Even worse, every interrupting device manages its interrupt sources differently. There is no universal, generic way to clear a device interrupt... only the actual device driver knows how to deal with it and often that means actually processing the related device events before the interrupt can be cleared. :> *BUT* it *IS* possible that the wrong APIC vector is being masked (and :> not because of an interrupt alias, but because the actual hard interrupt :> is misrouted). : :I don't think this is the case. Somehow the vector would have to get :corrupted during this function call, which is line 609 in :src/sys/i386/i386/local_apic.c: : :isrc = intr_lookup_source(apic_idt_to_irq(frame.if_vec)); The vector is not being corrupted at all. Just put that out of your mind... the APIC is working just fine. The problem is most likely that the device is asserting the interrupt on the WRONG PIN. Since the wrong IRQ is asserted, the wrong APIC vector is dispatched, the wrong interrupt handler and ithread is run, and the source from the device that actually generated the interrupt is NOT cleared (because it isn't the device that the system thinks generated the interrupt). :I would expect much wider aliasing or stray interrupt problems if this was :occuring. It's usually just one or possibly two devices that are mis-configured, mainly because the BIOS confusion is typically limited to particular devices. It depends heavily on the motherboard, BIOS, what devices are enabled in the BIOS, and what devices the BIOS itself needs (e.g. for PXE booting, USB keyboard, booting, etc) to boot. :I'm convinced these "misrouted interrupts" are sourcing from the boot :interrupt functionality. You don't route interrupts in APIC mode; its a :flat space. All of the APIC entries stack together as if they were one :gigantic IOAPIC that every PCI device's INTx lines were attached to. This :is the System Interrupts model described in the ACPI specification. : :-- :Doug White | FreeBSD: The Power to Serve :dwhite@gumbysoft.com | www.FreeBSD.org You do route interrupts in APIC mode. I wish it were a flat space! It isn't. I think you are forgetting a couple of things here: * PCI busses only have 4 interrupt lines (A, B, C, and D). * Motherboards often have anywhere from 3 to 6 PCI or PCI-like busses, connected to the APICs via bridge chips. * The bridge chips have a limited number of IRQ pins. * Sometimes you have several bridges connected to another bridge before it gets to the APIC. So the answer is... regardless of the capabilities of the APIC(s) devices still often have limited choices that require IRQ sharing simply due to the PCI BUS and BRIDGE configuration of the motherboard. But even more to the point, BIOSes (ACPI, etc.) often get really confused about routing IRQs through bridges. They will for example believe that two devices that share a *PHYSICAL* IRQ line through a bridge are capable of being assigned different IRQs when, in fact, they aren't. They will get confused about how some of the PCI IRQ lines are routed to the bridges (so line 'B' on PCI bus #1 might be misconfigured, for example). All sorts of bad things can happen. The only way for an operating system to figure this stuff out on its own is to understand the umpteen different bridge chips out there, test physical interrupt sources (which is not always possible) to see how they are actually routed, and ignore the BIOS completely. Wasn't it something like NetBSD or OpenBSD that was thinking about doing that? Not trying to figure out the routing but instead just figure out which vector was being asserted for a device? I'm beginning to think that that may be the ONLY solution. Intel really screwed up big time. Motorola had a much, much, MUCH better mechanism where the actual devices generated the actual vector number on the interrupt bus and the only thing you might have hardwired would have been the IPL. But Intel doesn't work that way. Their stuff is just totally screwed when it comes to handling interrupts. It's completely 100% guarenteed pungent crapola to anyone who has ever built hardware with a *REAL* interrupt subsystem. -Matt Matthew Dillon From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 02:49:32 2005 Return-Path: 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 7D02116A4CE; Mon, 11 Apr 2005 02:49:32 +0000 (GMT) Received: from av5-1-sn1.fre.skanova.net (av5-1-sn1.fre.skanova.net [81.228.11.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AD1A43D1F; Mon, 11 Apr 2005 02:49:32 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: by av5-1-sn1.fre.skanova.net (Postfix, from userid 502) id DFDF237E4A; Mon, 11 Apr 2005 04:49:30 +0200 (CEST) Received: from smtp3-2-sn1.fre.skanova.net (smtp3-2-sn1.fre.skanova.net [81.228.11.164]) by av5-1-sn1.fre.skanova.net (Postfix) with ESMTP id CC31837E48; Mon, 11 Apr 2005 04:49:30 +0200 (CEST) Received: from sentinel (h104n1-gl-a-d4.ias.bredband.telia.com [195.198.193.104]) by smtp3-2-sn1.fre.skanova.net (Postfix) with ESMTP id B0FAE37E42; Mon, 11 Apr 2005 04:49:30 +0200 (CEST) From: "Daniel Eriksson" To: "'FreeBSD Current'" Date: Mon, 11 Apr 2005 04:49:16 +0200 Organization: Home Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcU+QQ0jOzhTi0sXTUGqnvO2q2I/cg== cc: 'Pawel Jakub Dawidek' Subject: ggate and mmap, possible problem? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 02:49:32 -0000 Hi! Is it possible that there is some sort of problem using mmap on a (UFS2) filesystem mounted over ggate? I keep getting errors on the console when I enable mmap on a server running a proprietary video server application (which is a binary compiled on FBSD 4.11 afaik). I don't have access to the source code for the server app unfortunately (but I do have some access to the developers). I'm pretty sure that with mmap enabled in the server, it tries to mmap all files smaller than 50MB (most are 20-50MB). The errors look like this: g_vfs_done():ggate0[READ(offset=-1009882480640, length=65536)]error = 5 vnode_pager_getpages: I/O read error vm_fault: pager read error, pid 1527 (mcvidserv) This could certainly be a problem in the proprietary server, but I thought I'd ask here too. This is on a recent 6-CURRENT system. /Daniel Eriksson From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 03:25:59 2005 Return-Path: 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 62C2E16A4CE for ; Mon, 11 Apr 2005 03:25:59 +0000 (GMT) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id CEE3243D55 for ; Mon, 11 Apr 2005 03:25:58 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.3/8.13.3) with ESMTP id j3B3PwIV001464 for ; Sun, 10 Apr 2005 20:25:58 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.3/8.13.1/Submit) id j3B3Pwop001463 for freebsd-current@freebsd.org; Sun, 10 Apr 2005 20:25:58 -0700 (PDT) (envelope-from obrien) Date: Sun, 10 Apr 2005 20:25:58 -0700 From: "David O'Brien" To: freebsd-current@freebsd.org Message-ID: <20050411032558.GA1406@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Operating-System: FreeBSD 6.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 Subject: [PANIC] vm? vfs? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@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: Mon, 11 Apr 2005 03:25:59 -0000 FreeBSD 6.0-CURRENT FreeBSD 6.0-CURRENT #0: Tue Apr 5 12:19:35 PDT 2005 GNU gdb 20040810 [GDB v6.x for FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-portbld-freebsd6.0"... panic: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc063596a stack pointer = 0x10:0xf04e9b64 frame pointer = 0x10:0xf04e9b90 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1062 (xterm-static) trap number = 12 panic: page fault cpuid = 1 KDB: stack backtrace: kdb_backtrace(c067f02d,1,c065a072,f04e9a88,c344a730) at 0xc04f910e = kdb_backtrace+0x2e panic(c065a072,c0680005,f04e9b24,1,1) at 0xc04dc508 = panic+0x128 trap_fatal(f04e9b24,0,c06801e7,2c3,c344a730) at 0xc0637a84 = trap_fatal+0x304 trap_pfault(f04e9b24,0,0,f04e9b1c,0) at 0xc0637758 = trap_pfault+0x1b8 trap(18,10,10,f04e9bac,0) at 0xc0637340 = trap+0x350 calltrap() at 0xc062408a = calltrap+0x5 --- trap 0xc, eip = 0xc063596a, esp = 0xf04e9b64, ebp = 0xf04e9b90 --- generic_bcopy(c37d2038,f04e9bac,64,808cc30,c06b92a0) at 0xc063596a = generic_bcopy+0x1a ptcread(c33f1500,f04e9c80,4,3ae,1000) at 0xc0518d95 = ptcread+0x185 devfs_read_f(c380a360,f04e9c80,c3395880,0,c344a730) at 0xc049a806 = devfs_read_f+0xa6 dofileread(c344a730,c380a360,4,8085c20,1000) at 0xc0504aa2 = dofileread+0xc2 read(c344a730,f04e9d14,c,3ff,3) at 0xc050490b = read+0x6b syscall(2f,2f,2f,8085c20,80a0084) at 0xc0637de2 = syscall+0x2b2 Xint0x80_syscall() at 0xc06240df = Xint0x80_syscall+0x1f --- syscall (3, FreeBSD ELF32, read), eip = 0x28382edf, esp = 0xbfbfe66c, ebp = 0xbfbfe698 --- Uptime: 1d8h49m32s Dumping 1536 MB [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 16[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 32[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 48[CTRL-C to abort] 64 80[CTRL-C to abort] 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624 640 656 672 688 704 720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976 992 1008 1024 1040 1056 1072 1088 1104 1120 1136 1152 1168 1184 1200 1216 1232 1248 1264 1280 1296 1312 1328 1344 1360 1376 1392 1408 1424 1440 1456 1472 1488 1504 1520 --- #0 doadump () at pcpu.h:164 164 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); doadump () at pcpu.h:164 164 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) where #0 doadump () at pcpu.h:164 #1 0xc04dc1d2 in boot (howto=260) at ../../../kern/kern_shutdown.c:398 #2 0xc04dc583 in panic (fmt=0xc065a072 "%s") at ../../../kern/kern_shutdown.c:554 #3 0xc0637a84 in trap_fatal (frame=0xf04e9b24, eva=0) at ../../../i386/i386/trap.c:806 #4 0xc0637758 in trap_pfault (frame=0xf04e9b24, usermode=0, eva=0) at ../../../i386/i386/trap.c:724 #5 0xc0637340 in trap (frame= {tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -263283796, tf_esi = 0, tf_ebp = -263283824, tf_isp = -263283888, tf_ebx = 38, tf_edx = 0, tf_ecx = 9, tf_eax = -263283796, tf_trapno = 12, tf_err = 0, tf_eip = -1067230870, tf_cs = 8, tf_eflags = 66071, tf_esp = -1015209928, tf_ss = 128}) at ../../../i386/i386/trap.c:414 #6 0xc062408a in calltrap () at ../../../i386/i386/exception.s:139 #7 0x00000018 in ?? () #8 0x00000010 in ?? () #9 0x00000010 in ?? () #10 0xf04e9bac in ?? () #11 0x00000000 in ?? () #12 0xf04e9b90 in ?? () #13 0xf04e9b50 in ?? () #14 0x00000026 in ?? () #15 0x00000000 in ?? () #16 0x00000009 in ?? () #17 0xf04e9bac in ?? () #18 0x0000000c in ?? () #19 0x00000000 in ?? () #20 0xc063596a in generic_bcopy () at ../../../i386/i386/support.s:489 ---Type to continue, or q to quit--- #21 0xc37d2038 in ?? () #22 0x00000080 in ?? () #23 0xc05199fa in q_to_b (clistp=0xc063596a, dest=0xf04e9bac "\r\n/FBSD: write failed, filesystem is \025?Ã`£\200Ãð\233Nðê\003KÀ \222kÀ", amount=100) at ../../../kern/tty_subr.c:290 #24 0xc0518d95 in ptcread (dev=0x0, uio=0xf04e9c80, flag=4) at libkern.h:56 #25 0xc049a806 in devfs_read_f (fp=0xc380a360, uio=0xf04e9c80, cred=0xc3395880, flags=0, td=0xc344a730) at ../../../fs/devfs/devfs_vnops.c:943 #26 0xc0504aa2 in dofileread (td=0xc344a730, fp=0xc380a360, fd=0, buf=0x0, nbyte=3228113056, offset=Unhandled dwarf expression opcode 0x93 ) at file.h:234 #27 0xc050490b in read (td=0xc344a730, uap=0xf04e9d14) at ../../../kern/sys_generic.c:107 #28 0xc0637de2 in syscall (frame= {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134765600, tf_esi = 134873220, tf_ebp = -1077942632, tf_isp = -263283340, tf_ebx = 0, tf_edx = 0, tf_ecx = 4, tf_eax = 3, tf_trapno = 0, tf_err = 2, tf_eip = 674770655, tf_cs = 31, tf_eflags = 642, tf_esp = -1077942676, tf_ss = 47}) at ../../../i386/i386/trap.c:951 #29 0xc06240df in Xint0x80_syscall () at ../../../i386/i386/exception.s:200 #30 0x0000002f in ?? () #31 0x0000002f in ?? () #32 0x0000002f in ?? () #33 0x08085c20 in ?? () #34 0x080a0084 in ?? () #35 0xbfbfe698 in ?? () #36 0xf04e9d74 in ?? () #37 0x00000000 in ?? () #38 0x00000000 in ?? () ---Type to continue, or q to quit--- #39 0x00000004 in ?? () #40 0x00000003 in ?? () #41 0x00000000 in ?? () #42 0x00000002 in ?? () #43 0x28382edf in ?? () #44 0x0000001f in ?? () #45 0x00000282 in ?? () #46 0xbfbfe66c in ?? () #47 0x0000002f in ?? () #48 0x28184f96 in ?? () #49 0x28184fa6 in ?? () #50 0x28184fb6 in ?? () #51 0x28184fc6 in ?? () #52 0x49eee000 in ?? () #53 0xc350a5f4 in ?? () #54 0xc344a730 in ?? () #55 0xf04e99b0 in ?? () #56 0xf04e9990 in ?? () #57 0xc2bc4a10 in ?? () #58 0xc04efda0 in sched_switch (td=0x80a0084, newtd=0x0, flags=---Can't read userspace from dump, or kernel process--- ) at ../../../kern/sched_4bsd.c:963 Previous frame inner to this frame (corrupt stack?) From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 03:29:18 2005 Return-Path: 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 A1CF316A4CE for ; Mon, 11 Apr 2005 03:29:18 +0000 (GMT) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70CE643D1F for ; Mon, 11 Apr 2005 03:29:18 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.3/8.13.3) with ESMTP id j3B3THQr001619; Sun, 10 Apr 2005 20:29:17 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.3/8.13.1/Submit) id j3B3THMh001618; Sun, 10 Apr 2005 20:29:17 -0700 (PDT) (envelope-from obrien) Date: Sun, 10 Apr 2005 20:29:17 -0700 From: "David O'Brien" To: Darrel Message-ID: <20050411032917.GA1529@dragon.NUXI.org> Mail-Followup-To: freebsd-current@freebsd.org, Darrel References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 6.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: freebsd-current@freebsd.org Subject: Re: gnome upgrade on GENERIC i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 03:29:18 -0000 On Sun, Apr 10, 2005 at 02:27:37PM -0400, Darrel wrote: > Can I delete all of the files in /var/tmp? I am not sure if any of them > are necessary: > > epiphany > f-prot > gconfd > installkernel > orbit > packlists- several > temproot This looks like someone manually using /var/tmp when they probably wanted /tmp. > vi.recover This one is necessary. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 03:42:46 2005 Return-Path: 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 C1A6016A4CE; Mon, 11 Apr 2005 03:42:46 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.194.102.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8555743D41; Mon, 11 Apr 2005 03:42:46 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id C74135148C; Sun, 10 Apr 2005 20:42:45 -0700 (PDT) Date: Sun, 10 Apr 2005 20:42:45 -0700 From: Kris Kennaway To: obrien@freebsd.org, freebsd-current@freebsd.org Message-ID: <20050411034245.GA21389@xor.obsecurity.org> References: <20050411032558.GA1406@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/04w6evG8XlLl3ft" Content-Disposition: inline In-Reply-To: <20050411032558.GA1406@dragon.NUXI.org> User-Agent: Mutt/1.4.2.1i Subject: Panic resizing an xterm (Re: [PANIC] vm? vfs?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 03:42:46 -0000 --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Apr 10, 2005 at 08:25:58PM -0700, David O'Brien wrote: > current process = 1062 (xterm-static) > ptcread(c33f1500,f04e9c80,4,3ae,1000) at 0xc0518d95 = ptcread+0x185 This is the 'resize an xterm' panic I reported last week. phk said he hoped to look at it today. Kris --/04w6evG8XlLl3ft Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCWfI1Wry0BWjoQKURAp+NAJ9SDq1v0aKvTUkDY1/2CC2tbPgSCgCfchjl IFoSDo4nk+xM10f3FJTsWBc= =A7VL -----END PGP SIGNATURE----- --/04w6evG8XlLl3ft-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 04:16:45 2005 Return-Path: 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 8211C16A4CF for ; Mon, 11 Apr 2005 04:16:45 +0000 (GMT) Received: from web54005.mail.yahoo.com (web54005.mail.yahoo.com [206.190.36.229]) by mx1.FreeBSD.org (Postfix) with SMTP id E9B3843D48 for ; Mon, 11 Apr 2005 04:16:44 +0000 (GMT) (envelope-from spamrefuse@yahoo.com) Received: (qmail 23796 invoked by uid 60001); 11 Apr 2005 04:16:44 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=10pYfWM1C/rogWGG/P9RZWB4eYocWrgpnYGrz7Ua/R/uzxjhWv0A3AELbjpkxOz7NIjczYDMhXp6r6FNfvMZK8KuMCpNxDRVnwJsjLN+UTIAKitSlHcEdXCYzoNQkPusH8rxCl/nP3JnsUmBU5WQEGlBBcEJ+immfz619Y51DrI= ; Message-ID: <20050411041644.23794.qmail@web54005.mail.yahoo.com> Received: from [147.46.44.181] by web54005.mail.yahoo.com via HTTP; Sun, 10 Apr 2005 21:16:44 PDT Date: Sun, 10 Apr 2005 21:16:44 -0700 (PDT) From: Rob To: Ruslan Ermilov In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: FreeBSD current Subject: Re: xl(4) & polling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 04:16:45 -0000 --- Ruslan Ermilov wrote: > On Sat, Apr 09, 2005 at 06:54:20PM -0700, Rob wrote: >> PS: if this makes it into the official sources, >> then don't forget to also add xl(4) to the >> polling(4) manpage. > > It did (last month). The manpage was also updated. Will it also go into RELENG_5, after the 5.4 release? Rob. __________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 04:50:03 2005 Return-Path: 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 7E62016A4CE for ; Mon, 11 Apr 2005 04:50:03 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A0D443D1F for ; Mon, 11 Apr 2005 04:50:02 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.1/8.13.1) with ESMTP id j3B4nsbn031634; Sun, 10 Apr 2005 21:49:58 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200504110449.j3B4nsbn031634@gw.catspoiler.org> Date: Sun, 10 Apr 2005 21:49:54 -0700 (PDT) From: Don Lewis To: tk@giga.or.at In-Reply-To: <20050410152016.GA18914@dmath5.geometrie.tuwien.ac.at> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-current@FreeBSD.org Subject: Re: fsck_ufs: cannot alloc 3166749884 bytes for inoinfo X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 04:50:03 -0000 On 10 Apr, Thomas Klausner wrote: > On Sun, Feb 27, 2005 at 08:24:15AM +0000, Don Lewis wrote: >> On 26 Feb, Kris Kennaway wrote: >> > A recent panic left my FS with some serious corruption, which fsck is >> > unable to repair: >> > >> > # fsck_ufs -b 376512 -fy /var >> > Alternate super block location: 376512 >> > ** /dev/twed0s1e >> > ** Last Mounted on >> > ** Phase 1 - Check Blocks and Sizes >> > fsck_ufs: cannot alloc 3166749884 bytes for inoinfo >> > >> > (same holds for any superblock I've tried). >> > >> > How can I recover from this, short of running newfs? >> >> What does dumpfs say about the contents of the superblock? For some >> reason fsck thinks it needs to allocate space to hold the information >> about 791687471 in one cylinder group, which seems a bit unlikely. > > I have a similar problem with a 110GB UFS on 5.3/i386. > fsck dies for me with: > fsck_ufs: cannot alloc 607016868 bytes for inoinfo > > df output is strange too: > /dev/ad6s1a 113552318 -6315512682 6419980816 -6045% /vcr > > The dumpfs output for the file system is attached; > As you can see, dumpfs dumps core in the end. > > Any ideas how to restore this file system without using newfs > are welcome. At line 92 in src/sbin/fsck_ffs/pass1.c, you should see the following block of code: for (c = 0; c < sblock.fs_ncg; c++) { inumber = c * sblock.fs_ipg; setinodebuf(inumber); getblk(&cgblk, cgtod(&sblock, c), sblock.fs_cgsize); if (sblock.fs_magic == FS_UFS2_MAGIC) inosused = cgrp.cg_initediblk; else inosused = sblock.fs_ipg; Try changing inosused = cgrp.cg_initediblk; to inosused = (cgrp.cg_initediblk <= sblock.fs_ipg) ? cgrp.cg_initediblk : sblock.fs_ipg; and don't use the preen option. I'm not sure what the correct way of handling this problem is, but silently ignoring it probably is not right. It would also be nice to figure out how cg_initediblk is getting stomped on. Your dumpfs output shows that the cg 448 cylinder group block is getting spammed. cg 448:^M magic 5af7bc9b tell 1419718000 time Sat Oct 24 09:26:01 1953 ^M cgx 1974102781 ndblk 94980298 niblk -238122138 initiblk 151754217^M nbfree 260006838 ndir -1408502548 nifree -1954530115 nffree 1098493286^M rotor -2054137791 irotor 264831483 frotor -828630751^M frsum 348903779 -1401240352 380969914 -1562381953 -1776938 457 90294057 -1759202067^M Even the magic number is getting spammed (the correct value is 90255). That would seem to be fatal in the preen case: if (preen && usedsoftdep) { if (!cg_chkmagic(&cgrp)) pfatal("CG %d: BAD MAGIC NUMBER\n", c); From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 05:56:43 2005 Return-Path: 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 2E26316A4CE for ; Mon, 11 Apr 2005 05:56:43 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7703B43D45 for ; Mon, 11 Apr 2005 05:56:42 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j3B60D42028662; Mon, 11 Apr 2005 00:00:13 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <425A10DD.70500@samsco.org> Date: Sun, 10 Apr 2005 23:53:33 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Dillon References: <20050406233405.O47071@carver.gumbysoft.com> <200504081656.51917.jhb@FreeBSD.org> <20050410152946.W82708@carver.gumbysoft.com> <20050410172818.D82708@carver.gumbysoft.com> <200504110231.j3B2VOYr047361@apollo.backplane.com> In-Reply-To: <200504110231.j3B2VOYr047361@apollo.backplane.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 Subject: Re: Potential source of interrupt aliasing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 05:56:43 -0000 Matthew Dillon wrote: > :Or acknowledge the interrupt in the hardware before scheduling the > :ithread via a routine provided by the driver. > > There are two things that need to be acknowledged. > > (1) The APIC needs to be EOI'd to clear the interrupt so the APIC > can deliver the next interrupt. If you don't do this, ALL > interrupt sources stop working. > > (2) The actual device is asserting a level interrupt. Just EOI'ing > the interrupt the APIC delivers does not turn off the interrupt. > The APIC will see that the device is still asserting the interrupt > and immediately generate another event. > > The actual device has to deassert the interrupt, but this means > that you generally have to process the events from the device > to accomplish that. You often can't process these events in the > hard interrupt vector handling function (otherwise they'd simply > be FAST interrupts, but since they aren't they need the interrupt > thread's context to be properly processed). Hogwash. There is quite a bit of hardware that will allow you to silence the interrupt source without actually processing the interrupt data right away. This is a key feature of the interrupt handling API in Mac OSX, actually. I even have the AAC driver operate in this fashion for FreeBSD. > > This means that you can't deassert the interrupt from the device > source at the time you get the hardware interrupt. > > Since the device interrupt cannot be deasserted at the time the actual > interrupt occurs the only thing you can do is mask the interrupt in the > APIC so the APIC stops dispatching it. I'm not sure if you've actually read and comprehended Doug's mail. The 'boot interrupt', as documented in the Intel manuals, comes from masking the real intpin in the APIC while the source is asserted. This whole email thread is about figuring out a way to service interrupts without triggering this 'reroute-on-apic-mask-event' feature of the chipset. > > The interrupt thread is then responsible for unmasking the interrupt > in the APIC after it has finished processing the events from the > device(s) and presumably cleared the interrupt at its source. This is How Things Work already. > > Even worse, every interrupting device manages its interrupt sources > differently. There is no universal, generic way to clear a device > interrupt... only the actual device driver knows how to deal with it > and often that means actually processing the related device events > before the interrupt can be cleared. See above. You're making a blanket statement that is incorrect for most PCI hardware. > > :> *BUT* it *IS* possible that the wrong APIC vector is being masked (and > :> not because of an interrupt alias, but because the actual hard interrupt > :> is misrouted). > : > :I don't think this is the case. Somehow the vector would have to get > :corrupted during this function call, which is line 609 in > :src/sys/i386/i386/local_apic.c: > : > :isrc = intr_lookup_source(apic_idt_to_irq(frame.if_vec)); > > The vector is not being corrupted at all. Just put that out of your > mind... the APIC is working just fine. The problem is most likely > that the device is asserting the interrupt on the WRONG PIN. Since > the wrong IRQ is asserted, the wrong APIC vector is dispatched, the > wrong interrupt handler and ithread is run, and the source from the > device that actually generated the interrupt is NOT cleared (because > it isn't the device that the system thinks generated the interrupt). > No, you are absoutely wrong here. I can speak from authority because Doug is testing on hardware that sits in my basement. When an interrupt fires on em0 or ahd0, it shows up on the irq for both the actual source and for irq16, which just happens to be uhci0. There is no misrouting at all, it's that the interrupt is showing up in two places. With a little detective work, Doug discovered that it shows up on irq16 only after the real intpin has been masked in the APIC. Again, please re-read and comprehend his emails. > :I would expect much wider aliasing or stray interrupt problems if this was > :occuring. > > It's usually just one or possibly two devices that are mis-configured, > mainly because the BIOS confusion is typically limited to particular > devices. It depends heavily on the motherboard, BIOS, what devices > are enabled in the BIOS, and what devices the BIOS itself needs (e.g. > for PXE booting, USB keyboard, booting, etc) to boot. > > :I'm convinced these "misrouted interrupts" are sourcing from the boot > :interrupt functionality. You don't route interrupts in APIC mode; its a > :flat space. All of the APIC entries stack together as if they were one > :gigantic IOAPIC that every PCI device's INTx lines were attached to. This > :is the System Interrupts model described in the ACPI specification. > : > :-- > :Doug White | FreeBSD: The Power to Serve > :dwhite@gumbysoft.com | www.FreeBSD.org > > You do route interrupts in APIC mode. I wish it were a flat space! It > isn't. > > I think you are forgetting a couple of things here: > > * PCI busses only have 4 interrupt lines (A, B, C, and D). > > * Motherboards often have anywhere from 3 to 6 PCI or PCI-like busses, > connected to the APICs via bridge chips. > > * The bridge chips have a limited number of IRQ pins. > > * Sometimes you have several bridges connected to another bridge > before it gets to the APIC. > > So the answer is... regardless of the capabilities of the APIC(s) > devices still often have limited choices that require IRQ sharing > simply due to the PCI BUS and BRIDGE configuration of the motherboard. > > But even more to the point, BIOSes (ACPI, etc.) often get really > confused about routing IRQs through bridges. They will for example > believe that two devices that share a *PHYSICAL* IRQ line through a > bridge are capable of being assigned different IRQs when, in fact, > they aren't. They will get confused about how some of the PCI IRQ > lines are routed to the bridges (so line 'B' on PCI bus #1 might be > misconfigured, for example). All sorts of bad things can happen. > > The only way for an operating system to figure this stuff out on its > own is to understand the umpteen different bridge chips out there, > test physical interrupt sources (which is not always possible) to see > how they are actually routed, and ignore the BIOS completely. One of the design goals of the APIC and PIC routing is to make it honor the user-selected routing that comes from the BIOS. There are a number of BIOSes that allow the user to chose which INTx line will be routed to a particular PCI slot or embedded device. It would be a big POLA problem to ignore these hints and route purely based on what we think is right. The problem here is that certain Intel chipsets. and maybe others, have a special compatibility mode for routing interrupts in a way that is easy for Option ROM and DOS drivers to deal with. It's called the 'boot interrupt' according to the Intel docs. We need to fully understand how this works so we can deal with it correctly. That is the point of the thread. We already know how the MP specs and ACPI specs work with regard to traditional interrupt routing. > > Wasn't it something like NetBSD or OpenBSD that was thinking about > doing that? Not trying to figure out the routing but instead just > figure out which vector was being asserted for a device? I'm beginning > to think that that may be the ONLY solution. > > Intel really screwed up big time. Motorola had a much, much, MUCH > better mechanism where the actual devices generated the actual vector > number on the interrupt bus and the only thing you might have hardwired > would have been the IPL. But Intel doesn't work that way. Their stuff > is just totally screwed when it comes to handling interrupts. It's > completely 100% guarenteed pungent crapola to anyone who has ever > built hardware with a *REAL* interrupt subsystem. See also: sbus(4), msi(4). MSI is something that I'd like to work on, but simply had the time. It's not a panacea since it will only work for MSI-enabled PCI devices, but many peripherals found on these Intel systems fall into that category. Scott From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 06:28:58 2005 Return-Path: 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 D9BF816A4CE for ; Mon, 11 Apr 2005 06:28:58 +0000 (GMT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B09E843D3F for ; Mon, 11 Apr 2005 06:28:58 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) j3B6Sw0e048328; Sun, 10 Apr 2005 23:28:58 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id j3B6Sw3m048327; Sun, 10 Apr 2005 23:28:58 -0700 (PDT) (envelope-from dillon) Date: Sun, 10 Apr 2005 23:28:58 -0700 (PDT) From: Matthew Dillon Message-Id: <200504110628.j3B6Sw3m048327@apollo.backplane.com> To: Scott Long References: <20050406233405.O47071@carver.gumbysoft.com> <200504081656.51917.jhb@FreeBSD.org> <20050410152946.W82708@carver.gumbysoft.com> <20050410172818.D82708@carver.gumbysoft.com> <200504110231.j3B2VOYr047361@apollo.backplane.com> <425A10DD.70500@samsco.org> cc: freebsd-current@freebsd.org Subject: Re: Potential source of interrupt aliasing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 06:28:59 -0000 Sheesh Scott, you don't have to be nasty about it. I'm just trying to help. I've seen billions of interrupt routing related problems but not one interrupt aliasing issue. What I/O APIC chipset and stepping does Doug have on that motherboard? Intel has a ton of errata for their I/O APICs. I see a mention of having to turn off earlier revs of the chip and revert to legacy 'boot interrupt' operation, but that's the only mention I see, and it's only for old versions (< B-0 stepping) of the 80332. Still, perhaps the BIOS is doing this even with later revs of the chip in the MB. There's a reference to the '80332 I/O Processor' developers manual which implies a more detailed explanation of 'boot interrupt' operation. http://www.intel.com/design/iio/specupdt/27392703.pdf -Matt From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 06:54:30 2005 Return-Path: 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 365C116A4CE for ; Mon, 11 Apr 2005 06:54:30 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7334D43D31 for ; Mon, 11 Apr 2005 06:54:27 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j3B6vwci028857; Mon, 11 Apr 2005 00:57:59 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <425A1E67.1050501@samsco.org> Date: Mon, 11 Apr 2005 00:51:19 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Dillon References: <20050406233405.O47071@carver.gumbysoft.com> <200504081656.51917.jhb@FreeBSD.org> <20050410152946.W82708@carver.gumbysoft.com> <20050410172818.D82708@carver.gumbysoft.com> <200504110231.j3B2VOYr047361@apollo.backplane.com> <425A10DD.70500@samsco.org> <200504110628.j3B6Sw3m048327@apollo.backplane.com> In-Reply-To: <200504110628.j3B6Sw3m048327@apollo.backplane.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 Subject: Re: Potential source of interrupt aliasing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 06:54:30 -0000 Matthew Dillon wrote: > Sheesh Scott, you don't have to be nasty about it. I'm just trying to > help. I've seen billions of interrupt routing related problems but > not one interrupt aliasing issue. Yes, uncalled for, please accept my apologies. Definitely a case of hitting the Send button too soon. > > What I/O APIC chipset and stepping does Doug have on that motherboard? > Intel has a ton of errata for their I/O APICs. I see a mention of > having to turn off earlier revs of the chip and revert to legacy > 'boot interrupt' operation, but that's the only mention I see, > and it's only for old versions (< B-0 stepping) of the 80332. > > Still, perhaps the BIOS is doing this even with later revs of the chip > in the MB. This is the motherboard chipset, mainly i7501, 7520, and 440GX (not so sure on the last one since that doesn't involve hardware I own). The 7520 documents a register to turn off the 'boot interrupt' routing, but the 7501 doesn't. Since it might be a more general problem, we want to figure out a general way to handle it. It only happens on FreeBSD 5.x/6.x with the full IOAPIC handling (there are 3 IOAPICs on the 7501 and 7520). 4.x (and presumably DFly) doesn't see it because it doesn't enable more than the first IOAPIC. In fact, what allows routing to work at all on 4.x is that the interrupts on the second and third APICs are masked by default in the IOAPIC and magically re-routed to irq16 on the first via this 'boot interrupt' feature. I have no idea how this applies to non-Intel chipsets with more than one IOAPIC, like the ServerWorks GC series. It doesn't appear to be a problem on Opteron chipsets, but that might be a whole different ball of wax. An interesting datapoint is that Linux RH9 and FC2 don't seem to have any aliasing issues on the same exact hardware. Or, maybe they lie very well about it. So either they know the secret handshake with the chipset, or they don't mask at the APIC while the interrupt is being serviced (which is very hard for FreeBSD to emulate because interrupts are handled in ithreads). Just to review, the sequence of events: - ahd fires irq50 - low-level handler runs - vector decoded - ahd ithread scheduled - EOI - write the mask to the APIC for irq50 - source is masked, boot interrupt feature activated in chipset - irq50 remains asserted, so is aliased to irq16 (uhci) - low-level handler runs - vector decoded - uhci ithread scheduled - EOI - write the mask to the APIC for irq16 -- time passes -- - ahd ithread runs - quench ahd hardware - irq50 de-asserted - irq16 also de-asserted by association - ithread completes - irq50 unmasked in the APIC -- time passes -- - uhci ithread runs - nothing to quench - ithread completes - irq16 unmasked in the APIC - repeat > > There's a reference to the '80332 I/O Processor' developers manual which > implies a more detailed explanation of 'boot interrupt' operation. Since the 80331 and 80332 include a PCI bridge, it wouldn't surprise me that there is a similar mechanism at work in them. But again, we are only talking about Intel motherboard chipsets here, not IOPs. Scott From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 06:58:02 2005 Return-Path: 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 B297A16A4D4 for ; Mon, 11 Apr 2005 06:58:02 +0000 (GMT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80E3943D45 for ; Mon, 11 Apr 2005 06:58:02 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) j3B6w20e048553; Sun, 10 Apr 2005 23:58:02 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id j3B6w2nb048552; Sun, 10 Apr 2005 23:58:02 -0700 (PDT) (envelope-from dillon) Date: Sun, 10 Apr 2005 23:58:02 -0700 (PDT) From: Matthew Dillon Message-Id: <200504110658.j3B6w2nb048552@apollo.backplane.com> To: Scott Long , Doug White , freebsd-current@freebsd.org References: <20050406233405.O47071@carver.gumbysoft.com> <200504081656.51917.jhb@FreeBSD.org> <20050410152946.W82708@carver.gumbysoft.com> <20050410172818.D82708@carver.gumbysoft.com> <200504110231.j3B2VOYr047361@apollo.backplane.com> <425A10DD.70500@samsco.org> Subject: Re: Potential source of interrupt aliasing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 06:58:02 -0000 Hmm. I can think of two solutions that avoid masking: * Change the trigger mode from level to edge as a means of masking the interrupt, then change it back to level triggered to unmask. This would be done in the IO APIC. * Change the delivery mode to low-priority for the interrupt that occured and use the priority field to mask the interrupt to the cpu. This would be done in the IO APIC with the LAPIC's TPR set appropriately. These are off-the-cuff ideas. I don't know how easy or hard it would be to implement (yet). But, certainly, changing the trigger mode can't be any more complicated then messing around with the mask. -Matt From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 07:11:59 2005 Return-Path: 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 7E01016A4CE for ; Mon, 11 Apr 2005 07:11:59 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id E22EB43D4C for ; Mon, 11 Apr 2005 07:11:58 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j3B7FU8p028935; Mon, 11 Apr 2005 01:15:30 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <425A2283.7040405@samsco.org> Date: Mon, 11 Apr 2005 01:08:51 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Dillon References: <20050406233405.O47071@carver.gumbysoft.com> <200504081656.51917.jhb@FreeBSD.org> <20050410152946.W82708@carver.gumbysoft.com> <20050410172818.D82708@carver.gumbysoft.com> <200504110231.j3B2VOYr047361@apollo.backplane.com> <425A10DD.70500@samsco.org> <200504110658.j3B6w2nb048552@apollo.backplane.com> In-Reply-To: <200504110658.j3B6w2nb048552@apollo.backplane.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 Subject: Re: Potential source of interrupt aliasing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 07:11:59 -0000 Matthew Dillon wrote: > Hmm. I can think of two solutions that avoid masking: > > * Change the trigger mode from level to edge as a means of masking the > interrupt, then change it back to level triggered to unmask. This > would be done in the IO APIC. > > * Change the delivery mode to low-priority for the interrupt that occured > and use the priority field to mask the interrupt to the cpu. This > would be done in the IO APIC with the LAPIC's TPR set appropriately. > > These are off-the-cuff ideas. I don't know how easy or hard it would be > to implement (yet). But, certainly, changing the trigger mode can't be > any more complicated then messing around with the mask. > > -Matt This is a place where two-level interrupt handling like in Mac OSX starts looking attractive. You have the driver quench the source right away in what is basically a fast interrupt handler, then you have an ithread come along later and process the data. I somewhat approximate this with the AAC driver, though I use a taskqueue instead of an ithread. There are definite trade-offs here; sometimes the only way to quench the hardware is to dequeue a status byte that is needed for later data processing. Queueing up this data byte to an ithread, and accounting that there might be more interrupts before the ithread runs, is ugly. Btw, AAC doesn't exhibit aliasing problems in the chipsets that I mentioned precisely because we don't mask the IOAPIC for fast handlers. Unfortunetaly, moving the entire OS to this scheme is quite labor-intensive. It would make just as much sense to implement MSI infrastructre and convert a number of drivers to that. And again, Linux seems immune to this problem, so it's very intriguing to find out why. Scott From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 07:15:33 2005 Return-Path: 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 6F38716A4CE for ; Mon, 11 Apr 2005 07:15:33 +0000 (GMT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41E8A43D48 for ; Mon, 11 Apr 2005 07:15:33 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) j3B7FX0e048669; Mon, 11 Apr 2005 00:15:33 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id j3B7FXVK048668; Mon, 11 Apr 2005 00:15:33 -0700 (PDT) (envelope-from dillon) Date: Mon, 11 Apr 2005 00:15:33 -0700 (PDT) From: Matthew Dillon Message-Id: <200504110715.j3B7FXVK048668@apollo.backplane.com> To: Scott Long , Doug White , freebsd-current@freebsd.org References: <20050406233405.O47071@carver.gumbysoft.com> <200504081656.51917.jhb@FreeBSD.org> <20050410152946.W82708@carver.gumbysoft.com> <20050410172818.D82708@carver.gumbysoft.com> <200504110231.j3B2VOYr047361@apollo.backplane.com> <425A10DD.70500@samsco.org> Subject: Re: Potential source of interrupt aliasing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 07:15:33 -0000 : Hmm. I can think of two solutions that avoid masking: : : * Change the trigger mode from level to edge as a means of masking the : interrupt, then change it back to level triggered to unmask. This : would be done in the IO APIC. : : * Change the delivery mode to low-priority for the interrupt that occured : and use the priority field to mask the interrupt to the cpu. This : would be done in the IO APIC with the LAPIC's TPR set appropriately. Here's a third... mess with the IOART_DEST mask for the pin on the IOAPIC. Can it be set to not route the interrupt to *any* cpu ? Usually it's set to broadcast (all bits 1, at least on 4.x and DragonFly). so. e.g. IOART_DESTPHY but then with no cpu specified in IOART_DEST. -Matt Matthew Dillon From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 07:19:28 2005 Return-Path: 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 7A5F116A520 for ; Mon, 11 Apr 2005 07:19:26 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 758A643D53 for ; Mon, 11 Apr 2005 07:19:25 +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 j3B7LMTP039015; Mon, 11 Apr 2005 10:21: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 73684-16; Mon, 11 Apr 2005 10:24:33 +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 j3B7LLAl039012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Apr 2005 10:21: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 j3B7JNPN093283; Mon, 11 Apr 2005 10:19:23 +0300 (EEST) (envelope-from ru) Date: Mon, 11 Apr 2005 10:19:23 +0300 From: Ruslan Ermilov To: Rob Message-ID: <20050411071923.GA93265@ip.net.ua> References: <20050411041644.23794.qmail@web54005.mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BXVAT5kNtrzKuDFl" Content-Disposition: inline In-Reply-To: <20050411041644.23794.qmail@web54005.mail.yahoo.com> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: FreeBSD current Subject: Re: xl(4) & polling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 07:19:28 -0000 --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 10, 2005 at 09:16:44PM -0700, Rob wrote: >=20 > --- Ruslan Ermilov wrote: > > On Sat, Apr 09, 2005 at 06:54:20PM -0700, Rob wrote: > >> PS: if this makes it into the official sources, > >> then don't forget to also add xl(4) to the > >> polling(4) manpage. > >=20 > > It did (last month). The manpage was also updated. >=20 > Will it also go into RELENG_5, after the 5.4 release? >=20 Yes, probably. After I hear more reports of success. The HEAD sources can be used on RELENG_5 to test the functionality. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --BXVAT5kNtrzKuDFl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCWiT6qRfpzJluFF4RAiHEAJ0SCJ5C082fJNZokZYnbf7ev73pWgCfQyy9 wX/4StfaPjcDStyFgfSwjMQ= =0sRA -----END PGP SIGNATURE----- --BXVAT5kNtrzKuDFl-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 07:30:59 2005 Return-Path: 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 D33FA16A4CF for ; Mon, 11 Apr 2005 07:30:59 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id F408443D31 for ; Mon, 11 Apr 2005 07:30:57 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id D5423AC976; Mon, 11 Apr 2005 09:30:42 +0200 (CEST) Date: Mon, 11 Apr 2005 09:30:42 +0200 From: Pawel Jakub Dawidek To: Daniel Eriksson Message-ID: <20050411073042.GI837@darkness.comp.waw.pl> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eHOIV5BfioPmIRHC" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: 'FreeBSD Current' Subject: Re: ggate and mmap, possible problem? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 07:31:00 -0000 --eHOIV5BfioPmIRHC Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 11, 2005 at 04:49:16AM +0200, Daniel Eriksson wrote: +>=20 +> Hi! Is it possible that there is some sort of problem using mmap on a (U= FS2) +> filesystem mounted over ggate? +>=20 +> I keep getting errors on the console when I enable mmap on a server runn= ing +> a proprietary video server application (which is a binary compiled on FB= SD +> 4.11 afaik). I don't have access to the source code for the server app +> unfortunately (but I do have some access to the developers). I'm pretty = sure +> that with mmap enabled in the server, it tries to mmap all files smaller +> than 50MB (most are 20-50MB). +>=20 +> The errors look like this: +>=20 +> g_vfs_done():ggate0[READ(offset=3D-1009882480640, length=3D65536)]error = =3D 5 +> vnode_pager_getpages: I/O read error +> vm_fault: pager read error, pid 1527 (mcvidserv) +>=20 +>=20 +> This could certainly be a problem in the proprietary server, but I thoug= ht +> I'd ask here too. This is on a recent 6-CURRENT system. I don't think it is related to mmap(2), it may be caused by timeouts. Can you increase debug level to 1 (kern.geom.gate.debug=3D1) and see if it prints anything new on console? --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --eHOIV5BfioPmIRHC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFCWieiForvXbEpPzQRAkVyAKCSZdVh9JQ8egfG8TXyJILXBim7MACgj0fH H3WcK00SWkwMzCX+9Zs1rQo= =T2xZ -----END PGP SIGNATURE----- --eHOIV5BfioPmIRHC-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 07:31:56 2005 Return-Path: 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 DBA6B16A4CE for ; Mon, 11 Apr 2005 07:31:55 +0000 (GMT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 88A6943D49 for ; Mon, 11 Apr 2005 07:31:55 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) j3B7Vt0e048806; Mon, 11 Apr 2005 00:31:55 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id j3B7VtPv048805; Mon, 11 Apr 2005 00:31:55 -0700 (PDT) (envelope-from dillon) Date: Mon, 11 Apr 2005 00:31:55 -0700 (PDT) From: Matthew Dillon Message-Id: <200504110731.j3B7VtPv048805@apollo.backplane.com> To: Scott Long References: <20050406233405.O47071@carver.gumbysoft.com> <200504081656.51917.jhb@FreeBSD.org> <20050410152946.W82708@carver.gumbysoft.com> <20050410172818.D82708@carver.gumbysoft.com> <200504110231.j3B2VOYr047361@apollo.backplane.com> <425A10DD.70500@samsco.org> <200504110658.j3B6w2nb048552@apollo.backplane.com> <425A2283.7040405@samsco.org> cc: freebsd-current@freebsd.org Subject: Re: Potential source of interrupt aliasing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 07:31:56 -0000 :... :that I mentioned precisely because we don't mask the IOAPIC for fast :handlers. Unfortunetaly, moving the entire OS to this scheme is :quite labor-intensive. It would make just as much sense to implement :MSI infrastructre and convert a number of drivers to that. And again, :Linux seems immune to this problem, so it's very intriguing to find out :why. : :Scott kernel/io_apic.c line 1829ish (linux 2.6.9). And the whole file in general. It appears that they simply do not EOI the APIC when handling a level triggered interrupt until after the interrupt handler has run. And indeed, that is what appears to happen. It looks like they may still be vulnerable due to the way they shutdown an interrupt (but by them the device is presumably not asserting interrupts any more). But for normal interrupt operation they simply do not EOI the APIC. I love the last sentence of this comment... OMG! They have got to be kidding. [ comment from linux source ]: /* * Level triggered interrupts can just be masked, * and shutting down and starting up the interrupt * is the same as enabling and disabling them -- except * with a startup need to return a "was pending" value. * * Level triggered interrupts are special because we * do not touch any IO-APIC register while handling * them. We ack the APIC in the end-IRQ handler, not * in the start-IRQ-handler. Protection against reentrance * from the same interrupt is still provided, both by the * generic IRQ layer and by the fact that an unacked local * APIC does not accept IRQs. */ They also have a workaround for various errata which is even nastier... it's just after that comment. It looks like they change the trigger mode to edge triggered then change it back to level after the edge-trigger occurs when they detect the chip errata's condition. -Matt Matthew Dillon [ more comments from the linux code ]: /* * It appears there is an erratum which affects at least version 0x11 * of I/O APIC (that's the 82093AA and cores integrated into various * chipsets). Under certain conditions a level-triggered interrupt is * erroneously delivered as edge-triggered one but the respective IRR * bit gets set nevertheless. As a result the I/O unit expects an EOI * message but it will never arrive and further interrupts are blocked * from the source. The exact reason is so far unknown, but the * phenomenon was observed when two consecutive interrupt requests * from a given source get delivered to the same CPU and the source is * temporarily disabled in between. * * A workaround is to simulate an EOI message manually. We achieve it * by setting the trigger mode to edge and then to level when the edge * trigger mode gets detected in the TMR of a local APIC for a * level-triggered interrupt. We mask the source for the time of the * operation to prevent an edge-triggered interrupt escaping meanwhile. * The idea is from Manfred Spraul. --macro */ From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 07:33:22 2005 Return-Path: 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 C459D16A4CE for ; Mon, 11 Apr 2005 07:33:22 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id DDBE643D3F for ; Mon, 11 Apr 2005 07:33:21 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id DD499ACC47; Mon, 11 Apr 2005 09:33:17 +0200 (CEST) Date: Mon, 11 Apr 2005 09:33:17 +0200 From: Pawel Jakub Dawidek To: Daniel Eriksson Message-ID: <20050411073317.GJ837@darkness.comp.waw.pl> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Y4Sc2lTxFPaHyX/6" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: 'FreeBSD Current' Subject: Re: ggate and mmap, possible problem? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 07:33:22 -0000 --Y4Sc2lTxFPaHyX/6 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 11, 2005 at 04:49:16AM +0200, Daniel Eriksson wrote: +>=20 +> Hi! Is it possible that there is some sort of problem using mmap on a (U= FS2) +> filesystem mounted over ggate? +>=20 +> I keep getting errors on the console when I enable mmap on a server runn= ing +> a proprietary video server application (which is a binary compiled on FB= SD +> 4.11 afaik). I don't have access to the source code for the server app +> unfortunately (but I do have some access to the developers). I'm pretty = sure +> that with mmap enabled in the server, it tries to mmap all files smaller +> than 50MB (most are 20-50MB). +>=20 +> The errors look like this: +>=20 +> g_vfs_done():ggate0[READ(offset=3D-1009882480640, length=3D65536)]error = =3D 5 +> vnode_pager_getpages: I/O read error +> vm_fault: pager read error, pid 1527 (mcvidserv) +>=20 +>=20 +> This could certainly be a problem in the proprietary server, but I thoug= ht +> I'd ask here too. This is on a recent 6-CURRENT system. I didn't look close enough at your log. You have negative offset! Could you give me 'uname -a' from the client and from the server? --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --Y4Sc2lTxFPaHyX/6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFCWig9ForvXbEpPzQRAv2FAKDg9UiZnlrcHRI6IhJMZT+gT5D3SACfa0xe CocV/wxuGnFnplE0Apa1uz8= =ttvj -----END PGP SIGNATURE----- --Y4Sc2lTxFPaHyX/6-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 07:53:49 2005 Return-Path: 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 0F88C16A4CE for ; Mon, 11 Apr 2005 07:53:49 +0000 (GMT) Received: from mail.next-computer.ro (mail.next-computer.ro [217.156.22.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8149943D2D for ; Mon, 11 Apr 2005 07:53:48 +0000 (GMT) (envelope-from cristian@mail.next-computer.ro) Received: by mail.next-computer.ro (Postfix, from userid 99) id EE75924608; Mon, 11 Apr 2005 11:01:42 +0300 (EEST) Received: from mail.next-computer.ro (mail.next-computer.ro [127.0.0.1]) by mail.next-computer.ro (Postfix) with ESMTP id 78E97237B8 for ; Mon, 11 Apr 2005 11:01:30 +0300 (EEST) Received: from inferno.next-computer.ro (smd.next-computer.ro [217.156.22.45]) by mail.next-computer.ro (AvMailGate-2.0.2-5) id 03040-225E6592; Mon, 11 Apr 2005 11:01:30 +0300 From: Man Cristian Organization: Next Computer STL To: freebsd-current@freebsd.org Date: Mon, 11 Apr 2005 10:54:17 +0000 User-Agent: KMail/1.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504111054.18746.cristian@mail.next-computer.ro> X-AntiVirus: checked by AntiVir MailGate (version: 2.0.2-5; AVE: 6.30.0.7; VDF: 6.30.0.81; host: mail.next-computer.ro) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on mail.next-computer.ro X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.1 Subject: kernel update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 07:53:49 -0000 Hello From where i can download a new version of FreeBDS 6.0 kernel ? Tka From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 08:07:33 2005 Return-Path: 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 8875916A4CE for ; Mon, 11 Apr 2005 08:07:33 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.194.102.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id EDD6143D1D for ; Mon, 11 Apr 2005 08:07:32 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id CD90951516; Mon, 11 Apr 2005 01:07:31 -0700 (PDT) Date: Mon, 11 Apr 2005 01:07:31 -0700 From: Kris Kennaway To: Man Cristian Message-ID: <20050411080731.GA88196@xor.obsecurity.org> References: <200504111054.18746.cristian@mail.next-computer.ro> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UugvWAfsgieZRqgk" Content-Disposition: inline In-Reply-To: <200504111054.18746.cristian@mail.next-computer.ro> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org Subject: Re: kernel update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 08:07:33 -0000 --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Apr 11, 2005 at 10:54:17AM +0000, Man Cristian wrote: > Hello > From where i can download a new version of FreeBDS 6.0 kernel ? It's explained in detail on www.freebsd.org how to obtain copies of FreeBSD. Please read it, and if you have specific questions then follow up on questions@FreeBSD.org. Kris --UugvWAfsgieZRqgk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCWjBDWry0BWjoQKURAqBoAKCQLqNf7fvdIZZZTEr92NjXI+l7GACglCMq YJnnfnCVT1S/bj4XBDitJCM= =baty -----END PGP SIGNATURE----- --UugvWAfsgieZRqgk-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 08:30:14 2005 Return-Path: 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 2DB3716A4CE for ; Mon, 11 Apr 2005 08:30:14 +0000 (GMT) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FD1743D45 for ; Mon, 11 Apr 2005 08:30:13 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j3B8U7AG009478 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 11 Apr 2005 18:30:07 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j3B8U67l097817; Mon, 11 Apr 2005 18:30:06 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j3B8U6nu097816; Mon, 11 Apr 2005 18:30:06 +1000 (EST) (envelope-from pjeremy) Date: Mon, 11 Apr 2005 18:30:06 +1000 From: Peter Jeremy To: Matthew Dillon Message-ID: <20050411083006.GJ89047@cirb503493.alcatel.com.au> References: <20050406233405.O47071@carver.gumbysoft.com> <200504081656.51917.jhb@FreeBSD.org> <20050410152946.W82708@carver.gumbysoft.com> <20050410172818.D82708@carver.gumbysoft.com> <200504110231.j3B2VOYr047361@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504110231.j3B2VOYr047361@apollo.backplane.com> User-Agent: Mutt/1.4.2i cc: freebsd-current@freebsd.org Subject: Re: Potential source of interrupt aliasing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 08:30:14 -0000 On Sun, 2005-Apr-10 19:31:24 -0700, Matthew Dillon wrote: > The only way for an operating system to figure this stuff out on its > own is to understand the umpteen different bridge chips out there, > test physical interrupt sources (which is not always possible) to see > how they are actually routed, and ignore the BIOS completely. ISTR the old ISA probes for things like sio would raise an interrupt in the 16[45]50 and see what IRQ appeared. Given a plethora of bridges, this becomes more difficult if you can't trust that the BIOS has done anything right (like even routing the interrupt from source to an upstream interrupt controller). Presumably, these motherboards run Winbloze. And I understand that Winbloze uses interrupts, so presumably interrupt routing stuffups will break Winbloze just as badly as *BSD or Linux. What is Winbloze doing differently to work around broken BIOSes? > Intel really screwed up big time. Motorola had a much, much, MUCH > better mechanism where the actual devices generated the actual vector > number on the interrupt bus and the only thing you might have hardwired > would have been the IPL. But Intel doesn't work that way. Their stuff > is just totally screwed when it comes to handling interrupts. It's > completely 100% guarenteed pungent crapola to anyone who has ever > built hardware with a *REAL* interrupt subsystem. I'm as big a fan of Intel as you are but I don't think the problem here is Intel. I do agree that interrupt handling in the PC is stuffed - designing active-high interrupts using hardware that would automatically support wired-or of active-low interrupts suggests that someone in IBM had either done their tie up far too tight or had been over-indulging in recreational substances. Both the 8080 and 8085 supported vectored interrupts to a limited extent. The 6800 and 6809 don't support vectored interrupts. The Z-80, 68000 and 8086 all fully support vectored interrupts. But the Z-80 and 68000 both need the designer to (exclusively) use the Z-80 or 68000 peripheral chips in order to take advantage of their vectored interrupts. Using a separate interrupt controller means that you can use bog-standard peripherals that just have INTR outputs. It's a pity that the modern PC is hamstrung by design decisions made over 25 years ago. -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 08:42:27 2005 Return-Path: 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 074DD16A4CE for ; Mon, 11 Apr 2005 08:42:27 +0000 (GMT) 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 4ED6443D2D for ; Mon, 11 Apr 2005 08:42:26 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [172.18.2.1] (axiell-gw1.novi.dk [130.225.63.24]) by spider.deepcore.dk (8.13.3/8.13.3) with ESMTP id j3B8gN8S028356; Mon, 11 Apr 2005 10:42:24 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <425A380D.5030400@DeepCore.dk> Date: Mon, 11 Apr 2005 10:40:45 +0200 From: =?ISO-8859-15?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Reifenberger References: <20050410164959.G38200@fw.reifenberger.com> <42597A6D.8080801@DeepCore.dk> <20050410212444.H25065@fw.reifenberger.com> In-Reply-To: <20050410212444.H25065@fw.reifenberger.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable X-mail-scanned: by DeepCore Virus & Spam killer v1.12 cc: FreeBSD-Current Subject: Re: SATA with new ata code doesn't work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 08:42:27 -0000 Michael Reifenberger wrote: > On Sun, 10 Apr 2005, [ISO-8859-1] S=F8ren Schmidt wrote: > ... >=20 >>> Is this a known problem? >> >> >> Yes, the problem is that the alloc_resource fails on the last resource= =20 >> (0xb4000-0xb4ff) for some unknown reason. >> I've given up finding this remotely and have ordered a VIA based=20 >> motherboard that I'm picking up tomorrow, then I'm sure I can have fix= =20 >> ready soon... >> Warner has committed an update to the PCI code, could you please try it=20 out and get back to me we the result ? --=20 -S=F8ren From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 08:45:13 2005 Return-Path: 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 158EE16A4CE; Mon, 11 Apr 2005 08:45:13 +0000 (GMT) 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 4390043D2D; Mon, 11 Apr 2005 08:45:12 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [172.18.2.1] (axiell-gw1.novi.dk [130.225.63.24]) by spider.deepcore.dk (8.13.3/8.13.3) with ESMTP id j3B8j8pO028412; Mon, 11 Apr 2005 10:45:09 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <425A38B2.8010103@DeepCore.dk> Date: Mon, 11 Apr 2005 10:43:30 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gary Jennejohn References: <200504090923.j399NgxV000774@peedub.jennejohn.org> In-Reply-To: <200504090923.j399NgxV000774@peedub.jennejohn.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-mail-scanned: by DeepCore Virus & Spam killer v1.12 cc: freebsd-current@FreeBSD.ORG cc: sos@FreeBSD.ORG Subject: Re: SATA PHY commit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 08:45:13 -0000 Gary Jennejohn wrote: > WIth the SATA PHY commit my SATA drives are not found anymore, the PATA= > devices are still OK. >=20 > Here snippets from a failed boot -v: >=20 > atapci0: port 0xc000-0xc007,0xb800-0xb803= , > 0xb400-0 xb407,0xb000-0xb003,0xa800-0xa80f,0xa400-0xa4ff irq 20 at devi= ce > 15.0 on pci0 > atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xa800 > atapci0: [MPSAFE] > ata2: on atapci0 > device_attach: ata2 attach returned 6 > ata3: on atapci0 > device_attach: ata3 attach returned 6 Could you please try again with the changes Warner has committed to=20 dev/pci/pci.c and get back to me with the result, thanks! --=20 -S=F8ren From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 08:55:55 2005 Return-Path: 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 41A4A16A4CE; Mon, 11 Apr 2005 08:55:55 +0000 (GMT) Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9CEF43D1D; Mon, 11 Apr 2005 08:55:54 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: from sentinel (195.198.193.104) by pne-smtpout2-sn2.hy.skanova.net (7.1.026.7) id 41E3223E00AF8186; Mon, 11 Apr 2005 10:55:53 +0200 From: "Daniel Eriksson" To: "'Pawel Jakub Dawidek'" Date: Mon, 11 Apr 2005 10:55:50 +0200 Organization: Home Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <20050411073317.GJ837@darkness.comp.waw.pl> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcU+aMfTOu/gUyopT0GNM1sOfN0B3gACzhcg cc: 'FreeBSD Current' Subject: RE: ggate and mmap, possible problem? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 08:55:55 -0000 Pawel Jakub Dawidek wrote: > I didn't look close enough at your log. > You have negative offset! Could you give me 'uname -a' from > the client and > from the server? Both server and client are running 6-CURRENT compiled from sources dated 2005.04.08.04.00.00. /Daniel Eriksson From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 09:21:26 2005 Return-Path: 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 453D916A4CE; Mon, 11 Apr 2005 09:21:26 +0000 (GMT) Received: from av4-1-sn3.vrr.skanova.net (av4-1-sn3.vrr.skanova.net [81.228.9.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9812E43D1F; Mon, 11 Apr 2005 09:21:25 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: by av4-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 7141037E64; Mon, 11 Apr 2005 11:21:24 +0200 (CEST) Received: from smtp1-1-sn3.vrr.skanova.net (smtp1-1-sn3.vrr.skanova.net [81.228.9.177]) by av4-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 5EDBD37E45; Mon, 11 Apr 2005 11:21:24 +0200 (CEST) Received: from sentinel (h104n1-gl-a-d4.ias.bredband.telia.com [195.198.193.104]) by smtp1-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 23CA03800A; Mon, 11 Apr 2005 11:21:24 +0200 (CEST) From: "Daniel Eriksson" To: "'Pawel Jakub Dawidek'" Date: Mon, 11 Apr 2005 11:21:19 +0200 Organization: Home Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcU+aKSpBSofk/usR2+niH60Lb0W8AADpuYg In-Reply-To: <20050411073042.GI837@darkness.comp.waw.pl> cc: 'FreeBSD Current' Subject: RE: ggate and mmap, possible problem? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 09:21:26 -0000 Pawel Jakub Dawidek wrote: > I don't think it is related to mmap(2), it may be caused by timeouts. > Can you increase debug level to 1 (kern.geom.gate.debug=1) and see if > it prints anything new on console? No additional output at all on the client. At least not when kern.geom.gate.debug=1 is set during runtime (with already existing ggate providers / mounted filesystems). The error message stays the same. /Daniel Eriksson From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 09:34:03 2005 Return-Path: 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 74FE616A4CE for ; Mon, 11 Apr 2005 09:34:03 +0000 (GMT) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id F048043D39 for ; Mon, 11 Apr 2005 09:34:02 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1DKvIv-0008eB-RO; Mon, 11 Apr 2005 12:34:01 +0300 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: Peter Jeremy In-reply-to: Your message of Mon, 11 Apr 2005 18:30:06 +1000 . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 11 Apr 2005 12:34:01 +0300 From: Danny Braniss Message-ID: cc: freebsd-current@freebsd.org Subject: Re: Potential source of interrupt aliasing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 09:34:03 -0000 ... > It's a pity that the modern PC is hamstrung by design decisions made > over 25 years ago. sorry, but couldn't help it :-) The US Standard railroad gauge (distance between the rails) is 4 feet, 8.5 inches. That's an exceedingly odd number. Why was that gauge used? Because that's the way they built them in England, and the US railroads were built by English expatriates. Why did the English people build them like that? Because the first rail lines were built by the same people who built the pre-railroad tramways, and that's the gauge they used. Why did "they" use that gauge then? Because the people who built the tramways used the same jigs and tools that they used for building wagons, which used that wheel spacing. Okay! Why did the wagons use that odd wheel spacing? Well, if they tried to use any other spacing the wagons would break on some of the old, long distance roads, because that's the spacing of the old wheel ruts. So who built these old rutted roads? The first long distance roads in Europe were built by Imperial Rome for the benefit of their legions. The roads have been used ever since. And the ruts? The initial ruts, which everyone else had to match for fear of destroying their wagons, were first made by Roman war chariots. Since the chariots were made for or by Imperial Rome they were all alike in the matter of wheel spacing. Thus, we have the answer to the original question. The United States standard railroad gauge of 4 feet, 8.5 inches derives from the original specification for an Imperial Roman army war chariot. Specs and Bureaucracies live forever. So, the next time you are handed a spec ification and wonder what horse's ass came up with it, you may be exactly right. Because the Imperial Roman chariots were made to be just wide enough to accommodate the back ends of two war horses. Now the twist to the story.... There's an interesting extension of the story about railroad gauge and horses' behinds. When we see a Space Shuttle sitting on the launch pad, there are two big booster rockets attached to the sides of the main fuel tank. These are the solid rocket boosters, or SRBs. The SRBs are made by Thiokol at a factory in Utah. The engineers who designed the SRBs might have preferred to make them a bit fatter, but the SRBs had to be shipped by train from the factory to the launch site. The railroad line to the factory runs through a tunnel in the mountains. The SRBs had to fit through that tunnel. The tunnel is slightly wider than a railroad track, and the railroad track is about as wide as two horses' behinds. So a major design feature of what is arguably the world's most advanced transportation system was determined by the width of a horse's ass! From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 09:35:12 2005 Return-Path: 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 3283F16A4CF for ; Mon, 11 Apr 2005 09:35:12 +0000 (GMT) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id D17C843D66 for ; Mon, 11 Apr 2005 09:35:10 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) (8.13.4/8.13.3) with ESMTP id j3B9Z7AZ014100 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 11 Apr 2005 11:35:07 +0200 (CEST) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.4/8.13.3/Submit) id j3B9Z7Q1014099 for current@freebsd.org; Mon, 11 Apr 2005 11:35:07 +0200 (CEST) Date: Mon, 11 Apr 2005 11:35:07 +0200 From: Divacky Roman To: current@freebsd.org Message-ID: <20050411093507.GA14060@stud.fit.vutbr.cz> References: <20050405095912.GA74416@stud.fit.vutbr.cz> <20050405101024.GA76053@stud.fit.vutbr.cz> <4252654C.5060402@DeepCore.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4252654C.5060402@DeepCore.dk> User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.49 on 147.229.10.14 Subject: [SOLVED] Re: SiS not working with atamkIII X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 09:35:12 -0000 this was my fault... I didnt have atadisk loaded ;( On Tue, Apr 05, 2005 at 12:15:40PM +0200, S?ren Schmidt wrote: > Divacky Roman wrote: > >additinoal info (hand rewritten from verbose dmesg): > >atamkIII: > >ata0: reset tp1 mask=03 ostat=50 ostat1=50 > >ata0: stat0=0x90 err=0x90 lsb=0x90 msb=0x90 > >ata0: stat0=0x90 err=0x90 lsb=0x90 msb=0x90 > >ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 > >ata0: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb > >ata0: reset tp2 stat=50 stat1=00 devices=0x9 (ATAPI_SLAVE,ATA_MASTER> > > > > > >old ata: > >atapci0: port > >0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0 > >xff00-0xff0f at device 2.5 on pci0 > >atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xff00 > >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=50 > >ata0-master: stat=0x90 err=0x90 lsb=0x90 msb=0x90 > >ata0-master: stat=0x90 err=0x90 lsb=0x90 msb=0x90 > >ata0-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 > >ata0-slave: stat=0x00 err=0x01 lsb=0x14 msb=0xeb > >ata0: reset tp2 stat0=50 stat1=00 devices=0x9 > > Hmm, from what I can see above both old and new find the exact same > devices: ATAPI_SLAVE,ATA_MASTER. > > What is it you miss ? > > -- > > -S?ren > > > _______________________________________________ > 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 Mon Apr 11 09:39:11 2005 Return-Path: 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 62ADC16A4CE for ; Mon, 11 Apr 2005 09:39:11 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.194.102.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2603243D48 for ; Mon, 11 Apr 2005 09:39:11 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 294925130F; Mon, 11 Apr 2005 02:39:08 -0700 (PDT) Date: Mon, 11 Apr 2005 02:39:08 -0700 From: Kris Kennaway To: Danny Braniss Message-ID: <20050411093907.GA19053@xor.obsecurity.org> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LQksG6bCIzRHxTLp" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i cc: Peter Jeremy cc: freebsd-current@freebsd.org Subject: Re: Potential source of interrupt aliasing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: crap@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: Mon, 11 Apr 2005 09:39:11 -0000 --LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 11, 2005 at 12:34:01PM +0300, Danny Braniss wrote: > ... > > It's a pity that the modern PC is hamstrung by design decisions made > > over 25 years ago. >=20 > sorry, but couldn't help it :-) >=20 > The US Standard railroad gauge (distance between the rails) is 4 > feet, 8.5 inches. That's an exceedingly odd number. Why was that > gauge used? Because that's the way they built them in England, > and the US railroads were built by English expatriates. [...] http://www.snopes.com/history/american/gauge.htm Kris --LQksG6bCIzRHxTLp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCWkW7Wry0BWjoQKURAjtEAJ474dzgDbT3G+ETG6OaRT8AplTb2ACg+jTD 03T29jDpWeAhajmTO4cVRko= =dkUe -----END PGP SIGNATURE----- --LQksG6bCIzRHxTLp-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 09:39:33 2005 Return-Path: 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 6180816A4CE for ; Mon, 11 Apr 2005 09:39:33 +0000 (GMT) Received: from smtp-vbr12.xs4all.nl (smtp-vbr12.xs4all.nl [194.109.24.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id BEE8343D45 for ; Mon, 11 Apr 2005 09:39:32 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) j3B9dDFT022702; Mon, 11 Apr 2005 11:39:15 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.13.3/8.12.9) with ESMTP id j3B9dCs6056247; Mon, 11 Apr 2005 11:39:12 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.13.3/8.13.1/Submit) id j3B9dCg6056246; Mon, 11 Apr 2005 11:39:12 +0200 (CEST) (envelope-from wb) Date: Mon, 11 Apr 2005 11:39:12 +0200 From: Wilko Bulte To: Danny Braniss Message-ID: <20050411093912.GE56099@freebie.xs4all.nl> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 4.11-STABLE User-Agent: Mutt/1.5.6i X-Virus-Scanned: by XS4ALL Virus Scanner cc: Peter Jeremy cc: freebsd-current@freebsd.org Subject: Re: Potential source of interrupt aliasing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 09:39:33 -0000 On Mon, Apr 11, 2005 at 12:34:01PM +0300, Danny Braniss wrote.. > ... > > It's a pity that the modern PC is hamstrung by design decisions made > > over 25 years ago. > > sorry, but couldn't help it :-) > > The US Standard railroad gauge (distance between the rails) is 4 > feet, 8.5 inches. That's an exceedingly odd number. Why was that > gauge used? Because that's the way they built them in England, > and the US railroads were built by English expatriates. > > Why did the English people build them like that? Why would any sane person continue to use inches, feet, stones, yards etc etc anyway? >:-) Wilko -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 10:12:50 2005 Return-Path: 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 92C1416A4CF; Mon, 11 Apr 2005 10:12:50 +0000 (GMT) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 609B343D1F; Mon, 11 Apr 2005 10:12:49 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) (8.13.4/8.13.3) with ESMTP id j3BACkIJ016430 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 11 Apr 2005 12:12:46 +0200 (CEST) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.4/8.13.3/Submit) id j3BACkox016429; Mon, 11 Apr 2005 12:12:46 +0200 (CEST) Date: Mon, 11 Apr 2005 12:12:46 +0200 From: Divacky Roman To: John Baldwin Message-ID: <20050411101246.GA15463@stud.fit.vutbr.cz> References: <20050406130909.GA90294@stud.fit.vutbr.cz> <200504081649.09705.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504081649.09705.jhb@FreeBSD.org> User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.49 on 147.229.10.14 cc: current@FreeBSD.org Subject: Re: slow kbd input on 6-current on amd64@nforce3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 10:12:50 -0000 On Fri, Apr 08, 2005 at 04:49:07PM -0400, John Baldwin wrote: > On Wednesday 06 April 2005 09:09 am, Divacky Roman wrote: > > as I have mentioned on the list I have very slow keyboard input. it might > > be related to kbd not having an IRQ assigned. I repeat once again that it > > worked on 5.3R. > > > > I include verbose dmesg + this piece which didnt get into dmesg (dont know > > why): > > Do you have a dmesg from 5.3 where the keyboard works? this should be it (taken by booting 5.3R kernel on 6-c userland with a script in rc.local, but that shouldnt affect kernel): I was not able to see wheter it works or not but when I boot freebsd 5.3R installcd and run fixit shell it works so I expect this is valid (ie. working) dmesg: AMD Features=0xe2500800,LM,3DNow+,3DNow> 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: 512 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative real memory = 268369920 (255 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000992000 - 0x000000000f83ffff, 250273792 bytes (61102 pages) avail memory = 248131584 (236 MB) APIC: CPU 0 has ACPI ID 0 MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 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: intr override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: high MADT: intr override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: high MADT: intr override: source 14, irq 14 ioapic0: intpin 14 trigger: edge ioapic0: intpin 14 polarity: high MADT: intr 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: active-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 wlan: <802.11 Link Layer> random: mem: io: null: acpi0: on motherboard acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x80004804 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=00e110de) AcpiOsDerivePciId: bus 0 dev 1 func 0 acpi0: Power Button (fixed) AcpiOsDerivePciId: bus 0 dev 1 func 0 ACPI timer looks GOOD min = 5, max = 6, width = 1 ACPI timer looks GOOD min = 5, max = 6, width = 1 ACPI timer looks GOOD min = 5, max = 6, width = 1 ACPI timer looks GOOD min = 5, max = 6, width = 1 ACPI timer looks GOOD min = 5, max = 6, width = 1 ACPI timer looks GOOD min = 5, max = 6, width = 1 ACPI timer looks GOOD min = 5, max = 6, width = 1 ACPI timer looks GOOD min = 5, max = 6, width = 1 ACPI timer looks GOOD min = 5, max = 6, width = 1 ACPI timer looks GOOD min = 5, max = 6, width = 1 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 unknown: not probed (disabled) cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf0-0xcf3,0xcf8-0xcff on acpi0 ACPI PCI link initial configuration: \\_SB_.PCI0.APCS irq 0: [20 21 22 23] 0+ high,level,sharable 0.1.0 \\_SB_.PCI0.APCS irq 0: [20 21 22 23] 0+ high,level,sharable 0.1.1 \\_SB_.PCI0.APCF irq 0: [20 21 22 23] 0+ high,level,sharable 0.2.0 \\_SB_.PCI0.APCG irq 0: [20 21 22 23] 0+ high,level,sharable 0.2.1 \\_SB_.PCI0.APCL irq 0: [20 21 22 23] 0+ high,level,sharable 0.2.2 \\_SB_.PCI0.APCH irq 0: [20 21 22 23] 0+ high,level,sharable 0.5.0 \\_SB_.PCI0.APCJ irq 0: [20 21 22 23] 0+ high,level,sharable 0.6.0 \\_SB_.PCI0.APCK irq 0: [20 21 22 23] 0+ high,level,sharable 0.6.1 \\_SB_.PCI0.APCZ irq 0: [20 21 22 23] 0+ high,level,sharable 0.8.0 \\_SB_.PCI0.APSI irq 0: [20 21 22 23] 0+ high,level,sharable 0.9.0 \\_SB_.PCI0.APSJ irq 0: [20 21 22 23] 0+ high,level,sharable 0.10.0 pci0: on pcib0 pci0: physical bus=0 map[10]: type 3, range 32, base f0000000, size 27, enabled found-> vendor=0x10de, dev=0x00e1, revid=0xa1 bus=0, slot=0, func=0 class=06-00-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=0x00e0, revid=0xa2 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) map[10]: type 4, range 32, base 0000e800, 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 pcib0: matched entry for 0.1.INTA (src \\_SB_.PCI0.APCS) pcib0: possible interrupts: 20 21 22 23 ACPI PCI link arbitrated settings: \\_SB_.PCI0.APCS (references 2, priority 220): interrupts: 23 22 21 20 penalty: 110 110 110 110 \\_SB_.PCI0.APCF (references 1, priority 110): interrupts: 23 22 21 20 penalty: 110 110 110 110 \\_SB_.PCI0.APCG (references 1, priority 110): interrupts: 23 22 21 20 penalty: 110 110 110 110 \\_SB_.PCI0.APCL (references 1, priority 110): interrupts: 23 22 21 20 penalty: 110 110 110 110 \\_SB_.PCI0.APCH (references 1, priority 110): interrupts: 23 22 21 20 penalty: 110 110 110 110 \\_SB_.PCI0.APCJ (references 1, priority 110): interrupts: 23 22 21 20 penalty: 110 110 110 110 \\_SB_.PCI0.APCK (references 1, priority 110): interrupts: 23 22 21 20 penalty: 110 110 110 110 \\_SB_.PCI0.APCZ (references 1, priority 110): interrupts: 23 22 21 20 penalty: 110 110 110 110 \\_SB_.PCI0.APSI (references 1, priority 110): interrupts: 23 22 21 20 penalty: 110 110 110 110 \\_SB_.PCI0.APSJ (references 1, priority 110): interrupts: 23 22 21 20 penalty: 110 110 110 110 ioapic0: Changing polarity for pin 23 to high pcib0: slot 1 INTA routed to irq 23 via \\_SB_.PCI0.APCS found-> vendor=0x10de, dev=0x00e4, revid=0xa1 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=23 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base fc002000, size 12, enabled pcib0: matched entry for 0.2.INTA (src \\_SB_.PCI0.APCF) pcib0: possible interrupts: 20 21 22 23 ACPI PCI link arbitrated settings: \\_SB_.PCI0.APCF (references 1, priority 225): interrupts: 22 21 20 23 penalty: 220 220 220 240 \\_SB_.PCI0.APCG (references 1, priority 225): interrupts: 22 21 20 23 penalty: 220 220 220 240 \\_SB_.PCI0.APCL (references 1, priority 225): interrupts: 22 21 20 23 penalty: 220 220 220 240 \\_SB_.PCI0.APCH (references 1, priority 225): interrupts: 22 21 20 23 penalty: 220 220 220 240 \\_SB_.PCI0.APCJ (references 1, priority 225): interrupts: 22 21 20 23 penalty: 220 220 220 240 \\_SB_.PCI0.APCK (references 1, priority 225): interrupts: 22 21 20 23 penalty: 220 220 220 240 \\_SB_.PCI0.APCZ (references 1, priority 225): interrupts: 22 21 20 23 penalty: 220 220 220 240 \\_SB_.PCI0.APSI (references 1, priority 225): interrupts: 22 21 20 23 penalty: 220 220 220 240 \\_SB_.PCI0.APSJ (references 1, priority 225): interrupts: 22 21 20 23 penalty: 220 220 220 240 ioapic0: Changing polarity for pin 22 to high pcib0: slot 2 INTA routed to irq 22 via \\_SB_.PCI0.APCF found-> vendor=0x10de, dev=0x00e7, revid=0xa1 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=22 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base fc003000, size 12, enabled pcib0: matched entry for 0.2.INTB (src \\_SB_.PCI0.APCG) pcib0: possible interrupts: 20 21 22 23 ACPI PCI link arbitrated settings: \\_SB_.PCI0.APCG (references 1, priority 337): interrupts: 21 20 22 23 penalty: 330 330 340 350 \\_SB_.PCI0.APCL (references 1, priority 337): interrupts: 21 20 22 23 penalty: 330 330 340 350 \\_SB_.PCI0.APCH (references 1, priority 337): interrupts: 21 20 22 23 penalty: 330 330 340 350 \\_SB_.PCI0.APCJ (references 1, priority 337): interrupts: 21 20 22 23 penalty: 330 330 340 350 \\_SB_.PCI0.APCK (references 1, priority 337): interrupts: 21 20 22 23 penalty: 330 330 340 350 \\_SB_.PCI0.APCZ (references 1, priority 337): interrupts: 21 20 22 23 penalty: 330 330 340 350 \\_SB_.PCI0.APSI (references 1, priority 337): interrupts: 21 20 22 23 penalty: 330 330 340 350 \\_SB_.PCI0.APSJ (references 1, priority 337): interrupts: 21 20 22 23 penalty: 330 330 340 350 ioapic0: Changing polarity for pin 21 to high pcib0: slot 2 INTB routed to irq 21 via \\_SB_.PCI0.APCG found-> vendor=0x10de, dev=0x00e7, revid=0xa1 bus=0, slot=2, func=1 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=b, irq=21 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base fc004000, size 8, enabled pcib0: matched entry for 0.2.INTC (src \\_SB_.PCI0.APCL) pcib0: possible interrupts: 20 21 22 23 ACPI PCI link arbitrated settings: \\_SB_.PCI0.APCL (references 1, priority 450): interrupts: 20 22 21 23 penalty: 440 450 450 460 \\_SB_.PCI0.APCH (references 1, priority 450): interrupts: 20 22 21 23 penalty: 440 450 450 460 \\_SB_.PCI0.APCJ (references 1, priority 450): interrupts: 20 22 21 23 penalty: 440 450 450 460 \\_SB_.PCI0.APCK (references 1, priority 450): interrupts: 20 22 21 23 penalty: 440 450 450 460 \\_SB_.PCI0.APCZ (references 1, priority 450): interrupts: 20 22 21 23 penalty: 440 450 450 460 \\_SB_.PCI0.APSI (references 1, priority 450): interrupts: 20 22 21 23 penalty: 440 450 450 460 \\_SB_.PCI0.APSJ (references 1, priority 450): interrupts: 20 22 21 23 penalty: 440 450 450 460 ioapic0: Changing polarity for pin 20 to high pcib0: slot 2 INTC routed to irq 20 via \\_SB_.PCI0.APCL found-> vendor=0x10de, dev=0x00e8, revid=0xa2 bus=0, slot=2, func=2 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=c, irq=20 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base fc000000, size 12, enabled map[14]: type 4, range 32, base 0000c400, size 3, enabled pcib0: matched entry for 0.5.INTA (src \\_SB_.PCI0.APCH) pcib0: possible interrupts: 20 21 22 23 ACPI PCI link arbitrated settings: \\_SB_.PCI0.APCH (references 1, priority 562): interrupts: 22 21 20 23 penalty: 560 560 560 570 \\_SB_.PCI0.APCJ (references 1, priority 562): interrupts: 22 21 20 23 penalty: 560 560 560 570 \\_SB_.PCI0.APCK (references 1, priority 562): interrupts: 22 21 20 23 penalty: 560 560 560 570 \\_SB_.PCI0.APCZ (references 1, priority 562): interrupts: 22 21 20 23 penalty: 560 560 560 570 \\_SB_.PCI0.APSI (references 1, priority 562): interrupts: 22 21 20 23 penalty: 560 560 560 570 \\_SB_.PCI0.APSJ (references 1, priority 562): interrupts: 22 21 20 23 penalty: 560 560 560 570 pcib0: slot 5 INTA routed to irq 22 via \\_SB_.PCI0.APCH found-> vendor=0x10de, dev=0x00df, revid=0xa2 bus=0, slot=5, 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=22 powerspec 2 supports D0 D1 D2 D3 current D0 map[20]: type 4, range 32, base 0000f000, size 4, enabled found-> vendor=0x10de, dev=0x00e5, revid=0xa2 bus=0, slot=8, 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[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 0000e000, size 4, enabled pcib0: matched entry for 0.9.INTA (src \\_SB_.PCI0.APSI) pcib0: possible interrupts: 20 21 22 23 ACPI PCI link arbitrated settings: \\_SB_.PCI0.APCJ (references 1, priority 675): interrupts: 21 20 23 22 penalty: 670 670 680 680 \\_SB_.PCI0.APCK (references 1, priority 675): interrupts: 21 20 23 22 penalty: 670 670 680 680 \\_SB_.PCI0.APCZ (references 1, priority 675): interrupts: 21 20 23 22 penalty: 670 670 680 680 \\_SB_.PCI0.APSI (references 1, priority 675): interrupts: 21 20 23 22 penalty: 670 670 680 680 \\_SB_.PCI0.APSJ (references 1, priority 675): interrupts: 21 20 23 22 penalty: 670 670 680 680 pcib0: slot 9 INTA routed to irq 21 via \\_SB_.PCI0.APSI found-> vendor=0x10de, dev=0x00ee, revid=0xa2 bus=0, slot=9, func=0 class=01-01-85, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=a, irq=21 powerspec 2 supports D0 D3 current D0 found-> vendor=0x10de, dev=0x00e2, revid=0xa2 bus=0, slot=11, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0220, cachelnsz=0 (dwords) lattimer=0x10 (480 ns), mingnt=0x0e (3500 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x00ed, revid=0xa2 bus=0, slot=14, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x00a0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0x02 (500 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) isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) ohci0: mem 0xfc002000-0xfc002fff irq 22 at device 2.0 on pci0 ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfc002000 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: 4 ports with 4 removable, self powered ohci1: mem 0xfc003000-0xfc003fff irq 21 at device 2.1 on pci0 ohci1: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfc003000 ohci1: [GIANT-LOCKED] usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: on ohci1 usb1: USB revision 1.0 uhub1: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 4 ports with 4 removable, self powered pci0: at device 2.2 (no driver attached) pci0: at device 5.0 (no driver attached) atapci0: port 0xf000-0xf00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 8.0 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xf000 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=7f ostat1=50 ata0-master: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata0-master: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata0-master: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata0-master: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata0-master: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata0-master: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata0-master: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata0-master: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata0-slave: stat=0x10 err=0x01 lsb=0x14 msb=0xeb ata0: reset tp2 stat0=ff stat1=10 devices=0x8 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=00 ostat0=ff ostat1=ff ata1: [MPSAFE] atapci1: port 0xe000-0xe00f,0xb60-0xb63,0x960-0x967,0xbe0-0xbe3,0x9e0-0x9e7 irq 21 at device 9.0 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xe000 atapci1: [MPSAFE] ata2: channel #0 on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x9e0 atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0xbe0 ata2: reset tp1 mask=03 ostat0=50 ostat1=00 ata2-master: stat=0xd0 err=0x00 lsb=0x86 msb=0x78 ata2-master: stat=0xd0 err=0x00 lsb=0x86 msb=0x78 ata2-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata2-slave: stat=0x00 err=0x01 lsb=0x00 msb=0x00 ata2: reset tp2 stat0=50 stat1=00 devices=0x1 ata2: [MPSAFE] ata3: channel #1 on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0x960 atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0xb60 ata3: reset tp1 mask=03 ostat0=7f ostat1=7f ata3-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata3-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata3-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata3-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata3-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata3-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata3-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata3-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata3-slave: stat=0x7f err=0xff lsb=0xff msb=0xff ata3: reset tp2 stat0=ff stat1=ff devices=0x0 ata3: [MPSAFE] pcib1: at device 11.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xa000-0xafff pcib1: memory decode 0xf8000000-0xf9ffffff pcib1: prefetched decode 0xe0000000-0xefffffff ACPI link \\_SB_.PCI0.APC1 has invalid initial irq 5, ignoring ACPI PCI link initial configuration: \\_SB_.PCI0.APC1 irq 0: [16] 0+ low,level,sharable 1.0.0 pci1: on pcib1 pci1: physical bus=1 map[10]: type 3, range 32, base e0000000, size 28, enabled pcib1: device (null) requested decoded memory range 0xe0000000-0xefffffff map[14]: type 4, range 32, base 0000a000, size 8, enabled pcib1: device (null) requested decoded I/O range 0xa000-0xa0ff map[18]: type 1, range 32, base f9000000, size 16, enabled pcib1: device (null) requested decoded memory range 0xf9000000-0xf900ffff pcib1: matched entry for 1.0.INTA (src \\_SB_.PCI0.APC1) pcib1: possible interrupts: 16 ACPI PCI link arbitrated settings: \\_SB_.PCI0.APCJ (references 1, priority 677): interrupts: 20 22 23 21 penalty: 670 680 680 680 \\_SB_.PCI0.APCK (references 1, priority 677): interrupts: 20 22 23 21 penalty: 670 680 680 680 \\_SB_.PCI0.APCZ (references 1, priority 677): interrupts: 20 22 23 21 penalty: 670 680 680 680 \\_SB_.PCI0.APSJ (references 1, priority 677): interrupts: 20 22 23 21 penalty: 670 680 680 680 \\_SB_.PCI0.APC1 (references 1, priority 20): interrupts: 16 penalty: 20 pcib1: slot 0 INTA routed to irq 16 via \\_SB_.PCI0.APC1 found-> vendor=0x1002, dev=0x5157, revid=0x00 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=16 powerspec 2 supports D0 D1 D2 D3 current D0 pci1: at device 0.0 (no driver attached) pcib2: at device 14.0 on pci0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xb000-0xbfff pcib2: memory decode 0xfa000000-0xfbffffff pcib2: prefetched decode 0xfff00000-0xfffff ACPI PCI link initial configuration: \\_SB_.PCI0.APC1 irq*16: [16] 0+ low,level,sharable 2.6.0 \\_SB_.PCI0.APC2 irq 0: [17] 0+ low,level,sharable 2.6.1 \\_SB_.PCI0.APC3 irq 0: [18] 0+ low,level,sharable 2.6.2 \\_SB_.PCI0.APC4 irq 0: [19] 0+ low,level,sharable 2.6.3 \\_SB_.PCI0.APC2 irq 0: [17] 0+ low,level,sharable 2.7.0 \\_SB_.PCI0.APC3 irq 0: [18] 0+ low,level,sharable 2.7.1 \\_SB_.PCI0.APC4 irq 0: [19] 0+ low,level,sharable 2.7.2 \\_SB_.PCI0.APC1 irq*16: [16] 0+ low,level,sharable 2.7.3 \\_SB_.PCI0.APC3 irq 0: [18] 0+ low,level,sharable 2.8.0 \\_SB_.PCI0.APC4 irq 0: [19] 0+ low,level,sharable 2.8.1 \\_SB_.PCI0.APC1 irq*16: [16] 0+ low,level,sharable 2.8.2 \\_SB_.PCI0.APC2 irq 0: [17] 0+ low,level,sharable 2.8.3 \\_SB_.PCI0.APC4 irq 0: [19] 0+ low,level,sharable 2.9.0 \\_SB_.PCI0.APC1 irq*16: [16] 0+ low,level,sharable 2.9.1 \\_SB_.PCI0.APC2 irq 0: [17] 0+ low,level,sharable 2.9.2 \\_SB_.PCI0.APC3 irq 0: [18] 0+ low,level,sharable 2.9.3 \\_SB_.PCI0.APC2 irq 0: [17] 0+ low,level,sharable 2.10.0 \\_SB_.PCI0.APC3 irq 0: [18] 0+ low,level,sharable 2.10.1 \\_SB_.PCI0.APC4 irq 0: [19] 0+ low,level,sharable 2.10.2 \\_SB_.PCI0.APC1 irq*16: [16] 0+ low,level,sharable 2.10.3 \\_SB_.PCI0.APC2 irq 0: [17] 0+ low,level,sharable 2.11.0 \\_SB_.PCI0.APC3 irq 0: [18] 0+ low,level,sharable 2.11.1 \\_SB_.PCI0.APC4 irq 0: [19] 0+ low,level,sharable 2.11.2 \\_SB_.PCI0.APC1 irq*16: [16] 0+ low,level,sharable 2.11.3 \\_SB_.PCI0.APC4 irq 0: [19] 0+ low,level,sharable 2.12.0 \\_SB_.PCI0.APC4 irq 0: [19] 0+ low,level,sharable 2.12.1 \\_SB_.PCI0.APC4 irq 0: [19] 0+ low,level,sharable 2.12.2 \\_SB_.PCI0.APC4 irq 0: [19] 0+ low,level,sharable 2.12.3 \\_SB_.PCI0.APC5 irq 0: [16] 16+ low,level,sharable 2.13.0 \\_SB_.PCI0.APC5 irq 0: [16] 16+ low,level,sharable 2.13.1 \\_SB_.PCI0.APC5 irq 0: [16] 16+ low,level,sharable 2.13.2 \\_SB_.PCI0.APC5 irq 0: [16] 16+ low,level,sharable 2.13.3 pci2: on pcib2 pci2: physical bus=2 map[10]: type 4, range 32, base 0000b000, size 8, enabled pcib2: device (null) requested decoded I/O range 0xb000-0xb0ff map[14]: type 1, range 32, base fb000000, size 8, enabled pcib2: device (null) requested decoded memory range 0xfb000000-0xfb0000ff pcib2: matched entry for 2.13.INTA (src \\_SB_.PCI0.APC5) pcib2: possible interrupts: 16 ACPI PCI link arbitrated settings: \\_SB_.PCI0.APC4 (references 10, priority 2000): interrupts: 19 penalty: 200 \\_SB_.PCI0.APC5 (references 4, priority 920): interrupts: 16 penalty: 230 \\_SB_.PCI0.APC2 (references 6, priority 720): interrupts: 17 penalty: 120 \\_SB_.PCI0.APC3 (references 6, priority 720): interrupts: 18 penalty: 120 \\_SB_.PCI0.APCJ (references 1, priority 677): interrupts: 20 21 23 22 penalty: 670 680 680 680 \\_SB_.PCI0.APCK (references 1, priority 677): interrupts: 20 21 23 22 penalty: 670 680 680 680 \\_SB_.PCI0.APCZ (references 1, priority 677): interrupts: 20 21 23 22 penalty: 670 680 680 680 \\_SB_.PCI0.APSJ (references 1, priority 677): interrupts: 20 21 23 22 penalty: 670 680 680 680 pcib2: slot 13 INTA routed to irq 16 via \\_SB_.PCI0.APC5 found-> vendor=0x10ec, dev=0x8169, revid=0x10 bus=2, slot=13, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns) intpin=a, irq=16 powerspec 2 supports D0 D1 D2 D3 current D0 re0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xb000 pcib2: device re0 requested decoded I/O range 0xb000-0xb0ff re0: port 0xb000-0xb0ff mem 0xfb000000-0xfb0000ff irq 16 at device 13.0 on pci2 pcib2: device re0 requested decoded I/O range 0xb000-0xb0ff miibus0: on re0 rgephy0: on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto re0: bpf attached re0: Ethernet address: 00:11:09:d9:b6:61 re0: [MPSAFE] unknown: not probed (disabled) unknown: not probed (disabled) sio0: irq maps: 0xca1 0xcb1 0xca1 0xca1 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) atkbdc0: port 0x64,0x60 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: unable to allocate IRQ unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) ahc_isa_probe 4: ioport 0x4c00 alloc failed ex_isa_identify() atkbdc: atkbdc0 already exists; skipping it sio: sio0 already exists; skipping it Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 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 0xd2000-0xd2fff,0xd0000-0xd17ff,0xcc000-0xcffff,0xc0000-0xcbfff on isa0 fdc0 failed to probe at port 0x3f0-0x3f5 irq 6 drq 2 on isa0 ppc0: cannot reserve I/O port range ppc0: failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0xca1 0xca1 0xca1 0xca1 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 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:0xffffffff800b8000 size:32k gran:32k, buf:0 size:32k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0e 0f 00 00 07 80 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 VGA parameters in BIOS for mode 24 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 EGA/VGA parameters to be used for mode 24 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0e 0f 00 00 07 80 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 isa_probe_children: probing PnP devices Device configuration finished. procfs registered Timecounter "TSC" frequency 1808811173 Hz quality 800 Timecounters tick every 0.976 msec lo0: bpf attached ata0-slave: pio=0x0c wdma=0x22 udma=0x42 cable=40pin ata0-slave: setting PIO4 on nVidia nForce3 Pro chip ata0-slave: setting UDMA33 on nVidia nForce3 Pro chip acd0: CDROM drive at ata0 as slave acd0: 128KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, packet acd0: Writes: acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc ata2-master: pio=0x0c wdma=0x22 udma=0x46 cable=40pin ad4: ATA-6 disk at ata2-master ad4: 76319MB (156301488 sectors), 155061 C, 16 H, 63 S, 512 B ad4: 16 secs/int, 1 depth queue, UDMA33 GEOM: new disk ad4 ar: FreeBSD check1 failed ioapic0: routing intpin 1 (ISA IRQ 1) to cluster 0 ioapic0: routing intpin 2 (ISA IRQ 0) to cluster 0 ioapic0: routing intpin 4 (ISA IRQ 4) to cluster 0 ioapic0: routing intpin 8 (ISA IRQ 8) to cluster 0 ioapic0: routing intpin 9 (ISA IRQ 9) 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 16 (PCI IRQ 16) to cluster 0 ioapic0: routing intpin 21 (PCI IRQ 21) to cluster 0 ioapic0: routing intpin 22 (PCI IRQ 22) to cluster 0 [0] f:00 typ:7 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:81915372 [1] f:80 typ:165 s(CHS):1023/255/63 e(CHS):1023/254/63 s:81915435 l:74380950 [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 ad4s1, start 32256 length 41940670464 end 41940702719 GEOM: Configure ad4s2, start 41940702720 length 38083046400 end 80023749119 GEOM: Configure ad4s2a, start 0 length 37008441344 end 37008441343 GEOM: Configure ad4s2b, start 37008441344 length 1074605056 end 38083046399 GEOM: Configure ad4s2c, start 0 length 38083046400 end 38083046399 Mounting root from ufs:/dev/ad4s2a start_init: trying /sbin/init calcru: negative runtime of -997279 usec for pid 99 (sh) calcru: negative runtime of -550697 usec for pid 207 (ifconfig) calcru: negative runtime of -993368 usec for pid 3 (g_up) calcru: negative runtime of -993368 usec for pid 3 (g_up) calcru: negative runtime of -993148 usec for pid 3 (g_up) calcru: runtime went backwards from 2886978 usec to 1980814 usec for pid 11 (idle) calcru: negative runtime of -993148 usec for pid 3 (g_up) calcru: runtime went backwards from 2886978 usec to 1980814 usec for pid 11 (idle) From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 10:13:16 2005 Return-Path: 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 F34CC16A4CE for ; Mon, 11 Apr 2005 10:13:15 +0000 (GMT) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CB1943D48 for ; Mon, 11 Apr 2005 10:13:15 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) (8.13.4/8.13.3) with ESMTP id j3BADC9X016515 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 11 Apr 2005 12:13:12 +0200 (CEST) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.4/8.13.3/Submit) id j3BADChc016514; Mon, 11 Apr 2005 12:13:12 +0200 (CEST) Date: Mon, 11 Apr 2005 12:13:12 +0200 From: Divacky Roman To: Doug White Message-ID: <20050411101312.GB15463@stud.fit.vutbr.cz> References: <20050406130909.GA90294@stud.fit.vutbr.cz> <20050408144444.GA34248@stud.fit.vutbr.cz> <20050408094349.U63303@carver.gumbysoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050408094349.U63303@carver.gumbysoft.com> User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.49 on 147.229.10.14 cc: current@freebsd.org Subject: Re: slow kbd input on 6-current on amd64@nforce3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 10:13:16 -0000 > I don't recall seeing .. what happens if you boot safe mode? its the same in safe mode.. From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 11:28:18 2005 Return-Path: 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 9E62616A4CE for ; Mon, 11 Apr 2005 11:28:18 +0000 (GMT) Received: from mail16.syd.optusnet.com.au (mail16.syd.optusnet.com.au [211.29.132.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id CEEA043D1F for ; Mon, 11 Apr 2005 11:28:17 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j3BBS1Qp029048 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 11 Apr 2005 21:28:02 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j3BBS07l097987; Mon, 11 Apr 2005 21:28:01 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j3BBS0k3097986; Mon, 11 Apr 2005 21:28:00 +1000 (EST) (envelope-from pjeremy) Date: Mon, 11 Apr 2005 21:28:00 +1000 From: Peter Jeremy To: Wilko Bulte Message-ID: <20050411112800.GK89047@cirb503493.alcatel.com.au> References: <20050411093912.GE56099@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050411093912.GE56099@freebie.xs4all.nl> User-Agent: Mutt/1.4.2i cc: freebsd-current@freebsd.org Subject: Re: Potential source of interrupt aliasing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 11:28:18 -0000 On Mon, 2005-Apr-11 11:39:12 +0200, Wilko Bulte wrote: >On Mon, Apr 11, 2005 at 12:34:01PM +0300, Danny Braniss wrote.. >> ... >> > It's a pity that the modern PC is hamstrung by design decisions made >> > over 25 years ago. >> >> sorry, but couldn't help it :-) >> >> The US Standard railroad gauge (distance between the rails) is 4 >> feet, 8.5 inches. That's an exceedingly odd number. Alternative measurements of 1435mm or 4.787nsec are just as odd. >> Why did the English people build them like that? > >Why would any sane person continue to use inches, feet, stones, yards >etc etc anyway? That could be the problem :-). If the CPU and PCI bus is built using imperial measurements whilst the northbridge/southbridge is a metric BGA, the electrons could be getting confused by the changes in units and are arriving at the wrong interrupt pin. :-) :-) -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 12:27:48 2005 Return-Path: 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 1093516A4CE for ; Mon, 11 Apr 2005 12:27:48 +0000 (GMT) Received: from peedub.jennejohn.org (J9216.j.pppool.de [85.74.146.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28F5143D1F for ; Mon, 11 Apr 2005 12:27:47 +0000 (GMT) (envelope-from garyj@jennejohn.org) Received: from jennejohn.org (localhost [127.0.0.1]) by peedub.jennejohn.org (8.13.3/8.11.6) with ESMTP id j3BCRccU000582; Mon, 11 Apr 2005 14:27:38 +0200 (CEST) (envelope-from garyj@jennejohn.org) Message-Id: <200504111227.j3BCRccU000582@peedub.jennejohn.org> X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: sos@DeepCore.dk In-Reply-To: Message from =?ISO-8859-1?Q?S=F8ren_Schmidt?= of "Mon, 11 Apr 2005 10:43:30 +0200." <425A38B2.8010103@DeepCore.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 11 Apr 2005 14:27:38 +0200 From: Gary Jennejohn cc: freebsd-current@FreeBSD.ORG Subject: Re: SATA PHY commit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 12:27:48 -0000 Soeren Schmidt > Gary Jennejohn wrote: >> WIth the SATA PHY commit my SATA drives are not found anymore, the PATA >> devices are still OK. >> [snip] > Could you please try again with the changes Warner has committed to=20 > dev/pci/pci.c and get back to me with the result, thanks! > Doesn't help, the drives still aren't found. --- Gary Jennejohn / garyjATjennejohnDOTorg gjATfreebsdDOTorg garyjATdenxDOTde From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 12:59:50 2005 Return-Path: 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 3A9F816A4CE for ; Mon, 11 Apr 2005 12:59:50 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78E4743D2F for ; Mon, 11 Apr 2005 12:59:47 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j3BD3GqK030850; Mon, 11 Apr 2005 07:03:16 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <425A7407.7000502@samsco.org> Date: Mon, 11 Apr 2005 06:56:39 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Dillon References: <20050406233405.O47071@carver.gumbysoft.com> <200504081656.51917.jhb@FreeBSD.org> <20050410152946.W82708@carver.gumbysoft.com> <20050410172818.D82708@carver.gumbysoft.com> <200504110231.j3B2VOYr047361@apollo.backplane.com> <425A10DD.70500@samsco.org> <200504110658.j3B6w2nb048552@apollo.backplane.com> <425A2283.7040405@samsco.org> <200504110731.j3B7VtPv048805@apollo.backplane.com> In-Reply-To: <200504110731.j3B7VtPv048805@apollo.backplane.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 Subject: Re: Potential source of interrupt aliasing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 12:59:50 -0000 Matthew Dillon wrote: > :... > :that I mentioned precisely because we don't mask the IOAPIC for fast > :handlers. Unfortunetaly, moving the entire OS to this scheme is > :quite labor-intensive. It would make just as much sense to implement > :MSI infrastructre and convert a number of drivers to that. And again, > :Linux seems immune to this problem, so it's very intriguing to find out > :why. > : > :Scott > > kernel/io_apic.c line 1829ish (linux 2.6.9). And the whole file in > general. > > It appears that they simply do not EOI the APIC when handling a > level triggered interrupt until after the interrupt handler has > run. And indeed, that is what appears to happen. It looks like they > may still be vulnerable due to the way they shutdown an interrupt > (but by them the device is presumably not asserting interrupts any more). > But for normal interrupt operation they simply do not EOI the APIC. > > I love the last sentence of this comment... OMG! They have got to be > kidding. This would explain it. Unfortunately, I don't think that we can do the same in FreeBSD because 1) the ithread won't run right away (unless PREEMPTION is enabled) 2) the ithread might block (remember this is a feature of ithreads =-) The end result is that the CPU will often go off and do other things for long periods of time instead of servicing the ithread, all the time with the EOI not sent and thus timer interrupts not reaching it either. We program the APIC delivery to be round-robin, but on the P4 family that decomposes to only delivering to CPU0. I think that Linux tries harder to do more complex CPU routing, but that still wouldn't guarantee to help the situation we have here. So that's why a say that a two-tiered interrupt scheme is attractive; you get the benefit of being able to service and quench the interrupt right away along with the benefit of being about to block for locks and resources in the ithread. [...] > [ more comments from the linux code ]: > /* > * It appears there is an erratum which affects at least version 0x11 > * of I/O APIC (that's the 82093AA and cores integrated into various > * chipsets). Under certain conditions a level-triggered interrupt is > * erroneously delivered as edge-triggered one but the respective IRR > * bit gets set nevertheless. As a result the I/O unit expects an EOI > * message but it will never arrive and further interrupts are blocked > * from the source. The exact reason is so far unknown, but the > * phenomenon was observed when two consecutive interrupt requests > * from a given source get delivered to the same CPU and the source is > * temporarily disabled in between. > * > * A workaround is to simulate an EOI message manually. We achieve it > * by setting the trigger mode to edge and then to level when the edge > * trigger mode gets detected in the TMR of a local APIC for a > * level-triggered interrupt. We mask the source for the time of the > * operation to prevent an edge-triggered interrupt escaping meanwhile. > * The idea is from Manfred Spraul. --macro > */ > This sounds like the famous EOI bug in PCI-Express handling in the 7520 chipset. Good times. From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 13:46:18 2005 Return-Path: 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 852FF16A4CE for ; Mon, 11 Apr 2005 13:46:18 +0000 (GMT) Received: from mailout11.sul.t-online.com (mailout11.sul.t-online.com [194.25.134.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0905843D31 for ; Mon, 11 Apr 2005 13:46:18 +0000 (GMT) (envelope-from mike@reifenberger.com) Received: from fwd33.aul.t-online.de by mailout11.sul.t-online.com with smtp id 1DKzF2-0000JY-05; Mon, 11 Apr 2005 15:46:16 +0200 Received: from fw.reifenberger.com (rfcgHGZ6oeqM+FIPgcRrWE2fQ5uhvzp+S4neMpYWkv4lRVY5651AoM@[217.232.232.108]) by fwd33.sul.t-online.de with esmtp id 1DKzEo-0dSF4y0; Mon, 11 Apr 2005 15:46:02 +0200 Received: from localhost (mike@localhost)j3BDk1ZD033792; Mon, 11 Apr 2005 15:46:01 +0200 (CEST) (envelope-from mike@reifenberger.com) X-Authentication-Warning: fw.reifenberger.com: mike owned process doing -bs Date: Mon, 11 Apr 2005 15:46:01 +0200 (CEST) From: Michael Reifenberger To: =?ISO-8859-15?Q?S=F8ren_Schmidt?= In-Reply-To: <425A380D.5030400@DeepCore.dk> Message-ID: <20050411154520.M33433@fw.reifenberger.com> References: <20050410164959.G38200@fw.reifenberger.com> <42597A6D.8080801@DeepCore.dk><425A380D.5030400@DeepCore.dk> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-941186705-1113227161=:33433" X-ID: rfcgHGZ6oeqM+FIPgcRrWE2fQ5uhvzp+S4neMpYWkv4lRVY5651AoM@t-dialin.net X-TOI-MSGID: 6ee4df4e-869d-49c2-9cbd-ee52ed0d39a7 cc: FreeBSD-Current Subject: Re: SATA with new ata code doesn't work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 13:46:18 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-941186705-1113227161=:33433 Content-Type: TEXT/PLAIN; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT On Mon, 11 Apr 2005, Søren Schmidt wrote: ... >>> Yes, the problem is that the alloc_resource fails on the last resource >>> (0xb4000-0xb4ff) for some unknown reason. >>> I've given up finding this remotely and have ordered a VIA based >>> motherboard that I'm picking up tomorrow, then I'm sure I can have fix >>> ready soon... >>> > > Warner has committed an update to the PCI code, could you please try it out > and get back to me we the result ? > Not before 21:00 CEST Bye/2 --- Michael Reifenberger, Business Development Manager SAP-Basis, Plaut Consulting Comp: Michael.Reifenberger@plaut.de | Priv: Michael@Reifenberger.com http://www.plaut.de | http://www.Reifenberger.com --0-941186705-1113227161=:33433-- From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 15:21:36 2005 Return-Path: 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 4EAD316A4CE; Sun, 10 Apr 2005 15:21:36 +0000 (GMT) Received: from dmath5.geometrie.tuwien.ac.at (dmath5.geometrie.tuwien.ac.at [128.130.42.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id AABCA43D39; Sun, 10 Apr 2005 15:21:35 +0000 (GMT) (envelope-from wiz@dmath5.geometrie.tuwien.ac.at) Received: by dmath5.geometrie.tuwien.ac.at (Postfix, from userid 1000) id 4C13B294DC; Sun, 10 Apr 2005 17:20:17 +0200 (CEST) Date: Sun, 10 Apr 2005 17:20:17 +0200 From: Thomas Klausner To: Don Lewis Message-ID: <20050410152016.GA18914@dmath5.geometrie.tuwien.ac.at> References: <20050227050523.GA92300@xor.obsecurity.org> <200502271024.j1RAO6jC010109@gw.catspoiler.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="/04w6evG8XlLl3ft" Content-Disposition: inline In-Reply-To: <200502271024.j1RAO6jC010109@gw.catspoiler.org> X-Mailman-Approved-At: Mon, 11 Apr 2005 14:25:47 +0000 cc: freebsd-current@FreeBSD.org Subject: Re: fsck_ufs: cannot alloc 3166749884 bytes for inoinfo X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Apr 2005 15:21:36 -0000 --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Feb 27, 2005 at 08:24:15AM +0000, Don Lewis wrote: > On 26 Feb, Kris Kennaway wrote: > > A recent panic left my FS with some serious corruption, which fsck is > > unable to repair: > > > > # fsck_ufs -b 376512 -fy /var > > Alternate super block location: 376512 > > ** /dev/twed0s1e > > ** Last Mounted on > > ** Phase 1 - Check Blocks and Sizes > > fsck_ufs: cannot alloc 3166749884 bytes for inoinfo > > > > (same holds for any superblock I've tried). > > > > How can I recover from this, short of running newfs? > > What does dumpfs say about the contents of the superblock? For some > reason fsck thinks it needs to allocate space to hold the information > about 791687471 in one cylinder group, which seems a bit unlikely. I have a similar problem with a 110GB UFS on 5.3/i386. fsck dies for me with: fsck_ufs: cannot alloc 607016868 bytes for inoinfo df output is strange too: /dev/ad6s1a 113552318 -6315512682 6419980816 -6045% /vcr The dumpfs output for the file system is attached; As you can see, dumpfs dumps core in the end. Any ideas how to restore this file system without using newfs are welcome. Cheers, Thomas P.S.: Please CC me, I'm not on this list. --/04w6evG8XlLl3ft Content-Type: application/octet-stream Content-Disposition: attachment; filename="dumpfs.output.bz2" Content-Transfer-Encoding: base64 QlpoOTFBWSZTWYDh0ywAOzxfgHAyRmf/8CEAjgq/79/wYCu/B8+IFRj74BeeA8YRdIzXQGpV AVEJ9NLgOMU9vpvt99B7uYn27tCqHjN3p3Pvu7aLafXz2+uO+OcPpivmWZ187FV072eqenus AdW94G89dgC4BcD0DRkkQDQfbAhpGExDRISCIgNAAYQGKBqbfqlRBNQAaAAAAAGmITJKJp6l MgGgAAAABmVIaIZJkkQD1AAAAAESIIQTIUSeoD1A09QB6m1NAClJBTI1GTJo1GkxoRNqHqMQ Y08Yl/PFmfz+lVS6FR9P7Pb6fZ3N/2z/3r/SqpdO5QvpoNUMkx2QVtH3ZpSWMFaUaSmZrTTW sArmXGm7EJYMCVmBUucIrUsilmIK342jYNrpVUv8ZVUv2f85DUUVHwqqMVVHaKqPgnI94aKq IKVmQBmEKgUYpUP/e2ZxP4EkpSAAQAoxsnnEYAQxZWIEAP6iBbCABACAAQAthAIAQACgECya MdBISQJYHQEmIYLCFSQkGQZDjAipR+tFJhDsqHbp2DnX60PN9q5wsiEiEIMjXkABYqqOLDGS oR3GQLiyDmqCsUlxCRLhUGRSCYFATvblBT9oIpWM0BIJqqpBWJUGRSQCQ+YFQcgQqP4xaiyJ IeIhUAhGIbVCuIpcHiJKCSRLIFoSZYsigMNMYmE0LCiEhLARWxRC7hLCqmKr+MrOS7lxcQnw STENBDwpOlD5ECZisoksIDFNrbZIRACBiLgQLYbYcAiAEAPAgBbNWbySSW/bpggBtbBz5AVt m2mYzMxmRugr11F8sFmI9MX6+ub77o/XJLfj24VT7Mgprfn5AVq1qVOjgU3t2NKiyo2zWpAU jjlGjS4prl/tz4HOWbvKnLu8zdG7u7uksAHDIDomZmZ5wM5yAAABoDoZ5znORzmACVuTi2NM 6BMzMzMzIAAAACZmZmZkBznOc5zgREREBMzMzPEzMzMjnOc5MRERMyDnOc5znAATjXNdRnrc z1vnJJAAADnOcIiIABMzMzMyB1111110AAc3nMyzreNazt1MzMzMhEREQABGeax0tum9vcrm vg5VmAIgYeRAUAKJoAABFTvG+dZ2ZDaIuBU5iAWKEiXWL43LVVHWjhABal4VVH+2XxJ+fngA H8YEktm1+pQoUKFChQoUAoX8ZUoUKFChQoUKFChIFChQlChQCUKFChVakShQkgUIEoUKFChI FChQoVKgUKFChAoUKFChQoUIlShQkChQoUKFChQFqUKE/SRKFChIFChQoUKFChQoUKFChfyl Sn1/D+aVVKn5qj8clH8nn+HsqXzyEnh7vHXnVUvl37fPrArXKpdcRJoCu8NvZplgrFlRmRTG ZmCrMlQhUEpH8awAAurrmEglE/dmUhdVFCEEJV03AqqEAJEAMQQLbiClK3V2oVc1fUVVHx69 IALeuEcwEUf1vnKAC94qqPW/H59/YKh9fvwUDYkrz/TyqqXUOsLdC8/rxQrvArOtKm1fLD0x aya/PQ/ICsi3zWGsWVMvvYPOlTKumJvKIkhPmUwbEUaVPB9T7169c3+G9b9/F7mZuVVy0Hay 7emZmjcVwgCjAmBhHABwhJBNQeOWopIJxGESoJmBcS4JIJIJIJItN3QQE4iNEGASCEiAc2np i7V2914tvi1us2bsXe8auxrIKzeIo8m6qXynVU8mZPIkgDFVsnWTNHNyaZ3imZIxziMlWckO 5yxpAXN3jfsIhyKxTrU0jz7CLdgpMsZVMyr3NIQ1mZhMqTBMqFgQkisAUSQhIpIrVKiUg/rA ayMzFCywxmZl8oWNFKxgCAFvypJbLSAWWSUCYtsilP1mssxee7AK//33MzCFljMY3KTGszLM m8L+9R/d4FJ86VM8fMCud/YBXaBXOtvb8IFfyArcCt8Ar8OvjEPxlMzMZZkrMispZmWYZkjG QMoYmYZhGYqsBkZkxhmP/vt6fbSj7clSeWKV5fY+m33fcL+FDgVmsyKZlVDJiXlUwCDZFVJD gcqBBBlyJTMJviQ6c793EC2YzGlU0RtUXAsjYSIKaJYNQQCwJYohhQJVVAMVvMUUgJpUWugC pVmUpzjjdUbbjOeHMa1JGqGdNmuDGdK3DYMAlIAaxAADEqm8ANc63wbaLAOAHPHG+7nKDnE1 IMVCEBLhuVMFHGsUiMUNcIi3i8YucHGceTCKKFIpea55RbQqCaiagNgEghTkVNxETiDskBS4 o6gSKaxdQuCSJIIycxG4iEgOpUugA3FkQZJEQkgam95uCooTo/mtM8GSt4Q2jyoXeqOcCBiA mxwKEqkFKvB1eMoiyZB44oADWq+H7dTXGO8jZiM1xzkjdRiC3351vJAL2IUBK2dS6FDF1stV UKnjahyyTiG4zWOXXZbFgmZSnGaTMFYwcS02zuqDfG8smsbQ5Ga7+OYDuwmjJmRmRmDMspor U2gAdoKOL552CCOMZmgAFvqsN4oVKiJm7uBIJIJItEqOoNQSQLIFQSQbjUEkEkEhigKgkxQU DiAYiOCDdBjGIJIJIJIJImMTMTNajWJmRi1ib5KfL8enIVkEkca1VUsFO7nCi7uNZdHC6W+c Z1LHKTMTJmb2SXi0QqqiRDwhocgBW8JMY84TfFSmwFbdcJmWTOfDaSu7JbgYQzKqlvwVTcQB TMVVGlFTPFZmZVVjHbNGPfQLMSVndQlvmSWs7t1SjebR266lGy6znQddhE0l380aCCNXaMii EBEedb675QESpuIWz6wu27ZZJbrZLZ+26bKqqqqqqqsVVVVVVVVVVVVVVWKqqqqqqsVVVVVV KoqrGBFVqqqqqqqxVVVVVWKqqqoKqqqqqqqoKqqxVVVVVVVVYqqqxVVVYqqqqqqqqqqqqqqt 73ve973MgCIWsACIEDy2mj/v/CPr6/Z3tVVVVVVMzMq1W73qYiNaaKpV3ve4iIiK3vdVVVVV VrVVVVUIiBERVVVLVVURERVMyM2NaDJEEAAFnwfAgCfF4v0/SmAznOQqiydvinEMau9psgwi 47zWdetjx4xnd8OQAFs4z51nnOuN9IHUEJICqc51rV5QOObmNY7VnednIRFaxBlDKzDfDRqx q4UtWt5vjvZooiAG7AASA+MZ1q+yAC7RDq9fE2y96T3V4zd5HjPvjvqYycVjjhvczjOQNIKu IiBl8mq73XztZeR33885nMnAACOhyubzTo9KIAAEQy8eRc6sqopPJzuLwBFliOWC1Oo7zOcx bN6mZmaqhAbABYatuN73iN2jWNRuMZxfNgtrWCWWM3bvMJbWMpfu003d3cYHknzF7rtk1y8V k839AiIiGKXQ4x9s9+vnERKqqzMTJmc2R3zJ2pndzebyBHqIAER3zu6e9DTkEmwypiI1/1aJ 1KaYrtFx4Z3deEqdd+e2gAGD0AAARG+oymGWxECIh7IfJVffzz588+Y97TzSYJPS+hJ3EnpZ qs3R94aF9EdeHPHvAacx4jU3ren3k4jISK/7CKlU3zW8V9kSAE8W22yj3Z5w7m3p05y89ucE m1n2FnrLvnfXN6duPSkCcrOwnflwUIECEkklvKkDnbHjnmTaZLNiBnXba+eNpwTytFiTZaeG pOB0ejBO9tklXXGNe/ezTYL2JNzBvtnzppPfznbjnjriF5ZAAMqKgv2a6YN++ydfID259Mxq 8nkD274AiZ80lIKlrRJINpdF7ytzs0kCBAGjmbSQ9fTREmcvOWXEkPNERF5vYKDqAIFRFEmb prF3dEkISSde7vQo14pULiIVEU4ionnfG9zxi37+yiBEQDHB9MHDnMs8G3pJJOL7TXnPb4qn wAACIblIk+02/byBd/TkN1ywJp778rnnWSSx6eSUETz5Jk2kTneOvIExbuxNR5AAAHMBMTfv nd1CTkoFSvKCwRUpRVoAQJVlXC7BRc3eCFTBVyTNVjqXedZz551DXO1vL1PPx8O/l379vDGP IADoaDx73ve97096agUVIYmqcgCIpwmgAyiyDUJfPo0VlgKniOuNazj2s9mj9jw9qo3fnEy1 Mgz3u+aVHSAC0KpdFeesddqrGuPjtzVVzxxzjQ1yu7u32ZnuV3valCBZOxERECO16ECIDgOI IpkmazxJvVkJziv25EPsDxUxyKihynaSJx+ONKeNAIvBBC8aVEwWqKebrxkASoagKXAAOs35 7X54rP4PAo4gom+fX4ff4efw9CALxx5u7qpNQKh9Vzfton4Vtv0t9T6gVVqroR8wIAAocJJP ab9a70iIVVKgA1XN3fmy7wVM76x0QBY5w2uXy5riSR1a2zjf1pEwT4kZ5vZ7VUbvWMvjyI5B SRHH1QCb5knrF2eKqSp9wAAWCooVd96qq7389uM4h1vtx4MoyAs+fXHOqN8VzjGZg55DQAgZ sBBoQrHx9fddvvrudcc1XkoZFAkUGpUgoQRVwY+kj1jElksmFkNcQEFcKBztvnqevOu5nbOZ jXcPhT4X4qskklogHTvh7M3dO3afP01213zmM+3hgfCh7InCgAE4xvxxJzzv88zk5kL5X1kk kmkikiR1JLDVZga+it5dUAABEWAhOCeXzvv68nR8NEglpeBJj6m58u59Sp3mO/Hkz58ce+M7 xxwNduqkoK3dqiBdXEmdrYve1jvez2Z2cm97b1k/WlmdW1epmZmZmICWAADUb1bOMX3jWL2j Ft4vnG8WtrF7BbABbLYrWIEREFsvr3FYEeXNLsqNho3vW/NVD5wuT0zrIUX3szGvfE0LrtAR AAhi2bUu3veufHvvsktzNxtjZ3d2W3W7jzTTsAQACdLxd+jPPJyaNKZgSKmbxLzkGVM1bWdK B9kzYjxYJSKV2pHmF10IEgIagjjbio6dwRrW3f239DW2IpyKU7deffjx8+ZbbZOJxTzDFwgs dF2U8qel9JH0a9fP1HO5vN5OYPBEAcIECfXi1IkmpblVJJ1PuXCpIKLBRZK7TPXbteZL3nLj TbLMcamEA8LNFADp9ee5NdF4NM9+9xjPfHLmrgLMRJJ4kfErSJ+aR03W7G8f1WMc84+/n6b8 e+tedxeZbMIHpSAHQgnHPXWOvDnfbMzHG4HgTWKDLbLbYrnHOiSE+lkrI2ySVATyvY2zx2vq Z16HfOdc0137emYgzoaJJJPEiSRi0062NmzPLsL1mVLJJhJAFE9Suimvjq7hVV2l77dgFz94 3rE1enWaY89ts5+OPe/g1ihh8TBMWW2ZNNNlADmVLmd8+Nd/rvvmb1xw9CivnHjvXCPhBYIq XQqlxBRPm7kk+qqRkxVUqgFd512799eHaO3evPkO2MdvSqqqqqoBYABzbiIyGYYjd0ZkxmYW oZgZEIYIqa3CLcA99YrXNGWVU8qcNGeBMRaMHcZyek9cpdmp+uYTHuz4SxEQG66wtZboi7Vp vdXxyKve8Pm5LY2a3d2pmZsbzNyrIAABxQAIGV6SEhfTUFU6l3cuyua/D7HgGChmIqUZgGVZ jBmsslB04kd+ZlJd85760oGIAtSALIoCVUfHis331ea+wzWaRsPL5z788+fPlVVVVVTMzMzV vfD5zOctiqN5WOYxvcbmYiI5VVyqqqrnOWtznOc5yZmRMzjnOc43OciIiI5zGFVsY9+TRne9 6vdr3xRnax3v3AEgAACImSfhTnPpHxNnlXY8n486ySZSH1r3Y3wgZesPePgdvHiQ121xqWzU tmmxO53w92ObJJVZZJZFVAOnGHsdtOO18+93dztm9byc4nfPcOHnCHSgAT4Ymp438d7PfrTO +cZBBDaQQQ8Ynma+fX18+PXn44kkJJNVUNV9oNkigDIV01PVePPr0evV8nE3e3Yx981oXzY8 i3xQhyLycyQbS4O7NGBT7eMacHnOWyBphCMzb9YIgWChjAIAFFgrXV2iARD0k+o8lLiztCbt IF77jz1hX3LiEjIrZOeHRcSmyy5qqgS2bST1m/v4N61vZGeN/NJG8HGrWqNTMzMzMzAMAEhF rWvGc31i1rX1vN77xfWLWjOItZs4xXdZRsQ7Q06ds5yncbdL6Q19aI/m2P2rwt6umOPrfb3v LzMIiJKzEQiIiNjAiEdlFiBAi3nPIAC62gAvtAbM8NKBiykoZBJEJAJCMnMdzGS8XjGb6gQB VgZpRzAQJOq3Qr1FROCb0jVU6gmc4V/UPqanPFuZY0McPm91RCoNVyxO1MYs9UQRDHbPXbr1 1jtk7CALVbxgQBfMFRQ2xVTwKHhmZAfGSOgou0S0paVGkDWnGPixEYiMYOr4l4zrgL2lYU2Q MQBCr2HcbcY5mTSS+YcIzMRAAnz5nefXW9/Leu2HR58wOoLBOW8P16GsOLI3MCual3u70zp1 6AVwyqpYyqKEFVO3bnrtur32frezGtaS+X6zrGPcv5oAB7a53yz188+vdZ44nAzr4nbf3C+T mUUKC+vuiW2IzkWZmVFBbPzFdx83j3B6Lq1VrxQCNZEshF25AgQFl+DzZj48TByGxh76nHYv nVrfIjczMzVVVAZAcDcb3jGY3rOI1vMYzreM4zz5vdhjo0YfK5nO/bVCxuMLd4P3pfiN2/dY 4+zFh5S+KU33m9+Gl3O42x3tLu7VTM7W7uisKuhgIx5pneNky0ZTo0CL4E3mUOAQCQCAVNSj mkzBtFBz1XURQcKqjxSQD2IiBDEmixxnFq1n5b4tDNu2HvufVvJ7ZUxI3a7KVxy0nh0O3DRE 7evA2caPcZhvbGaykTzACtBv7WFsFVlEWtT8748YvvWspbSYTSsiN5R+wSIciEECIKO+PivG PfVdufHzwYxrfnFycUresXRGcwRAo746uF4xjMWicSDABBrIyAwBMlUKpIiHR37ePHr43789 Pn30db97NBAAArCx4v67dPPWFsiHkegRERC8h5kRLLM53Gn3zlnpjHiHaqqqqqqgNggNbta9 73tszOyBTUWuiqLHnU58OH66To1PWPNhDetXxrPqAvncm2nyh6GrnI3usZO6K/ZjTIhy8wZn NrOrd3aqZmt3d5nIiIiBFB+gAJFdWADJ4pBS5qcedTFSzEhlIWKHTWKE8NidZPKnjWIWMZt5 ubZTSerXsibIgVWxmbGThFtfTb9nls5w6okkCWwAIiFaHHuEsnlwE1n2ZZFECKIHFV3z37/W nOMd33vWq1rv2vWqz2dx1++nRO1r3sceqsyodwQIiJCAI7gEALWBB+M/P1nM+a5vnfo6K1nO C3xKVFMQGKqj5a6swKweVc8YRlRPWlYUkgAAi0/mPeS0uhTBUSF967578w9XD55fZ1TntvMI zZi12lCtl2fMR6Wta1rXvKvTtUzavYxgDtVVVVVVQEAkRABBLkQASxAhaLKqoiWQJpprxss+ nPrtnw7s+pi/oZRPV77XLYUPq13u2+Lq7eWB2eOlyxFADmq8tqc57Z68S7nd2ZnpNVvTu1VV VZmbxc62AAtHWtIJuZpHtFBRhz21xRXUIiXMtl2A1NgAARGpjRiQ05PkzECAGSAAtYEQRb3b EomP8/PO+tQ+dZ3rvnqqqqqqrGMYxjGK3v0fMZTOb5ddvKc4vOczyZiIiqrm973vdVU3vVc5 zEREWtEc5znOc5zkRERHOYwqNjHp/ece/GyLb2Soc50w3vrwPigekGtR44VE08+eYl3hc7yj 4xbgsfGJUbYVsq0IdsWulxfy5AiITFvaPPqpzIrUPysli7Q0BUQt90XANJcEAAXXvsaBAAFu 9xpb603jMqlbPk8VMIGtnCJgPk44wVE4RERECzyx+xZowb+jjxMIygAAESjl6efVevUDmNjn N16S636bIZwPSyOG4nXrKZy0jMG+a9RGbWgA7VVVVVVUBwyM60zFotnWcZxGcv5pPQY4nw/X j435C9wjni7Zs5rk22tr4hH5WESMvCozPl386tijnNTtjERsOuo3vLgjc49Vr2Ai+4sVhWqD blVUokmxAgDJ4AIjTECKZjJIzbXPTAGs6QGaVMrMJIRECoYoEzzUAOoAu4KLfbNduqrrnGd+ 5wgAuuqz3668V21q80guIqA7zb68ztrrnnnn38Z2Kp4zV7aFUxRSirXE5vUxrXmZzi1ECRVC RFeOq+NQ4nFqfSnxjlFTtBRDvJFQUO/NdcmLuQhrXxz36+fXPP0qqPdABd3R38Xr4961nMFF 7QURGfT3Tkm1FcCD6s9qpzBPyut96A+hJ+FvJ3EFrGb+H7s1qw5uqGY1nyOa80mfT8LfKvy/ NQFRLkREABdvXal8S8cfec6TLvNrciIiIiIzMzMzVVQEsDeNI1vOI1EY3jXfz8/Hrc67VUb5 yPTutPEWaUs+Npa6+JXc0m+GREREC6CAMgCBAqigi0iMgMIKAkiofv81PHv4+Oe3rwIDYALA ABAbABYAAIDYAAs0B0AQGwAWAACA2ACwAAQGwAWAACA2ACwAAQGwAWAACA2ACwAAQGwAWgNg AgNgAsAAEBsAFgAAgNgAsHyXve972v8N0BYRFRve5rVtS6vtiHWDAipiYAF3Qbp9mIAEujRm rkqaN3EWxaYiGvBjD8G1tCeFtWlslski6bJJSNVlCianc0XZME2Vr5IkllYVOFukjuCmJopK XrUrGwy65N3Ts5dOZunIHKraqsdSEdtYHLGLLkM4RbQVy5I5AERN8rNt1UyVtMNzM8q+S7ty 1qQ11fKuZYWS2dNEQBJoizdDLEkpqTKsuSpQQiAJnJRmABAZiINBuABG0omWskkSJMncTIuj LEmUa3M1k+0AF/j7K/akUT84oIH5T+vP6V38e+3r8u/nOPv5KBzwbfjPuV19XwmAbY+oOZna 2evzw+YsL5jB5P9M6uqcu6HrOOXPO3iu0cY4Dju+IdXyLtyNLmsOKmQbjWTbXm6XXj0j9XCV +PyCAAIv9/3fB9wAACJAn9ZAiBDdf2+a/VwG/y/Rvnz8e++8fpjcJ9vxCpm9vB9z5ObHmn2z 71vNpwIv+XPDL+mOdR+3Ns7lSuj6zuZN+UMZTj0c5o+mhxdReqwkbN4zjm8tVmRZx73Pl468 ff08t+z2oK/2gV5wKyBWfrR/YAAAi/V7j/izXsoIAAi9jWvr67rfzz7evtr6+325znOc5zjM zMzc5yqM+ZzmqWI4q8qqqs5znOc1Vc5znOVVPaqqqrERAiIqqqr1VU7s785z/Z3Z3iK39U+j ym9I3LXaet4otZlN5p/LXbYi++m2OnbO9Jic5NObi+O7rmo6t9Y6+rLF7ovC/5unX7hBznkr nk7hOzbKa8raZ8gx53h44n4+4IAAiWxAAAi9lV2AAifuv8//Mfwwfx4/lOQAF9+PFfl+Pr8v u+/1xX8n5Wyf4/LflEqT/OLb/KQe2086Z5fmpXupOMK+KZ3vrM7d06/I7d+2ROqd9vcAAAi4 gPaH+35jyF2efZAAAiTvfa1HnHR1Xq6f0bT57R9+AAAEVqCL2/aCvPPH8vw7IK/fKsmVJTMq o1QVqgr/uF9d7y7dNvL0+fr5c9Pb5eftz89vbt7/dtvjeMo+ftCWlLauupeznq7cG4sgW0P9 6Sa11OrWobe+PmZxs4y44AAACJMrw9a/cIZddocjzC9btd/u79e3k8/dv+QFdXxSJPHf02AV 213b8dPPx3+H6fpAr1+z6gV57wJPiBXDwG/2kAACKvsjfX3/PxvEX8fTqPa3+4+nZPy9rpdN 3w24+8zZNA85Q21yUnPh1XMY61XRuwm+q+8PqFxtDRmwltz+zJrHLxqtLWu9tjUifOH42weE 2eaGNSvNcvzffQVn9Pz7tZr6uUFdpaArIku7C2zb1AVzArmBWoFa02vn9t29NapJb4p9G6Cv LbrtrjIFfhf4qPxeMCvvgV7/ggr663oK/zcPRhCvdv9eYFfX4gVrlntIVkCuYFe9IrnGIJPH bRrAKzIFd/fs/t8Hb51Ar4wK+fdtfDoBJ4agV0xAryQV77Meu9AL9Y/79+uDfjzaipXOPfIg C/pNYAAXuoK5/rpBWa1QK1xsgrp6GoFenhu8jsb+uwFfGBXl9nV7ernx6EJNt5CToBXw7Z6d tfJ4b/5gVzsyBWVVLFVMZPbAKd/0gVu8wK7s40kUP2ePrtzVUtayVMpbYBCLJLYyS2AQhCff UAAktBgKDFQioSSSSSSQhJJJd7AJNkCvltt8IlLaYMkyWSJYxgFaArwu5z4gV1vXnr5OeNb/ DzAr2c68Nu8CTtArtArIFeGvB69b59espPfvxzArYCTfygVu9OKCt3l6EJPpUfdC/fjvoJPn n60qden9d/UCvgBJ+/AC8n1r7QAW39Cbx9CIL/+LuSKcKEhAcOmWAA== --/04w6evG8XlLl3ft-- From owner-freebsd-current@FreeBSD.ORG Sun Apr 10 17:55:39 2005 Return-Path: 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 029D116A4CE; Sun, 10 Apr 2005 17:55:39 +0000 (GMT) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57B8D43D2D; Sun, 10 Apr 2005 17:55:38 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])j3AHtXml022309; Mon, 11 Apr 2005 03:55:33 +1000 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) j3AHtVIo014029; Mon, 11 Apr 2005 03:55:32 +1000 Date: Mon, 11 Apr 2005 03:55:31 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Chuck Swiger In-Reply-To: <42595E04.60705@mac.com> Message-ID: <20050411032601.S55302@delplex.bde.org> References: <200504100251.j3A2pLEH055107@sana.init-main.com> <1892195662.20050410140423@andric.com><42595E04.60705@mac.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Mon, 11 Apr 2005 14:25:47 +0000 cc: freebsd-fs@freebsd.org cc: Daniel Ellard cc: freebsd-current@freebsd.org Subject: Re: smbfs bug introduced at smbfs_vnops.c:1.58 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Apr 2005 17:55:39 -0000 On Sun, 10 Apr 2005, Chuck Swiger wrote: > Daniel Ellard wrote: >> On Sun, 10 Apr 2005, Dimitry Andric wrote: > [ ... ] >> At least the gcc folk now do detect this old chestnut: >> >> { >> int a; >> >> a /= 0; >> } >> >> which was used to provoke arguments in compiler >> classes for many years. (Optimized, nothing happens. >> Unoptimized, a division-by-zero error happens...) > > Great example. > > If the optimized code fails to generate a division-by-zero error here, the > optimizer is buggy. (I won't quote Aho, Sethi, and Ullman again.... :-) No, the behaviour is undefined. The compiler can do anything. gcc now emits a warning even with -O0. A similar example with "double a;" is more interesting. This also gives undefined behaviour (C99 6.5.5[#5]). However, this is bogus if there is a floating point infinity. C99 has support for IEEE floating point and it is clearly intended that the behaviour of 1.0/0.0 is to give +Inf and raise the divide-by-zero exception, but I couldn't see anywhere in the C99 draft n869.txt where this is spelled out (raising of the divide-by-zero exception is spelled out for lots of math functions but doesn't seem to be mentioned for plain division). Also, in C99 with IEEE FP support, "#pragma STDC FENV_ACCESS *" should affect the behaviour. I'm not sure of the details, but think that programs can only depend on getting the divide-by-zero exception if FENV_ACCESS is ON. gcc still doesn't support this pragma, so it does several wrong things with FENV_ACCESS ON: - for "a = 1.0 / 0.0;", it evaluates 1.0 / 0.0 at compile time (even with -O0) so it never raises a divide-by-zero exception. - "a /= 0.0;" where "a" is not otherwise used is not dead code, since it should have the side effect of raising the exception, but gcc considers this code to be dead. Bruce From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 08:26:16 2005 Return-Path: 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 734B716A4F2 for ; Mon, 11 Apr 2005 08:26:16 +0000 (GMT) Received: from tower.berklix.org (bsd.bsn.com [194.221.32.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C94543D46 for ; Mon, 11 Apr 2005 08:26:15 +0000 (GMT) (envelope-from jhs@flat.berklix.net) Received: from js.berklix.net (p549A432F.dip.t-dialin.net [84.154.67.47]) (authenticated bits=0) by tower.berklix.org (8.12.9p2/8.12.9) with ESMTP id j3B8Q58o015249; Mon, 11 Apr 2005 10:26:05 +0200 (CEST) (envelope-from jhs@flat.berklix.net) Received: from fire.jhs.private (fire.jhs.private [192.168.91.41]) by js.berklix.net (8.12.11/8.12.11) with ESMTP id j3B8Q4BQ001389; Mon, 11 Apr 2005 10:26:04 +0200 (CEST) (envelope-from jhs@flat.berklix.net) Received: from fire.jhs.private (localhost [127.0.0.1]) by fire.jhs.private (8.13.1/8.13.1) with ESMTP id j3B8Q4Wr003529; Mon, 11 Apr 2005 10:26:04 +0200 (CEST) (envelope-from jhs@fire.jhs.private) Message-Id: <200504110826.j3B8Q4Wr003529@fire.jhs.private> To: Man Cristian In-Reply-To: Message from Man Cristian <200504111054.18746.cristian@mail.next-computer.ro> Date: Mon, 11 Apr 2005 10:26:04 +0200 From: "Julian H. Stacey" X-Mailman-Approved-At: Mon, 11 Apr 2005 14:25:47 +0000 cc: freebsd-current@freebsd.org Subject: Re: kernel update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 08:26:16 -0000 Man Cristian wrote: > Hello > From where i can download a new version of FreeBDS 6.0 kernel ? Nowhere, It does not exist yet, please read http://www.freebsd.org/releases/ http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.html - Julian Stacey Net & Sys Eng Consultant, Munich http://berklix.com Mail in Ascii (Html=Spam). Ihr Rauch = mein allergischer Kopfschmerz. From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 09:38:14 2005 Return-Path: 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 3EE4516A4CE for ; Mon, 11 Apr 2005 09:38:14 +0000 (GMT) Received: from smp500.sitetronics.com (sitetronics.com [82.192.77.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1A9B43D1D for ; Mon, 11 Apr 2005 09:38:13 +0000 (GMT) (envelope-from dodell@offmyserver.com) Received: from localhost.sitetronics.com ([127.0.0.1] helo=smp500.sitetronics.com) by smp500.sitetronics.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DKvKu-000ExY-UE for freebsd-current@freebsd.org; Mon, 11 Apr 2005 11:36:05 +0200 Received: (from dodell@localhost) by smp500.sitetronics.com (8.12.11/8.12.11/Submit) id j3B9a4sT057507 for freebsd-current@freebsd.org; Mon, 11 Apr 2005 11:36:04 +0200 (CEST) (envelope-from dodell@offmyserver.com) X-Authentication-Warning: smp500.sitetronics.com: dodell set sender to dodell@offmyserver.com using -f Date: Mon, 11 Apr 2005 11:36:03 +0200 From: "Devon H. O'Dell " To: freebsd-current@freebsd.org Message-ID: <20050411093603.GB56515@smp500.sitetronics.com> Mail-Followup-To: freebsd-current@freebsd.org References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dTy3Mrz/UPE2dbVg" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-Mailman-Approved-At: Mon, 11 Apr 2005 14:25:47 +0000 Subject: Re: Potential source of interrupt aliasing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 09:38:14 -0000 --dTy3Mrz/UPE2dbVg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 11, 2005 at 12:34:01PM +0300, Danny Braniss wrote: > ... > > It's a pity that the modern PC is hamstrung by design decisions made > > over 25 years ago. >=20 > sorry, but couldn't help it :-) Urban legend. --Devon --dTy3Mrz/UPE2dbVg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCWkUDSkf3jVXOdl0RAngBAKCItGVJk+XazZQKYwu8niQFsXDp5QCdFIWT Hd3JM/e9DQX4R9eRQ1h7gFQ= =i6fI -----END PGP SIGNATURE----- --dTy3Mrz/UPE2dbVg-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 15:27:48 2005 Return-Path: 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 8B68D16A4CE for ; Mon, 11 Apr 2005 15:27:48 +0000 (GMT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43ABF43D49 for ; Mon, 11 Apr 2005 15:27:48 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) j3BFRl0e050814; Mon, 11 Apr 2005 08:27:47 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id j3BFRlld050811; Mon, 11 Apr 2005 08:27:47 -0700 (PDT) (envelope-from dillon) Date: Mon, 11 Apr 2005 08:27:47 -0700 (PDT) From: Matthew Dillon Message-Id: <200504111527.j3BFRlld050811@apollo.backplane.com> To: Peter Jeremy References: <20050406233405.O47071@carver.gumbysoft.com> <200504081656.51917.jhb@FreeBSD.org> <20050410152946.W82708@carver.gumbysoft.com> <20050410172818.D82708@carver.gumbysoft.com> <200504110231.j3B2VOYr047361@apollo.backplane.com> <20050411083006.GJ89047@cirb503493.alcatel.com.au> cc: freebsd-current@freebsd.org Subject: Re: Potential source of interrupt aliasing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 15:27:48 -0000 :Both the 8080 and 8085 supported vectored interrupts to a limited :extent. The 6800 and 6809 don't support vectored interrupts. The :Z-80, 68000 and 8086 all fully support vectored interrupts. But the :Z-80 and 68000 both need the designer to (exclusively) use the Z-80 or :68000 peripheral chips in order to take advantage of their vectored :interrupts. Using a separate interrupt controller means that you can :use bog-standard peripherals that just have INTR outputs. : :It's a pity that the modern PC is hamstrung by design decisions made :over 25 years ago. : :-- :Peter Jeremy The 68000 had a nice system, and you didn't have to use 68000 peripheral chips to take advantage of it. You could a auto-vector the IACK cycle for certain SPLs (the poor man's solution) or, even better, you could map RAM into the autovector space (basically ignore the FC lines) and then use a simple 8:3 (or other) selector to generate the vector for some or the SPLs for chips that could not generate one themselves. It's sad to know that a single 20 year + old $0.10 14 pin chip can outdo an APIC. -Matt Matthew Dillon From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 15:38:03 2005 Return-Path: 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 5003816A4CE for ; Mon, 11 Apr 2005 15:38:03 +0000 (GMT) Received: from smtp-vbr4.xs4all.nl (smtp-vbr4.xs4all.nl [194.109.24.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9234D43D53 for ; Mon, 11 Apr 2005 15:38:02 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp-vbr4.xs4all.nl (8.12.11/8.12.11) with ESMTP id j3BFbw96027574; Mon, 11 Apr 2005 17:37:58 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.13.3/8.12.9) with ESMTP id j3BFbwHN057225; Mon, 11 Apr 2005 17:37:58 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.13.3/8.13.1/Submit) id j3BFbwm9057224; Mon, 11 Apr 2005 17:37:58 +0200 (CEST) (envelope-from wb) Date: Mon, 11 Apr 2005 17:37:58 +0200 From: Wilko Bulte To: Matthew Dillon Message-ID: <20050411153758.GA57182@freebie.xs4all.nl> References: <20050406233405.O47071@carver.gumbysoft.com> <200504081656.51917.jhb@FreeBSD.org> <20050410152946.W82708@carver.gumbysoft.com> <20050410172818.D82708@carver.gumbysoft.com> <200504110231.j3B2VOYr047361@apollo.backplane.com> <20050411083006.GJ89047@cirb503493.alcatel.com.au> <200504111527.j3BFRlld050811@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504111527.j3BFRlld050811@apollo.backplane.com> X-OS: FreeBSD 4.11-STABLE User-Agent: Mutt/1.5.6i X-Virus-Scanned: by XS4ALL Virus Scanner cc: Peter Jeremy cc: freebsd-current@freebsd.org Subject: Re: Potential source of interrupt aliasing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 15:38:03 -0000 On Mon, Apr 11, 2005 at 08:27:47AM -0700, Matthew Dillon wrote.. > > :Both the 8080 and 8085 supported vectored interrupts to a limited > :extent. The 6800 and 6809 don't support vectored interrupts. The > :Z-80, 68000 and 8086 all fully support vectored interrupts. But the > :Z-80 and 68000 both need the designer to (exclusively) use the Z-80 or > :68000 peripheral chips in order to take advantage of their vectored > :interrupts. Using a separate interrupt controller means that you can > :use bog-standard peripherals that just have INTR outputs. > : > :It's a pity that the modern PC is hamstrung by design decisions made > :over 25 years ago. > : > :-- > :Peter Jeremy > > The 68000 had a nice system, and you didn't have to use 68000 peripheral > chips to take advantage of it. You could a auto-vector the IACK cycle > for certain SPLs (the poor man's solution) or, even better, you could map > RAM into the autovector space (basically ignore the FC lines) and then > use a simple 8:3 (or other) selector to generate the vector for some or > the SPLs for chips that could not generate one themselves. > > It's sad to know that a single 20 year + old $0.10 14 pin chip can outdo > an APIC. The 68k series were much nicer CPUs than Intel built. Too nice apparantly for IBM to put them into the first PC prototypes. The rest is history :-( -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 15:46:10 2005 Return-Path: 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 9541B16A4CE for ; Mon, 11 Apr 2005 15:46:10 +0000 (GMT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id C571343D45 for ; Mon, 11 Apr 2005 15:46:09 +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.1/8.13.1) with ESMTP id j3BFk3bj017349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Apr 2005 11:46:03 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id j3BFjlkG002518; Mon, 11 Apr 2005 11:45:47 -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: <16986.39851.597421.478406@grasshopper.cs.duke.edu> Date: Mon, 11 Apr 2005 11:45:47 -0400 (EDT) To: Scott Long In-Reply-To: <425A10DD.70500@samsco.org> References: <20050406233405.O47071@carver.gumbysoft.com> <200504081656.51917.jhb@FreeBSD.org> <20050410152946.W82708@carver.gumbysoft.com> <20050410172818.D82708@carver.gumbysoft.com> <200504110231.j3B2VOYr047361@apollo.backplane.com> <425A10DD.70500@samsco.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: freebsd-current@freebsd.org Subject: Re: Potential source of interrupt aliasing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 15:46:10 -0000 Scott Long writes: > > See also: sbus(4), msi(4). > > MSI is something that I'd like to work on, but simply had the time. > It's not a panacea since it will only work for MSI-enabled PCI devices, > but many peripherals found on these Intel systems fall into that > category. Bear in mind that MSI is another can of worms. I spent some time last month getting MSI interrupts working for our linux driver. I had the misfortune to start with a system (ServerWorks GC-SL based) which did not even support MSIs, but where linux let my driver enable MSI operation and allocate MSI interrupts. Any DMA to the address given by the linux MSI code resulted in a PCI master abort. That was not fun.. If/when we do MSI support, I really hope we do a better job of determining if MSIs actually work before enabling them ;) Drew From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 15:59:49 2005 Return-Path: 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 5EFB916A4CE for ; Mon, 11 Apr 2005 15:59:49 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83BFE43D4C for ; Mon, 11 Apr 2005 15:59:46 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j3BG386U031568; Mon, 11 Apr 2005 10:03:08 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <425A9E30.7080401@samsco.org> Date: Mon, 11 Apr 2005 09:56:32 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Gallatin References: <20050406233405.O47071@carver.gumbysoft.com> <200504081656.51917.jhb@FreeBSD.org> <20050410152946.W82708@carver.gumbysoft.com> <20050410172818.D82708@carver.gumbysoft.com> <200504110231.j3B2VOYr047361@apollo.backplane.com> <425A10DD.70500@samsco.org> <16986.39851.597421.478406@grasshopper.cs.duke.edu> In-Reply-To: <16986.39851.597421.478406@grasshopper.cs.duke.edu> 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 Subject: Re: Potential source of interrupt aliasing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 15:59:49 -0000 Andrew Gallatin wrote: > Scott Long writes: > > > > See also: sbus(4), msi(4). > > > > MSI is something that I'd like to work on, but simply had the time. > > It's not a panacea since it will only work for MSI-enabled PCI devices, > > but many peripherals found on these Intel systems fall into that > > category. > > Bear in mind that MSI is another can of worms. > > I spent some time last month getting MSI interrupts working for our > linux driver. I had the misfortune to start with a system > (ServerWorks GC-SL based) which did not even support MSIs, but where > linux let my driver enable MSI operation and allocate MSI interrupts. > Any DMA to the address given by the linux MSI code resulted in a PCI > master abort. That was not fun.. > > If/when we do MSI support, I really hope we do a better job of determining > if MSIs actually work before enabling them ;) > > Drew > > > I'm a little confused by this. Between the Intel architecture manuals and the PCI specs, it seems like MSI is a function of the PCI device mastering a 32 or 64-bit word into a specific location in host memory. On the intel architecture, that location is in an area that the L-APICs will sniff and treat as a kind of virtual IOAPIC. Maybe you're not actually hitting real RAM and instead there is Host Bridge magic going on, but the Intel manuals don't really talk at all about that. The Linux MSI support was written by Intel so I'm sure they tailored it for Intel chipsets and didn't care much about ServerWorks chipsets. Maybe this is yet another reason why we need to start seriously thinking about chipset drivers in FreeBSD. Scott From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 16:13:27 2005 Return-Path: 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 D8F2116A4CE for ; Mon, 11 Apr 2005 16:13:27 +0000 (GMT) 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 2A7DD43D2F for ; Mon, 11 Apr 2005 16:13:27 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.13.3/8.13.3) with ESMTP id j3BGDOf7033446; Mon, 11 Apr 2005 18:13:24 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <425AA1C2.8090801@DeepCore.dk> Date: Mon, 11 Apr 2005 18:11:46 +0200 From: =?ISO-8859-15?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Reifenberger References: <20050410164959.G38200@fw.reifenberger.com> <42597A6D.8080801@DeepCore.dk> <20050410212444.H25065@fw.reifenberger.com> <425A380D.5030400@DeepCore.dk> <20050411154520.M33433@fw.reifenberger.com> In-Reply-To: <20050411154520.M33433@fw.reifenberger.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable X-mail-scanned: by DeepCore Virus & Spam killer v1.12 cc: FreeBSD-Current Subject: Re: SATA with new ata code doesn't work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 16:13:28 -0000 Michael Reifenberger wrote: > On Mon, 11 Apr 2005, S=F8ren Schmidt wrote: > ... >=20 >>>> Yes, the problem is that the alloc_resource fails on the last=20 >>>> resource (0xb4000-0xb4ff) for some unknown reason. >>>> I've given up finding this remotely and have ordered a VIA based=20 >>>> motherboard that I'm picking up tomorrow, then I'm sure I can have=20 >>>> fix ready soon... >>>> >> >> Warner has committed an update to the PCI code, could you please try=20 >> it out and get back to me we the result ? >> >=20 > Not before 21:00 CEST Do worry, I've got my own VIA based system now, I'll get a fix done ASAP.= =2E --=20 -S=F8ren From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 16:13:35 2005 Return-Path: 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 4A81C16A4ED; Mon, 11 Apr 2005 16:13:35 +0000 (GMT) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id DEC2043D2F; Mon, 11 Apr 2005 16:13:34 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id IBA74465; Mon, 11 Apr 2005 09:13:34 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 53EF45D08; Mon, 11 Apr 2005 09:13:34 -0700 (PDT) To: Wiktor Niesiobedzki In-reply-to: Your message of "Sun, 10 Apr 2005 13:12:02 +0200." <20050410111202.GA5980@dln55.neoplus.adsl.tpnet.pl> Date: Mon, 11 Apr 2005 09:13:34 -0700 From: "Kevin Oberman" Message-Id: <20050411161334.53EF45D08@ptavv.es.net> cc: current@freebsd.org cc: sos@freebsd.org Subject: Re: ATA MkIII - Hang after resume solution X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 16:13:35 -0000 > Date: Sun, 10 Apr 2005 13:12:02 +0200 > From: Wiktor Niesiobedzki > Sender: owner-freebsd-current@freebsd.org > > Hi, > > I think I found solution to the problem, that after MkIII disks does not > reinit. Solution is simple: > > --- /usr/src/sys/dev/ata/ata-pci.c Fri Apr 8 11:37:47 2005 > +++ /tmp/ata-pci.c Sun Apr 10 13:09:48 2005 > @@ -599,8 +599,8 @@ > DEVMETHOD(device_attach, ata_pcichannel_attach), > DEVMETHOD(device_detach, ata_pcichannel_detach), > DEVMETHOD(device_shutdown, bus_generic_shutdown), > - DEVMETHOD(device_suspend, bus_generic_suspend), > - DEVMETHOD(device_resume, bus_generic_resume), > + DEVMETHOD(device_suspend, ata_suspend), > + DEVMETHOD(device_resume, ata_resume), > > /* ATA methods */ > DEVMETHOD(ata_setmode, ata_pcichannel_setmode), > > This is rollback of changes introduced by MkIII. After that change > suspend/resume works again. > > Can anybody review this? Sorry, but I have been on the road and couldn't test until this morning. ata is now resuming again and I can can now successfully suspend and resume my ThinkPad T30. I have tried suspending and resuming both in console mode and in X. Everything appears to re running as it did prior to MkIII except the slight oddity that the cd (atapicam) now does not probe until after root is mounted. If I boot single user, the probe messages pop up after I am asked for the shell to be run. This does not seem to have any impact on things. It's just that I have never seen probes for devices present at boot show up after root is mounted. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 16:18:57 2005 Return-Path: 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 995A416A4CF for ; Mon, 11 Apr 2005 16:18:57 +0000 (GMT) Received: from pne-smtpout2-sn1.fre.skanova.net (pne-smtpout2-sn1.fre.skanova.net [81.228.11.159]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23DB843D1F for ; Mon, 11 Apr 2005 16:18:57 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: from sentinel (195.198.193.104) by pne-smtpout2-sn1.fre.skanova.net (7.1.026.7) id 41E3209600B06F7F; Mon, 11 Apr 2005 18:18:55 +0200 From: "Daniel Eriksson" To: "'Kevin Oberman'" Date: Mon, 11 Apr 2005 18:18:52 +0200 Organization: Home Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <20050411161334.53EF45D08@ptavv.es.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcU+sY1Ci69ywAsHRnOsgG1d4tytgwAAEVQg cc: current@freebsd.org Subject: RE: ATA MkIII - Hang after resume solution X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 16:18:57 -0000 Kevin Oberman wrote: > Everything appears to re running as it did prior to MkIII except the > slight oddity that the cd (atapicam) now does not probe until > after root > is mounted. Could this be related to the fact that ata now is modularized? Have you removed any ata devices from the kernel config compared to GENERIC? /Daniel Eriksson From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 16:56:46 2005 Return-Path: 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 6736F16A4CE for ; Mon, 11 Apr 2005 16:56:46 +0000 (GMT) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4149C43D4C for ; Mon, 11 Apr 2005 16:56:46 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id IBA74465; Mon, 11 Apr 2005 09:56:45 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id C5CEA5D07; Mon, 11 Apr 2005 09:56:45 -0700 (PDT) To: "Daniel Eriksson" In-reply-to: Your message of "Mon, 11 Apr 2005 18:18:52 +0200." Date: Mon, 11 Apr 2005 09:56:45 -0700 From: "Kevin Oberman" Message-Id: <20050411165645.C5CEA5D07@ptavv.es.net> cc: current@freebsd.org Subject: Re: ATA MkIII - Hang after resume solution X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 16:56:46 -0000 > From: "Daniel Eriksson" > Date: Mon, 11 Apr 2005 18:18:52 +0200 > > Kevin Oberman wrote: > > > Everything appears to re running as it did prior to MkIII except the > > slight oddity that the cd (atapicam) now does not probe until > > after root > > is mounted. > > Could this be related to the fact that ata now is modularized? Have you > removed any ata devices from the kernel config compared to GENERIC? Daniel, Thanks for the suggestion. It caused me to look at diffs between my kernel and GENERIC for the first time since I started running 5 CURRENT at least two years ago. Not too surprisingly, I had missed a couple of things. In regard to this, I don't have ataraid, atapifd, or atapist in my kernel. I don't see why this should have any impact. I am not loading any ata or atapi modules (checked with kldstat). atapicam0 and atapicam1 are both probing normally. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 17:16:50 2005 Return-Path: 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 2470216A4CE for ; Mon, 11 Apr 2005 17:16:50 +0000 (GMT) Received: from melusine.cuivre.fr.eu.org (melusine.cuivre.fr.eu.org [82.225.155.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id B03C143D46 for ; Mon, 11 Apr 2005 17:16:49 +0000 (GMT) (envelope-from thomas@FreeBSD.ORG) Received: by melusine.cuivre.fr.eu.org (Postfix, from userid 1000) id 1B3C22C3D0; Mon, 11 Apr 2005 19:17:04 +0200 (CEST) Date: Mon, 11 Apr 2005 19:17:04 +0200 From: Thomas Quinot To: Thierry Herbelot Message-ID: <20050411171704.GA1271@melusine.cuivre.fr.eu.org> References: <200504101640.23906.thierry@herbelot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504101640.23906.thierry@herbelot.com> X-message-flag: WARNING! Using Outlook can damage your computer. User-Agent: Mutt/1.5.8i cc: bzeeb+freebsd+lor@zabbadoz.net cc: current@freebsd.org Subject: Re: new LOR report X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 17:16:50 -0000 * Thierry Herbelot, 2005-04-10 : > This LOR also seems not to have been reported : Just saw exactly the same on a -CURRENT tree cvsupped today (too bad, I wanted to test my ATAPI/CAM updates...) Thomas. From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 17:36:22 2005 Return-Path: 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 2475A16A4CE for ; Mon, 11 Apr 2005 17:36:22 +0000 (GMT) Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 561D243D5A for ; Mon, 11 Apr 2005 17:36:21 +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.3/8.13.3) with ESMTP id j3BHaKDE018912; Mon, 11 Apr 2005 21:36:20 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.3/8.13.3/Submit) id j3BHaJKY018911; Mon, 11 Apr 2005 21:36:19 +0400 (MSD) (envelope-from ache) Date: Mon, 11 Apr 2005 21:36:19 +0400 From: Andrey Chernov To: Vladimir Kushnir Message-ID: <20050411173619.GB18590@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Vladimir Kushnir , current@FreeBSD.ORG References: <20050411004706.I2914@kushnir1.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050411004706.I2914@kushnir1.kiev.ua> User-Agent: Mutt/1.5.9i X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-3; AVE: 6.30.0.7; VDF: 6.30.0.81; host: nagual.pp.ru) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (nagual.pp.ru [0.0.0.0]); Mon, 11 Apr 2005 21:36:20 +0400 (MSD) cc: current@FreeBSD.ORG Subject: Re: -CURRENT and ptsname() again X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 17:36:22 -0000 On Mon, Apr 11, 2005 at 01:09:13AM +0300, Vladimir Kushnir wrote: > It definitely looks like posix_openpt (perhaps) and ptsname/grantpt > (most probably) do not work as they should under -CURRENT. Examples: mc > ~> ./ptytest > Fail: grantpt > Open master: /dev/ptyp0, slave: /dev/ttysu > ^^^^^^^^^^ > Sorry, cannot fix it myself Try to mail phk directly, his last rounds of changes in that area may cause this. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 18:06:09 2005 Return-Path: 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 467E916A4CE for ; Mon, 11 Apr 2005 18:06:09 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C0DE43D5F for ; Mon, 11 Apr 2005 18:06:08 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j3BI4iLJ015761; Mon, 11 Apr 2005 12:04:44 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 11 Apr 2005 12:04:49 -0600 (MDT) Message-Id: <20050411.120449.45665227.imp@bsdimp.com> To: dillon@apollo.backplane.com From: "M. Warner Losh" In-Reply-To: <200504110231.j3B2VOYr047361@apollo.backplane.com> References: <20050410152946.W82708@carver.gumbysoft.com> <20050410172818.D82708@carver.gumbysoft.com> <200504110231.j3B2VOYr047361@apollo.backplane.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: Potential source of interrupt aliasing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 18:06:09 -0000 In message: <200504110231.j3B2VOYr047361@apollo.backplane.com> Matthew Dillon writes: : * PCI busses only have 4 interrupt lines (A, B, C, and D). PCI Slots have only 4 interrupts. The BUS can have the interrupt lines wired in an arbitrary manner. That's why we need to have $PIR parsing. Warner From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 18:29:18 2005 Return-Path: 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 BF0F716A4CE; Mon, 11 Apr 2005 18:29:18 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2344243D48; Mon, 11 Apr 2005 18:29:18 +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 j3BITHos021457; Mon, 11 Apr 2005 14:29: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 j3BITO44039499; Mon, 11 Apr 2005 14:29:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 959BC7306E; Mon, 11 Apr 2005 14:29:17 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050411182917.959BC7306E@freebsd-current.sentex.ca> Date: Mon, 11 Apr 2005 14:29:17 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.82, clamav-milter version 0.82 on clamscanner2 X-Virus-Status: Clean Subject: [current tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2005 18:29:18 -0000 TB --- 2005-04-11 17:10:17 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-11 17:10:17 - starting CURRENT tinderbox run for powerpc/powerpc TB --- 2005-04-11 17:10:17 - checking out the source tree TB --- 2005-04-11 17:10:17 - cd /home/tinderbox/CURRENT/powerpc/powerpc TB --- 2005-04-11 17:10:17 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-11 17:16:59 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-11 17:16:59 - cd /home/tinderbox/CURRENT/powerpc/powerpc/src TB --- 2005-04-11 17:16: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-04-11 18:25:35 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-11 18:25:35 - cd /home/tinderbox/CURRENT/powerpc/powerpc/src TB --- 2005-04-11 18:25:35 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Apr 11 18:25:35 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 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/powerpc/powerpc/src/sys -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/altq -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/pf -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Wno-error /tinderbox/CURRENT/powerpc/powerpc/src/sys/powerpc/powermac/uninorth.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 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/powerpc/powerpc/src/sys -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/altq -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/pf -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Wno-error /tinderbox/CURRENT/powerpc/powerpc/src/sys/powerpc/psim/iobus.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 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/powerpc/powerpc/src/sys -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/altq -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/pf -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Wno-error /tinderbox/CURRENT/powerpc/powerpc/src/sys/powerpc/psim/ata_iobus.c /tinderbox/CURRENT/powerpc/powerpc/src/sys/powerpc/psim/ata_iobus.c: In function `ata_iobus_alloc_resource': /tinderbox/CURRENT/powerpc/powerpc/src/sys/powerpc/psim/ata_iobus.c:171: error: `ATA_ALTADDR_RID' undeclared (first use in this function) /tinderbox/CURRENT/powerpc/powerpc/src/sys/powerpc/psim/ata_iobus.c:171: error: (Each undeclared identifier is reported only once /tinderbox/CURRENT/powerpc/powerpc/src/sys/powerpc/psim/ata_iobus.c:171: error: for each function it appears in.) /tinderbox/CURRENT/powerpc/powerpc/src/sys/powerpc/psim/ata_iobus.c:174: error: `ATA_ALTIOSIZE' undeclared (first use in this function) *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/obj/powerpc/tinderbox/CURRENT/powerpc/powerpc/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. TB --- 2005-04-11 18:29:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-11 18:29:17 - ERROR: failed to build generic kernel TB --- 2005-04-11 18:29:17 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 18:50:18 2005 Return-Path: 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 E9B9716A4CE; Mon, 11 Apr 2005 18:50:18 +0000 (GMT) Received: from sp.dominia.org (efnet-math.org [69.60.109.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5351443D3F; Mon, 11 Apr 2005 18:50:18 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from [192.168.1.12] (63-170-138-118.cst-sg.blacksburg.ntc-com.net [63.170.138.118]) (authenticated bits=0) by sp.dominia.org (8.13.1/8.13.1) with ESMTP id j3BIoFGO018708 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 11 Apr 2005 14:50:16 -0400 In-Reply-To: <20050411182917.959BC7306E@freebsd-current.sentex.ca> References: <20050411182917.959BC7306E@freebsd-current.sentex.ca> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Suleiman Souhlal Date: Mon, 11 Apr 2005 14:50:06 -0400 To: FreeBSD Tinderbox X-Mailer: Apple Mail (2.619.2) cc: powerpc@FreeBSD.org cc: current@FreeBSD.org Subject: Re: [current tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 18:50:19 -0000 On Apr 11, 2005, at 2:29 PM, FreeBSD Tinderbox wrote: > /tinderbox/CURRENT/powerpc/powerpc/src/sys/powerpc/psim/ata_iobus.c: > In function `ata_iobus_alloc_resource': > /tinderbox/CURRENT/powerpc/powerpc/src/sys/powerpc/psim/ata_iobus.c: > 171: error: `ATA_ALTADDR_RID' undeclared (first use in this function) > /tinderbox/CURRENT/powerpc/powerpc/src/sys/powerpc/psim/ata_iobus.c: > 171: error: (Each undeclared identifier is reported only once > /tinderbox/CURRENT/powerpc/powerpc/src/sys/powerpc/psim/ata_iobus.c: > 171: error: for each function it appears in.) > /tinderbox/CURRENT/powerpc/powerpc/src/sys/powerpc/psim/ata_iobus.c: > 174: error: `ATA_ALTIOSIZE' undeclared (first use in this function) > *** Error code 1 The patch at http://people.freebsd.org/~ssouhlal/waiting/ata_iobus.diff fixes this. I'm just waiting for grehan@'s approval to commit it. -- Suleiman Souhlal | ssouhlal@vt.edu The FreeBSD Project | ssouhlal@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 19:49:09 2005 Return-Path: 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 8390216A4CE; Mon, 11 Apr 2005 19:49:09 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1ACA43D31; Mon, 11 Apr 2005 19:49:08 +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 j3BJn8Qt027288; Mon, 11 Apr 2005 15:49:08 -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 j3BJn8dQ071707; Mon, 11 Apr 2005 15:49:08 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 4085D7306E; Mon, 11 Apr 2005 15:49:08 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050411194908.4085D7306E@freebsd-current.sentex.ca> Date: Mon, 11 Apr 2005 15:49:08 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on clamscanner1 X-Virus-Status: Clean Subject: [current tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2005 19:49:09 -0000 TB --- 2005-04-11 18:29:17 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-11 18:29:17 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2005-04-11 18:29:17 - checking out the source tree TB --- 2005-04-11 18:29:17 - cd /home/tinderbox/CURRENT/sparc64/sparc64 TB --- 2005-04-11 18:29:17 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-11 18:36:03 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-11 18:36:03 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-04-11 18:36:03 - /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-04-11 19:43:07 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-11 19:43:07 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-04-11 19:43:07 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Apr 11 19:43: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 >>> stage 3.2: building everything [...] vnode_if.c: In function `VOP_SETEXTATTR_APV': vnode_if.c:2649: warning: nested extern declaration of `ASSERT_VOP_ELOCKED' vnode_if.c:205: warning: redundant redeclaration of 'ASSERT_VOP_ELOCKED' vnode_if.c:205: warning: previous implicit declaration of 'ASSERT_VOP_ELOCKED' was here vnode_if.c: In function `VOP_SETLABEL_APV': vnode_if.c:2703: warning: nested extern declaration of `ASSERT_VOP_ELOCKED' vnode_if.c:205: warning: redundant redeclaration of 'ASSERT_VOP_ELOCKED' vnode_if.c:205: warning: previous implicit declaration of 'ASSERT_VOP_ELOCKED' was here *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2005-04-11 19:49:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-11 19:49:08 - ERROR: failed to build generic kernel TB --- 2005-04-11 19:49:08 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 22:40:25 2005 Return-Path: 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 D814116A4CF; Mon, 11 Apr 2005 22:40:25 +0000 (GMT) Received: from rdsmtp.iglou.com (rdsmtp.iglou.com [192.107.41.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52A3A43D5C; Mon, 11 Apr 2005 22:40:25 +0000 (GMT) (envelope-from dlevitch@iglou.com) Received: from [192.107.41.8] (helo=iglou2.iglou.com) by rdsmtp.iglou.com with esmtp (8.12.5/8.12.5) id 1DL7Zw-00050S-LI; Mon, 11 Apr 2005 18:40:24 -0400 Received: from [192.107.41.17] (helo=shell1) by iglou2.iglou.com with esmtp (8.12.5/8.12.5) id 1DL7Zu-0001uW-2L; Mon, 11 Apr 2005 18:40:22 -0400 Date: Mon, 11 Apr 2005 18:40:22 -0400 (EDT) From: Darrel X-X-Sender: dlevitch@shell1 To: Daniel O'Connor In-Reply-To: <200504111022.06861.doconnor@gsoft.com.au> Message-ID: References: <200504111022.06861.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Originating-IP: 192.107.41.17 X-IgLou-Customer: verified cc: freebsd-current@freebsd.org cc: freebsd-questions@freebsd.org Subject: Re: can't cd to /usr/obj/usr/src/sys/BIGD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 22:40:26 -0000 Thanks for your input. I read the handbook and am certain to understand more of it next time. It was my first kernel build- did not survive very long. Darrel On Mon, 11 Apr 2005, Daniel O'Connor wrote: > I've redirected this to freebsd-questions which is more relevant. > > On Sat, 9 Apr 2005 17:01, Darrel wrote: >> make buildworld >> exit >> script /var/tmp/bk.out >> make buildkernel KERNCONF=BIGD >> exit > > Did these succeed? > You didn't cd into /usr/src first so I don't see how they can have worked.. > >> - Rebooted to single user >> fsck -p > > Why run fsck? > >> mount -u / >> mount -a -t ufs > > mount -a is fine here (unless you have NFS in fstab) > >> swapon -a >> make installkernel KERNCONF=BIGD >> error code don't know how to make bsd.README > > You aren't in /usr/src? > > Did you read the handbook on this stuff? > > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 22:41:45 2005 Return-Path: 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 9317016A4CE for ; Mon, 11 Apr 2005 22:41:45 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.194.102.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3969A43D5D for ; Mon, 11 Apr 2005 22:41:45 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 7BB97514DB; Mon, 11 Apr 2005 15:41:42 -0700 (PDT) Date: Mon, 11 Apr 2005 15:41:42 -0700 From: Kris Kennaway To: Jeff Roberson Message-ID: <20050411224141.GA64750@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mYCpIKhGyMATD0i+" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i cc: current@freeBSD.org Subject: 'panic: lockmgr: upgrade exclusive lock' when rebooting X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 22:41:45 -0000 --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Running 6.0 from a few days ago, so you may have already fixed this. Apr 12 07:37:45 haessal reboot: rebooted by root Apr 12 07:37:47 haessal syslogd: exiting Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop...timed out Waiting (max 60 seconds) for system process `bufdaemon' to stop...done panic: lockmgr: upgrade exclusive lock cpuid = 0 KDB: enter: panic [thread pid 92797 tid 100297 ] Stopped at kdb_enter+0x30: leave db> wh Tracing pid 92797 tid 100297 td 0xc3b30600 kdb_enter(c0741b61,0,c073fd33,ee2f6ac4,c3b30600) at kdb_enter+0x30 panic(c073fd33,0,c073fc14,b5,c89d3670) at panic+0x13e debuglockmgr(c89d3670,2004,c89d36b0,c3b30600,c074ad3e) at debuglockmgr+0x336 vop_stdlock(ee2f6bb8,8,c3b30600,ee2f6b58,c054f845) at vop_stdlock+0x4e VOP_LOCK_APV(c0790c40,ee2f6bb8,ee2f6ba0,c07117a5,ee2f6bb8) at VOP_LOCK_APV+0x9e ffs_lock(ee2f6bb8,c0762ba4,36,c0762b83,c89d3618) at ffs_lock+0x19 VOP_LOCK_APV(c07906e0,ee2f6bb8,c074b5e7,782,c079f9c0) at VOP_LOCK_APV+0x9e vput(c89d3618,2,c07a5cc0,454,c3615860) at vput+0x15c ffs_sync(c3615800,2,c07a5cc0,c07a5cc0,c3615800) at ffs_sync+0x1dd sync(c07a5cc0,0,c0741b85,10d,c055cb74) at sync+0x100 boot(0,0,c0741b85,a2,ee2f6d40) at boot+0x2a1 reboot(c3b30600,ee2f6d14,3a6,c075ef20,c3b30600) at reboot+0x47 syscall(2f,2f,2f,1c,0) at syscall+0x2c4 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (55, FreeBSD ELF32, reboot), eip = 0x280a779f, esp = 0xbfbfec1c, ebp = 0xbfbfec74 --- db> show lockedvnods Locked vnodes panic: _mtx_lock_sleep: recursed on non-recursive mutex lockbuilder mtxpool @ ../../../kern/kern_lock.c:540 cpuid = 0 Uptime: 1d17h30m4s Dumping 2047 MB Dump failed. Partition too small. Automatic reboot in 15 seconds - press a key on the console to abort (Dammit) Kris --mYCpIKhGyMATD0i+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCWv0lWry0BWjoQKURAsZoAJ9cSMWzuM+JSOiOlAy2OalEmQACaQCfe8DH trEFgQMJjOJWo16eiUOh1cE= =0Jv3 -----END PGP SIGNATURE----- --mYCpIKhGyMATD0i+-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 22:59:14 2005 Return-Path: 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 5022516A4CE for ; Mon, 11 Apr 2005 22:59:14 +0000 (GMT) Received: from rdsmtp.iglou.com (rdsmtp.iglou.com [192.107.41.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08F7D43D53 for ; Mon, 11 Apr 2005 22:59:14 +0000 (GMT) (envelope-from dlevitch@iglou.com) Received: from [192.107.41.6] (helo=iglou3.iglou.com) by rdsmtp.iglou.com with esmtp (8.12.5/8.12.5) id 1DL7s9-0007J9-Kk for freebsd-current@freebsd.org; Mon, 11 Apr 2005 18:59:13 -0400 Received: from [192.107.41.17] (helo=shell1) by iglou3.iglou.com with esmtp (8.12.5/8.12.5) id 1DL7s9-0006jG-CX for freebsd-current@freebsd.org; Mon, 11 Apr 2005 18:59:13 -0400 Date: Mon, 11 Apr 2005 18:59:13 -0400 (EDT) From: Darrel X-X-Sender: dlevitch@shell1 To: freebsd-current@freebsd.org In-Reply-To: <20050411032917.GA1529@dragon.NUXI.org> Message-ID: References: <20050411032917.GA1529@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Originating-IP: 192.107.41.17 X-IgLou-Customer: verified Subject: Re: gnome upgrade on GENERIC i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 22:59:14 -0000 I eventually made a /home/Darrel/tmp; i.e., /tmp was too small as well. My gnome upgrade was a disaster, probably from a damaged kernel- I am not sure. I should not have accepted the default partition sizes. This computer not doing well and I switched it to NetBSD a change of scenery. Just finished configuring the network, x, and installed rdesktop and netscape. But today I installed FreeBSD and configured Samba at work- great documents! Thanks a lot! Zyxel GN670-T ethernet adapter works great with FreeBSD 5.3 Darrel On Sun, 10 Apr 2005, David O'Brien wrote: > On Sun, Apr 10, 2005 at 02:27:37PM -0400, Darrel wrote: >> Can I delete all of the files in /var/tmp? I am not sure if any of them >> are necessary: >> >> epiphany >> f-prot >> gconfd >> installkernel >> orbit >> packlists- several >> temproot > > This looks like someone manually using /var/tmp when they probably wanted > /tmp. > >> vi.recover > > This one is necessary. > > -- > -- David (obrien@FreeBSD.org) > _______________________________________________ > 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 Mon Apr 11 23:45:16 2005 Return-Path: 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 3E38A16A4CE for ; Mon, 11 Apr 2005 23:45:16 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.194.102.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id E75A343D55 for ; Mon, 11 Apr 2005 23:45:15 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 3921951326; Mon, 11 Apr 2005 16:45:12 -0700 (PDT) Date: Mon, 11 Apr 2005 16:45:12 -0700 From: Kris Kennaway To: current@FreeBSD.org Message-ID: <20050411234512.GA23344@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="W/nzBZO5zC0uMSeA" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: Softupdates not preventing lengthy fsck X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 11 Apr 2005 23:45:16 -0000 --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I'm seeing the following problem: on 6.0 machines which have had a lot of FS activity in the past but are currently quiet, an unclean reboot will require an hour or more of fscking and will end up clearing thousands of inodes: [...] /dev/da0s1e: UNREF FILE I=269731 OWNER=root MODE=100644 /dev/da0s1e: SIZE=8555 MTIME=Apr 18 02:29 2002 (CLEARED) /dev/da0s1e: UNREF FILE I=269732 OWNER=root MODE=100644 /dev/da0s1e: SIZE=3281 MTIME=Mar 18 07:48 2000 (CLEARED) /dev/da0s1e: UNREF FILE I=269733 OWNER=root MODE=100644 /dev/da0s1e: SIZE=4252 MTIME=Mar 18 07:48 2000 (CLEARED) /dev/da0s1e: UNREF FILE I=269734 OWNER=root MODE=100644 /dev/da0s1e: SIZE=4252 MTIME=Mar 18 07:48 2000 (CLEARED) /dev/da0s1e: UNREF FILE I=269735 OWNER=root MODE=100644 /dev/da0s1e: SIZE=4252 MTIME=Mar 18 07:48 2000 (CLEARED) /dev/da0s1e: UNREF FILE I=269736 OWNER=root MODE=100644 /dev/da0s1e: SIZE=1346 MTIME=Mar 18 07:48 2000 (CLEARED) /dev/da0s1e: UNREF FILE I=269737 OWNER=root MODE=100644 /dev/da0s1e: SIZE=7573 MTIME=Mar 18 07:48 2000 (CLEARED) /dev/da0s1e: UNREF FILE I=269738 OWNER=root MODE=100644 /dev/da0s1e: SIZE=7272 MTIME=Mar 18 07:48 2000 (CLEARED) /dev/da0s1e: UNREF FILE I=269739 OWNER=root MODE=100644 /dev/da0s1e: SIZE=4076 MTIME=Mar 18 07:48 2000 (CLEARED) /dev/da0s1e: UNREF FILE I=269740 OWNER=root MODE=100644 /dev/da0s1e: SIZE=20471 MTIME=Mar 18 07:48 2000 (CLEARED) /dev/da0s1e: UNREF FILE I=269741 OWNER=root MODE=100644 [...] It's as if dirty buffers aren't being written out properly, or something. Has anyone else seen this? Kris --W/nzBZO5zC0uMSeA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCWwwIWry0BWjoQKURAu3BAJ4tTB/+yuamDywhpNeapzi3+yVcGwCgzU1G dsIeCcdaqszvMde0k4SdSbw= =OSm4 -----END PGP SIGNATURE----- --W/nzBZO5zC0uMSeA-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 00:21:04 2005 Return-Path: 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 B16DF16A4CE for ; Tue, 12 Apr 2005 00:21:04 +0000 (GMT) Received: from mail22.sea5.speakeasy.net (mail22.sea5.speakeasy.net [69.17.117.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B7B143D39 for ; Tue, 12 Apr 2005 00:21:04 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 4196 invoked from network); 12 Apr 2005 00:21:03 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 12 Apr 2005 00:21:03 -0000 Received: from [131.106.57.68] (p178.n-lapop01.stsn.com [12.129.240.178]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j3C0KXGw016395; Mon, 11 Apr 2005 20:20:55 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Matthew Dillon Date: Mon, 11 Apr 2005 20:17:17 -0400 User-Agent: KMail/1.8 References: <20050406233405.O47071@carver.gumbysoft.com> <20050410172818.D82708@carver.gumbysoft.com> <200504110231.j3B2VOYr047361@apollo.backplane.com> In-Reply-To: <200504110231.j3B2VOYr047361@apollo.backplane.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504112017.18815.jhb@FreeBSD.org> X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: freebsd-current@FreeBSD.org Subject: Re: Potential source of interrupt aliasing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 12 Apr 2005 00:21:04 -0000 On Sunday 10 April 2005 10:31 pm, Matthew Dillon wrote: > :> *BUT* it *IS* possible that the wrong APIC vector is being masked > :> (and not because of an interrupt alias, but because the actual hard > :> interrupt is misrouted). > : > :I don't think this is the case. Somehow the vector would have to get > :corrupted during this function call, which is line 609 in > :src/sys/i386/i386/local_apic.c: > : > :isrc = intr_lookup_source(apic_idt_to_irq(frame.if_vec)); > > The vector is not being corrupted at all. Just put that out of your > mind... the APIC is working just fine. The problem is most likely > that the device is asserting the interrupt on the WRONG PIN. Since > the wrong IRQ is asserted, the wrong APIC vector is dispatched, the > wrong interrupt handler and ithread is run, and the source from the > device that actually generated the interrupt is NOT cleared (because > it isn't the device that the system thinks generated the interrupt). That's not the case here. This only happens on specific systems and Linux on the same systems does not see the aliasing presumably because Linux doesn't use interrupt threads and thus doesn't have to mask interrupt lines in the APIC. > You do route interrupts in APIC mode. I wish it were a flat space! It > isn't. Err, no, Doug is right. Except for some nForce chipsets, all APIC interrupts are hardwired. The ACPI _PRT entry has a null source meaning that the associated index is a global interrupt number where global interrupts are allocated consecutively across APICs. The MADT table contains the base interrupt number for pin 0 on each I/O APIC. This really does work fine for almost all systems out there now. For the !ACPI case we actually emulate the ACPI model by assigning similar global interrupt numbers to the APIC pins for the APICs listed in the MP Table. > I think you are forgetting a couple of things here: > > * PCI busses only have 4 interrupt lines (A, B, C, and D). > > * Motherboards often have anywhere from 3 to 6 PCI or PCI-like busses, > connected to the APICs via bridge chips. > > * The bridge chips have a limited number of IRQ pins. > > * Sometimes you have several bridges connected to another bridge > before it gets to the APIC. > > So the answer is... regardless of the capabilities of the APIC(s) > devices still often have limited choices that require IRQ sharing > simply due to the PCI BUS and BRIDGE configuration of the motherboard. Not always. For example, Intel's host to PCI-X bridges include their own I/OxAPIC in the bridge itself, so each slot gets its own pins on that APIC. The I/OxAPIC then sends interrupt requests as messages to the CPUs (sort of like MSI). > But even more to the point, BIOSes (ACPI, etc.) often get really > confused about routing IRQs through bridges. They will for example > believe that two devices that share a *PHYSICAL* IRQ line through a > bridge are capable of being assigned different IRQs when, in fact, > they aren't. They will get confused about how some of the PCI IRQ > lines are routed to the bridges (so line 'B' on PCI bus #1 might be > misconfigured, for example). All sorts of bad things can happen. I haven't seen this. Note that you have to handle bridges carefully. For example, if the bridge's bus is included in one of the tables ($PIR, MP Table, or ACPI _PRT) you just use the associated info directly for the device on that bus. However, if the bus isn't listed (such as in add-on cards, and also some other bridges in various chipsets), then instead you have to do the defined "barber-pole" swizzle and pass the request up to your parent. The generic PCI-PCI bridge's route_interrupt method does this. > The only way for an operating system to figure this stuff out on its > own is to understand the umpteen different bridge chips out there, > test physical interrupt sources (which is not always possible) to see > how they are actually routed, and ignore the BIOS completely. Nope. ACPI provides an abstraction for the link devices used for !APIC mode (and rarely for APIC mode) that work fine. Conceptually, the code needs to route link devices though and when you want to get the IRQ for a PCI device that's hooked up to a link, you ask the link for its IRQ. For the !ACPI case you can use the PCI BIOS to do this which is what the $PIR-driven driver does. > Wasn't it something like NetBSD or OpenBSD that was thinking about > doing that? Not trying to figure out the routing but instead just > figure out which vector was being asserted for a device? I'm beginning > to think that that may be the ONLY solution. NetBSD does have drivers for some of the chipsets that basically just implement what the PCI BIOS call does. > Intel really screwed up big time. Motorola had a much, much, MUCH > better mechanism where the actual devices generated the actual vector > number on the interrupt bus and the only thing you might have hardwired > would have been the IPL. But Intel doesn't work that way. Their stuff > is just totally screwed when it comes to handling interrupts. It's > completely 100% guarenteed pungent crapola to anyone who has ever > built hardware with a *REAL* interrupt subsystem. Hence MSI which PCI-E will use and PCI already has support for (and FreeBSD will grow support for in the not too distant future). -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 00:31:17 2005 Return-Path: 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 CB52616A4CE for ; Tue, 12 Apr 2005 00:31:17 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 354C243D3F for ; Tue, 12 Apr 2005 00:31:17 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.3) id j3C0VFBI001777; Mon, 11 Apr 2005 19:31:15 -0500 (CDT) (envelope-from dan) Date: Mon, 11 Apr 2005 19:31:15 -0500 From: Dan Nelson To: Kris Kennaway Message-ID: <20050412003114.GD284@dan.emsphone.com> References: <20050411234512.GA23344@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050411234512.GA23344@xor.obsecurity.org> X-OS: FreeBSD 5.4-PRERELEASE X-message-flag: Outlook Error User-Agent: Mutt/1.5.8i cc: current@freebsd.org Subject: Re: Softupdates not preventing lengthy fsck X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 12 Apr 2005 00:31:17 -0000 In the last episode (Apr 11), Kris Kennaway said: > I'm seeing the following problem: on 6.0 machines which have had a lot > of FS activity in the past but are currently quiet, an unclean reboot > will require an hour or more of fscking and will end up clearing > thousands of inodes: This might be expected behaviour if the previous boot tried to do a bgfsck and failed. It should set a flag forcing a full fsck on the next boot, which will clear out the half-committed inodes from the previous crash. I see it often on 5.*. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 00:42:35 2005 Return-Path: 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 7718416A4CE for ; Tue, 12 Apr 2005 00:42:35 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.194.102.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E86E43D2D for ; Tue, 12 Apr 2005 00:42:35 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id A502A514FE; Mon, 11 Apr 2005 17:42:32 -0700 (PDT) Date: Mon, 11 Apr 2005 17:42:32 -0700 From: Kris Kennaway To: Dan Nelson Message-ID: <20050412004232.GA83769@xor.obsecurity.org> References: <20050411234512.GA23344@xor.obsecurity.org> <20050412003114.GD284@dan.emsphone.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline In-Reply-To: <20050412003114.GD284@dan.emsphone.com> User-Agent: Mutt/1.4.2.1i cc: current@freebsd.org cc: Kris Kennaway Subject: Re: Softupdates not preventing lengthy fsck X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 12 Apr 2005 00:42:35 -0000 --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 11, 2005 at 07:31:15PM -0500, Dan Nelson wrote: > In the last episode (Apr 11), Kris Kennaway said: > > I'm seeing the following problem: on 6.0 machines which have had a lot > > of FS activity in the past but are currently quiet, an unclean reboot > > will require an hour or more of fscking and will end up clearing > > thousands of inodes: >=20 > This might be expected behaviour if the previous boot tried to do a > bgfsck and failed. It should set a flag forcing a full fsck on the > next boot, which will clear out the half-committed inodes from the > previous crash. I see it often on 5.*. I should have mentioned that I have background_fsck=3DNO (because of too many filesystem corruption problems after panics). The previous time the system booted it also had to fsck, and did the same thing (it's now been running for >2 hours). Kris --GvXjxJ+pjyke8COw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCWxl3Wry0BWjoQKURAsEyAKCgT+m+hohnXEfCghUFCK7qOhZpgQCglLxJ nmDdMC0WoKR1ifCVmUw/hl8= =Nb0Q -----END PGP SIGNATURE----- --GvXjxJ+pjyke8COw-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 01:08:10 2005 Return-Path: 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 B6CE316A4CE for ; Tue, 12 Apr 2005 01:08:10 +0000 (GMT) Received: from mail25.sea5.speakeasy.net (mail25.sea5.speakeasy.net [69.17.117.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72C1943D3F for ; Tue, 12 Apr 2005 01:08:10 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 21211 invoked from network); 12 Apr 2005 01:08:10 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 12 Apr 2005 01:08:09 -0000 Received: from [131.106.57.68] (p178.n-lapop01.stsn.com [12.129.240.178]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j3C17mbn016686; Mon, 11 Apr 2005 21:07:50 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Mon, 11 Apr 2005 20:31:24 -0400 User-Agent: KMail/1.8 References: <200504081529.33026.jhb@FreeBSD.org> <20050409115745.31a0059c.antoine.brodin@laposte.net> In-Reply-To: <20050409115745.31a0059c.antoine.brodin@laposte.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504112031.26979.jhb@FreeBSD.org> X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: nate@root.org cc: k-gleb@yandex.ru cc: dan.cojocar@gmail.com cc: Antoine Brodin Subject: Re: Interrupt storm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 12 Apr 2005 01:08:10 -0000 On Saturday 09 April 2005 05:57 am, Antoine Brodin wrote: > John Baldwin wrote: > > I think your other link devices are meant to be used in APIC mode (note > > their names start with 'A') and thus I think they are aliases for the > > other link devices. So when I turn off the alias, I turn off the > > non-APIC mode one as well. Working BIOSen handle this by having the same > > link device change its behavior (different _PRS return values) depending > > on the PIC mode. It's not easy to determine if a link is just not used > > (for example, if no card is plugged into a slot with a dedicated link) or > > if it's an alias. I think having two ACPI devices alias to the same > > hardware is a bug in the BIOS though. Perhaps your BIOS vendor can be > > convinced to fix this. Can you see if Linux has the same problem btw? > > I've just sent a technical support request to ASUS. I'll let you know > when they reply. > Linux doesn't have the same problem: I tested with a knoppix live cd > yesterday. > dmesg: http://bsd.miki.eu.org/~antoine/knoppix36.dmesg , but it doesn't > look very helpful. Actually, it is. What Linux is doing is probing all the link devices before it probes any PCI devices, so all the _DIS calls happen before any interrupts are routed. I believe Nate knows how to get FreeBSD to do something similar via a hack. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 01:08:15 2005 Return-Path: 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 76D7916A524 for ; Tue, 12 Apr 2005 01:08:15 +0000 (GMT) Received: from mail23.sea5.speakeasy.net (mail23.sea5.speakeasy.net [69.17.117.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 384F543D1D for ; Tue, 12 Apr 2005 01:08:15 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 25132 invoked from network); 12 Apr 2005 01:08:15 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 12 Apr 2005 01:08:14 -0000 Received: from [131.106.57.68] (p178.n-lapop01.stsn.com [12.129.240.178]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j3C17mbo016686; Mon, 11 Apr 2005 21:08:06 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Mon, 11 Apr 2005 20:38:32 -0400 User-Agent: KMail/1.8 References: <20050406130909.GA90294@stud.fit.vutbr.cz> In-Reply-To: <20050406130909.GA90294@stud.fit.vutbr.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504112038.32964.jhb@FreeBSD.org> X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: Divacky Roman Subject: Re: slow kbd input on 6-current on amd64@nforce3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 12 Apr 2005 01:08:15 -0000 On Wednesday 06 April 2005 09:09 am, Divacky Roman wrote: > as I have mentioned on the list I have very slow keyboard input. it might > be related to kbd not having an IRQ assigned. I repeat once again that it > worked on 5.3R. Actually, now that I look at this, you have a buggy BIOS. It is lying and claiming that some PCI interrupts are active-hi rather than active-low. Hmm, the 5.3 dmesg you gave me included APIC, while this one does not. Does disabling ACPI make your keyboard happy on 6.0 by chance? > I include verbose dmesg + this piece which didnt get into dmesg (dont know > why): > > (with atkbd.flags=0) > atkbd: the current kbd controller command byte 0047 > atkbd: keyboard ID 0x41ab (2) > kbdc: RESET_KBD return code:00fa > kbdc: RESET_KBD status:00aa > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: irq 1 on atkbdc0 > kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 > atkbd0: [GIANT-LOCKED] > psm0: current command byte:0047 > kbdc: TEST_AUX_PORT status:0000 > kbdc: RESET_AUX return code:00fe > kbdc: RESET_AUX return code:00fe > kbdc: RESET_AUX return code:00fe > kbdc: DIAGNOSE status:0055 > kbdc: TEST_KBD_PORT status:0000 > psm0: failed to reset the aux device. > fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 01:40:54 2005 Return-Path: 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 0240416A4CE for ; Tue, 12 Apr 2005 01:40:54 +0000 (GMT) Received: from web54003.mail.yahoo.com (web54003.mail.yahoo.com [206.190.36.227]) by mx1.FreeBSD.org (Postfix) with SMTP id 6437743D58 for ; Tue, 12 Apr 2005 01:40:53 +0000 (GMT) (envelope-from spamrefuse@yahoo.com) Received: (qmail 20113 invoked by uid 60001); 12 Apr 2005 01:40:52 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=2MeacGaICK/D7zrOlO6T5QgaI1p70uD6vNkC6nL+zkuucawZwTjJh1RGQsLm3WLHs0cv4CqesDmpPluiEgErKBcmrQYDJrKmUXZEQ6Il/xMWBG24kgFOulOrpkCCFXX9wwNXXeIUuhKNrW7fkWX5zYfAELewnixRcfeew84UH7Q= ; Message-ID: <20050412014052.20111.qmail@web54003.mail.yahoo.com> Received: from [147.46.44.181] by web54003.mail.yahoo.com via HTTP; Mon, 11 Apr 2005 18:40:52 PDT Date: Mon, 11 Apr 2005 18:40:52 -0700 (PDT) From: Rob To: Ruslan Ermilov In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: FreeBSD current Subject: Re: xl(4) & polling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 12 Apr 2005 01:40:54 -0000 --- Ruslan Ermilov wrote: > On Sun, Apr 10, 2005 at 09:16:44PM -0700, Rob wrote: >> >> Will it also go into RELENG_5, after the 5.4 >> release? > > Yes, probably. After I hear more reports of > success. > The HEAD sources can be used on RELENG_5 to test > the functionality. OK, I have applied your patch to 5.4-Stable as of yesterday. This is on a dual-homed router + NAT, with on the private network seven PCs (5x Windows + 2x FreeBSD). The router seems to operate fine under polling mode, although I don't know how to test this in more detail. Here's the output of 'ifconfig': xl0: flags=18843 mtu 1500 options=49 inet 167.42.40.110 netmask 0xffff0000 broadcast 167.42.255.255 ether 00:00:60:10:30:20 media: Ethernet autoselect (100baseTX ) status: active xl1: flags=18843 mtu 1500 options=49 inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255 ether 00:00:00:80:50:40 media: Ethernet autoselect (100baseTX ) status: active Regards, Rob. __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 01:43:26 2005 Return-Path: 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 0901116A4CE for ; Tue, 12 Apr 2005 01:43:26 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4F6243D54 for ; Tue, 12 Apr 2005 01:43:25 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.1/8.13.1) with ESMTP id j3C1hHv4034269; Mon, 11 Apr 2005 18:43:22 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200504120143.j3C1hHv4034269@gw.catspoiler.org> Date: Mon, 11 Apr 2005 18:43:17 -0700 (PDT) From: Don Lewis To: kris@obsecurity.org In-Reply-To: <20050411234512.GA23344@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: current@FreeBSD.org Subject: Re: Softupdates not preventing lengthy fsck X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 12 Apr 2005 01:43:26 -0000 On 11 Apr, Kris Kennaway wrote: > I'm seeing the following problem: on 6.0 machines which have had a lot > of FS activity in the past but are currently quiet, an unclean reboot > will require an hour or more of fscking and will end up clearing > thousands of inodes: > > [...] > /dev/da0s1e: UNREF FILE I=269731 OWNER=root MODE=100644 > /dev/da0s1e: SIZE=8555 MTIME=Apr 18 02:29 2002 (CLEARED) > /dev/da0s1e: UNREF FILE I=269741 OWNER=root MODE=100644 > [...] > > It's as if dirty buffers aren't being written out properly, or > something. Has anyone else seen this? This looks a lot like it could be a vnode refcnt leak. Files won't get removed from the disk while they are still in use (the old unlink while open trick). Could nullfs be a factor? From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 03:53:31 2005 Return-Path: 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 9653616A4CE; Tue, 12 Apr 2005 03:53:31 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.194.102.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53A2B43D46; Tue, 12 Apr 2005 03:53:31 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 0B93F51326; Mon, 11 Apr 2005 20:53:29 -0700 (PDT) Date: Mon, 11 Apr 2005 20:53:29 -0700 From: Kris Kennaway To: Don Lewis Message-ID: <20050412035111.GA31366@xor.obsecurity.org> References: <20050411234512.GA23344@xor.obsecurity.org> <200504120143.j3C1hHv4034269@gw.catspoiler.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <200504120143.j3C1hHv4034269@gw.catspoiler.org> User-Agent: Mutt/1.4.2.1i cc: current@FreeBSD.org cc: kris@obsecurity.org Subject: Re: Softupdates not preventing lengthy fsck X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 12 Apr 2005 03:53:31 -0000 On Mon, Apr 11, 2005 at 06:43:17PM -0700, Don Lewis wrote: > On 11 Apr, Kris Kennaway wrote: > > I'm seeing the following problem: on 6.0 machines which have had a lot > > of FS activity in the past but are currently quiet, an unclean reboot > > will require an hour or more of fscking and will end up clearing > > thousands of inodes: > >=20 > > [...] > > /dev/da0s1e: UNREF FILE I=3D269731 OWNER=3Droot MODE=3D100644 > > /dev/da0s1e: SIZE=3D8555 MTIME=3DApr 18 02:29 2002 (CLEARED) >=20 > > /dev/da0s1e: UNREF FILE I=3D269741 OWNER=3Droot MODE=3D100644 > > [...] > >=20 > > It's as if dirty buffers aren't being written out properly, or > > something. Has anyone else seen this? >=20 > This looks a lot like it could be a vnode refcnt leak. Files won't get > removed from the disk while they are still in use (the old unlink while > open trick). Could nullfs be a factor? Yes, I make extensive use of read-only nullfs. Kris (fsck still running) From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 07:27:35 2005 Return-Path: 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 A937516A4D0; Tue, 12 Apr 2005 07:27:35 +0000 (GMT) Received: from barton.dreadbsd.org (massena-4-82-67-196-50.fbx.proxad.net [82.67.196.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A308743D53; Tue, 12 Apr 2005 07:27:34 +0000 (GMT) (envelope-from antoine@massena-4-82-67-196-50.fbx.proxad.net) Received: from barton.dreadbsd.org (localhost [127.0.0.1]) by barton.dreadbsd.org (8.13.3/8.13.1) with ESMTP id j3C7RXrq004602; Tue, 12 Apr 2005 09:27:33 +0200 (CEST) (envelope-from antoine@massena-4-82-67-196-50.fbx.proxad.net) Received: (from antoine@localhost) by barton.dreadbsd.org (8.13.3/8.13.1/Submit) id j3C7RWFI004601; Tue, 12 Apr 2005 09:27:32 +0200 (CEST) (envelope-from antoine) Date: Tue, 12 Apr 2005 09:27:32 +0200 From: Antoine Brodin To: John Baldwin Message-Id: <20050412092732.72c9c87a.antoine.brodin@laposte.net> In-Reply-To: <200504112031.26979.jhb@FreeBSD.org> References: <200504081529.33026.jhb@FreeBSD.org> <20050409115745.31a0059c.antoine.brodin@laposte.net> <200504112031.26979.jhb@FreeBSD.org> X-Mailer: Sylpheed version 1.9.7 (GTK+ 2.6.5; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-current@FreeBSD.org cc: k-gleb@yandex.ru cc: dan.cojocar@gmail.com cc: nate@root.org Subject: Re: Interrupt storm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 12 Apr 2005 07:27:35 -0000 John Baldwin wrote: > On Saturday 09 April 2005 05:57 am, Antoine Brodin wrote: > > John Baldwin wrote: > > > I think your other link devices are meant to be used in APIC mode (note > > > their names start with 'A') and thus I think they are aliases for the > > > other link devices. So when I turn off the alias, I turn off the > > > non-APIC mode one as well. Working BIOSen handle this by having the same > > > link device change its behavior (different _PRS return values) depending > > > on the PIC mode. It's not easy to determine if a link is just not used > > > (for example, if no card is plugged into a slot with a dedicated link) or > > > if it's an alias. I think having two ACPI devices alias to the same > > > hardware is a bug in the BIOS though. Perhaps your BIOS vendor can be > > > convinced to fix this. Can you see if Linux has the same problem btw? > > > > I've just sent a technical support request to ASUS. I'll let you know > > when they reply. > > Linux doesn't have the same problem: I tested with a knoppix live cd > > yesterday. > > dmesg: http://bsd.miki.eu.org/~antoine/knoppix36.dmesg , but it doesn't > > look very helpful. > > Actually, it is. What Linux is doing is probing all the link devices before > it probes any PCI devices, so all the _DIS calls happen before any interrupts > are routed. I believe Nate knows how to get FreeBSD to do something similar > via a hack. There's this hack that works here: %%% Index: acpi.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi.c,v retrieving revision 1.210 diff -u -p -r1.210 acpi.c --- acpi.c 31 Mar 2005 19:07:26 -0000 1.210 +++ acpi.c 9 Apr 2005 09:50:54 -0000 @@ -1503,6 +1503,9 @@ acpi_probe_order(ACPI_HANDLE handle, int } else if (acpi_MatchHid(handle, "PNP0C09")) { *order = 2; ret = 1; + } else if (acpi_MatchHid(handle, "PNP0C0F")) { + *order = 3; + ret = 1; } return (ret); %%% Cheers, Antoine From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 07:38:14 2005 Return-Path: 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 C50A216A4CE; Tue, 12 Apr 2005 07:38:14 +0000 (GMT) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A3BA43D5A; Tue, 12 Apr 2005 07:38:13 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) (8.13.4/8.13.3) with ESMTP id j3C7cAj6089622 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 12 Apr 2005 09:38:10 +0200 (CEST) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.4/8.13.3/Submit) id j3C7cA85089621; Tue, 12 Apr 2005 09:38:10 +0200 (CEST) Date: Tue, 12 Apr 2005 09:38:10 +0200 From: Divacky Roman To: John Baldwin Message-ID: <20050412073810.GA89527@stud.fit.vutbr.cz> References: <20050406130909.GA90294@stud.fit.vutbr.cz> <200504112038.32964.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504112038.32964.jhb@FreeBSD.org> User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.49 on 147.229.10.14 cc: current@FreeBSD.org Subject: Re: slow kbd input on 6-current on amd64@nforce3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 12 Apr 2005 07:38:14 -0000 On Mon, Apr 11, 2005 at 08:38:32PM -0400, John Baldwin wrote: > On Wednesday 06 April 2005 09:09 am, Divacky Roman wrote: > > as I have mentioned on the list I have very slow keyboard input. it might > > be related to kbd not having an IRQ assigned. I repeat once again that it > > worked on 5.3R. > > Actually, now that I look at this, you have a buggy BIOS. It is lying and > claiming that some PCI interrupts are active-hi rather than active-low. Hmm, > the 5.3 dmesg you gave me included APIC, while this one does not. Does > disabling ACPI make your keyboard happy on 6.0 by chance? It doesnt boot with acpi enabled (stops in probing ata devices, but it never worked so I think ata is not the only culprit) what can I do with it? would some quirk made the trick? why it worked in 5.3R? thnx for reply roman From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 08:58:34 2005 Return-Path: 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 7F7C316A4CE; Tue, 12 Apr 2005 08:58:34 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9B6443D41; Tue, 12 Apr 2005 08:58:33 +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 j3C8wXHm059872; Tue, 12 Apr 2005 04:58:33 -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 j3C8wXTu002551; Tue, 12 Apr 2005 04:58:33 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E2EE87306E; Tue, 12 Apr 2005 04:58:32 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050412085832.E2EE87306E@freebsd-current.sentex.ca> Date: Tue, 12 Apr 2005 04:58:32 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on clamscanner4 X-Virus-Status: Clean Subject: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 08:58:34 -0000 TB --- 2005-04-12 07:33:48 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-12 07:33:48 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2005-04-12 07:33:48 - checking out the source tree TB --- 2005-04-12 07:33:48 - cd /home/tinderbox/CURRENT/amd64/amd64 TB --- 2005-04-12 07:33:48 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-12 07:40:30 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-12 07:40:30 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-04-12 07:40:30 - /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-04-12 08:53:25 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-12 08:53:25 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-04-12 08:53:25 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Tue Apr 12 08:53:26 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 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/amd64/amd64/src/sys -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/altq -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/pf -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -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 /tinderbox/CURRENT/amd64/amd64 /src/sys/dev/mpt/mpt_pci.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 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/amd64/amd64/src/sys -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/altq -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/pf -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -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 /tinderbox/CURRENT/amd64/amd64 /src/sys/dev/nge/if_nge.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 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/amd64/amd64/src/sys -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/altq -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/pf -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -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 /tinderbox/CURRENT/amd64/amd64 /src/sys/dev/null/null.c awk -f /tinderbox/CURRENT/amd64/amd64/src/sys/tools/makeobjops.awk /tinderbox/CURRENT/amd64/amd64/src/sys/dev/pccard/card_if.m -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 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/amd64/amd64/src/sys -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/altq -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/pf -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-s se -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror card_if.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 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/amd64/amd64/src/sys -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/altq -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/pf -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -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 /tinderbox/CURRENT/amd64/amd64 /src/sys/dev/pccard/pccard.c /tinderbox/CURRENT/amd64/amd64/src/sys/dev/pccard/pccard.c: In function `pccard_function_init': /tinderbox/CURRENT/amd64/amd64/src/sys/dev/pccard/pccard.c:451: warning: overflow in implicit constant conversion /tinderbox/CURRENT/amd64/amd64/src/sys/dev/pccard/pccard.c:474: warning: overflow in implicit constant conversion *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. TB --- 2005-04-12 08:58:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-12 08:58:32 - ERROR: failed to build generic kernel TB --- 2005-04-12 08:58:32 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 09:50:33 2005 Return-Path: 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 83CE616A4CE for ; Tue, 12 Apr 2005 09:50:33 +0000 (GMT) Received: from mi.veco.ru (mail.veco.ru [195.161.146.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id 750FF43D46 for ; Tue, 12 Apr 2005 09:50:31 +0000 (GMT) (envelope-from aka@veco.ru) Received: from [172.19.73.1] (HELO camel.veco.ru) by mi.veco.ru (CommuniGate Pro SMTP 4.2.7) with SMTP id 104104; Tue, 12 Apr 2005 13:50:29 +0400 Date: Tue, 12 Apr 2005 13:50:29 +0400 From: Andrey Koklin To: current@FreeBSD.org Message-Id: <20050412135029.2d81a216.aka@veco.ru> In-Reply-To: <424AFDAA.8010607@elischer.org> References: <20050330191824.4c08acc6.aka@veco.ru> <424AFDAA.8010607@elischer.org> X-Mailer: Sylpheed version 1.0.0rc (GTK+ 1.2.10; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: Julian Elischer Subject: ciss(4): speed degradation for Compaq Smart Array [3rd edition] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 12 Apr 2005 09:50:33 -0000 On Wed, 30 Mar 2005 11:27:38 -0800 Julian Elischer wrote: [snip] > Thanks for giving more info.. > this shows up some problems though.. > I'm not saying that there is no problem (I actually think there is a > slowdown in 5/6 but > it should be amenable to tuning as we get time to look at it.. The new > disk code is a lot more > dependent on teh scheduler than the old disk code). What I AM saying is that > teh test environment doens't eliminate some of the possible reasons for > speed > differences.. > For example, you don't say if the raid controllers arre set up the same.. > And the disks do not match.. the 74GB drives may be newer and faster.. > > Maybe you should reinstall the 6.0 machine to have a 4.11 partition as > well so that you > can dual boot on the exact same hardware.. THAT would show it if you > used the same > partition for both tests.. (The testing partition should be > a UFS1 filesystem that both can read.) Sorry, I'd got ill, and little later now with the reply. To remember, there was big enough difference in overall transfers under FreeBSD 4.11 and 6.0-CURRENT (5.4 gave results similar to 6.0, so I've omitted it for brevity) I've got one server, to have same hardware: HP Proliant DL380 G2, 2 x P3 1.133GHz, RAM 1280 Mb, SmartArray 5i, 5 x 36Gb Ultra320 10K HDD disks configured as RAID5 with default stripe size (16K?) do-test # bsdlabel da0s1 # /dev/da0s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 4194304 0 4.2BSD 0 0 0 b: 4194304 4194304 swap c: 284490208 0 unused 0 0 # "raw" part, don't edit d: 4194304 8388608 4.2BSD 2048 16384 89 e: 16777216 12582912 4.2BSD 0 0 0 f: 188743680 29360128 4.2BSD 0 0 0 g: 66386400 218103808 4.2BSD 2048 16384 28552 do-test # df -lh Filesystem Size Used Avail Capacity Mounted on /dev/da0s1a 1.9G 53M 1.7G 3% / devfs 1.0K 1.0K 0B 100% /dev /dev/da0s1e 7.7G 1.6G 5.5G 22% /usr /dev/da0s1f 87G 14G 66G 17% /var /dev/da0s1g 31G 3.4G 25G 12% /mnt da0s1a - FreeBSD 6.0-CURRENT da0s1d - FreeBSD 4.11 Both OSes have custom SMP kernels. 6.0 - stripped off debugging, 4BSD scheduler (I'd tried ULE one too, there was 5-10% difference in transfer and CPU load, so I've ommited it) As there was no big geometry factor, all tests use one partition da0s1g, formated as ufs1 and ufs2. 6.0-CURRENT, UFS2 ----------------- # newfs -O2 -U -o time /dev/da0s1g # mount /dev/da0s1g /mnt # # dd if=/dev/zero of=/mnt/1Gb-1 bs=1m count=1024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 48.481901 secs (22147272 bytes/sec) ... # dd if=/mnt/1Gb-1 of=/dev/null bs=1m 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 23.303288 secs (46076838 bytes/sec) # # bonnie -d /mnt -m '6.0(1)' -s 4096 -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 6.0(1) 4096 15810 35.8 19404 15.3 12366 11.0 30682 68.9 50639 23.5 1084.9 5.7 6.0-CURRENT, UFS1 ----------------- # newfs -O1 -U -o time /dev/da0s1g # mount /dev/da0s1g /mnt # # dd if=/dev/zero of=/mnt/1Gb-1 bs=1m count=1024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 44.986316 secs (23868187 bytes/sec) # dd if=/mnt/1Gb-1 of=/dev/null bs=1m 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 21.702390 secs (49475741 bytes/sec) # # bonnie -d /mnt -m '6.0(2)' -s 4096 -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 6.0(2) 4096 17107 39.8 23879 16.9 13289 11.8 33849 75.9 50417 23.5 1116.5 5.9 6.0-CURRENT, UFS1 (no snap) --------------------------- # newfs -O1 -U -n -o time /dev/da0s1g # mount /dev/da0s1g /mnt # # dd if=/dev/zero of=/mnt/1Gb-1 bs=1m count=1024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 39.034020 secs (27507846 bytes/sec) # dd if=/mnt/1Gb-1 of=/dev/null bs=1m 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 22.023556 secs (48754244 bytes/sec) # # bonnie -d /mnt -m '6.0(3)' -s 4096 -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 6.0(3) 4096 20402 45.2 20903 15.8 12674 11.0 32834 73.5 53088 22.3 1072.1 6.4 6.0-CURRENT, UFS1, partition formated under 4.11 ------------------------------------------------ # dd if=/dev/zero of=/mnt/1Gb-1 bs=1m count=1024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 25.460762 secs (42172415 bytes/sec) # dd if=/dev/zero of=/mnt/1Gb-3 bs=1m count=1024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 26.140447 secs (41075879 bytes/sec) # # bonnie -d /mnt -m '6.0(4)' -s 4096 -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 6.0(4) 4096 27343 59.8 36447 27.6 17517 15.1 39665 90.4 45941 19.3 1086.4 5.7 4.11-STABLE ----------- # newfs -U -o time /dev/da0s1g # mount /dev/da0s1g /mnt # dd if=/dev/zero of=/mnt/1Gb-1 bs=1m count=1024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 24.076042 secs (44597938 bytes/sec) ... dd if=/mnt/1Gb-1 of=/dev/null bs=1m 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 12.619832 secs (85083686 bytes/sec) # # bonnie -d /mnt -m '4.11' -s 4096 -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 4.11 4096 45359 74.4 47120 24.7 21104 16.2 45216 97.9 85723 31.8 1503.2 5.3 Putting bonnie results together: -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 6.0(1) 4096 15810 35.8 19404 15.3 12366 11.0 30682 68.9 50639 23.5 1084.9 5.7 6.0(2) 4096 17107 39.8 23879 16.9 13289 11.8 33849 75.9 50417 23.5 1116.5 5.9 6.0(3) 4096 20402 45.2 20903 15.8 12674 11.0 32834 73.5 53088 22.3 1072.1 6.4 6.0(4) 4096 27343 59.8 36447 27.6 17517 15.1 39665 90.4 45941 19.3 1086.4 5.7 4.11 4096 45359 74.4 47120 24.7 21104 16.2 45216 97.9 85723 31.8 1503.2 5.3 Where: (1) - 6.0, UFS2 (2) - 6.0, UFS1 (3) - 6.0, UFS1, no snap (4) - 6.0, UFS1, partition formated under 4.11 Again, simple benchmarks show disk system productivity under 6.0 as about 50-70% of 4.11's one. Not fatal yet, if it wouldn't drop further. Andrey From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 10:11:51 2005 Return-Path: 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 924DE16A4CE; Tue, 12 Apr 2005 10:11:51 +0000 (GMT) Received: from liberty.onthenet.com.au (liberty.OntheNet.com.au [203.22.124.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id D69AB43D1F; Tue, 12 Apr 2005 10:11:50 +0000 (GMT) (envelope-from grehan@freebsd.org) Received: from [203.13.71.95] (CPE-71-95.dsl.OntheNet.net [203.13.71.95]) j3CABnnP028110; Tue, 12 Apr 2005 20:11:49 +1000 (EST) (envelope-from grehan@freebsd.org) Message-ID: <425B9F02.9070406@freebsd.org> Date: Tue, 12 Apr 2005 20:12:18 +1000 From: Peter Grehan User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20041016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Suleiman Souhlal References: <20050411182917.959BC7306E@freebsd-current.sentex.ca> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: powerpc@freebsd.org cc: FreeBSD Tinderbox cc: current@freebsd.org Subject: Re: [current tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 12 Apr 2005 10:11:51 -0000 > The patch at http://people.freebsd.org/~ssouhlal/waiting/ata_iobus.diff > fixes this. I'm just waiting for grehan@'s approval to commit it. OK, I'm back now: go ahead and commit ! later, Peter. From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 08:13:59 2005 Return-Path: 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 67D9A16A4CE for ; Tue, 12 Apr 2005 08:13:59 +0000 (GMT) Received: from web31709.mail.mud.yahoo.com (web31709.mail.mud.yahoo.com [68.142.201.189]) by mx1.FreeBSD.org (Postfix) with SMTP id 07D4543D2F for ; Tue, 12 Apr 2005 08:13:59 +0000 (GMT) (envelope-from alasowadow@yahoo.com) Received: (qmail 18304 invoked by uid 60001); 12 Apr 2005 08:13:58 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=h4YIfuzBZRbwqzIuk46sTJmHX88u93lFs3FZQik6bmt/4OAebSN57OMmArYeo64l7c+8L5h9Z9SREoqDIEIEsstTiT3aV0w3XZSG8u8SJfHHmnMzLkIPJinyYS5uXdZVVBHV+Y5HVPF89JmNk8751NqyOUj5z47G2oUjnv001Jw= ; Message-ID: <20050412081358.18296.qmail@web31709.mail.mud.yahoo.com> Received: from [202.80.171.67] by web31709.mail.mud.yahoo.com via HTTP; Tue, 12 Apr 2005 01:13:58 PDT Date: Tue, 12 Apr 2005 01:13:58 -0700 (PDT) From: alasow adow To: freebsd-current@freebsd.org MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 12 Apr 2005 11:54:53 +0000 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: FBSD 5.1b2 Inst. Results on Dell i8500 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 12 Apr 2005 08:13:59 -0000 ok thanks all of you i neeed to send me sex movies the latest sex __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 12:01:57 2005 Return-Path: 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 E645F16A4CE for ; Tue, 12 Apr 2005 12:01:57 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F3F643D5E for ; Tue, 12 Apr 2005 12:01:57 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.1/8.13.1) with ESMTP id j3CC1nZ1035643; Tue, 12 Apr 2005 05:01:53 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200504121201.j3CC1nZ1035643@gw.catspoiler.org> Date: Tue, 12 Apr 2005 05:01:49 -0700 (PDT) From: Don Lewis To: kris@obsecurity.org In-Reply-To: <20050412035111.GA31366@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: current@FreeBSD.org Subject: Re: Softupdates not preventing lengthy fsck X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 12 Apr 2005 12:01:58 -0000 On 11 Apr, Kris Kennaway wrote: > On Mon, Apr 11, 2005 at 06:43:17PM -0700, Don Lewis wrote: >> On 11 Apr, Kris Kennaway wrote: >> > I'm seeing the following problem: on 6.0 machines which have had a lot >> > of FS activity in the past but are currently quiet, an unclean reboot >> > will require an hour or more of fscking and will end up clearing >> > thousands of inodes: >> > >> > [...] >> > /dev/da0s1e: UNREF FILE I=269731 OWNER=root MODE=100644 >> > /dev/da0s1e: SIZE=8555 MTIME=Apr 18 02:29 2002 (CLEARED) >> >> > /dev/da0s1e: UNREF FILE I=269741 OWNER=root MODE=100644 >> > [...] >> > >> > It's as if dirty buffers aren't being written out properly, or >> > something. Has anyone else seen this? >> >> This looks a lot like it could be a vnode refcnt leak. Files won't get >> removed from the disk while they are still in use (the old unlink while >> open trick). Could nullfs be a factor? > > Yes, I make extensive use of read-only nullfs. > > Kris (fsck still running) It would also be interesting to find out why fsck is taking so long to run. I don't see anything obvious in the code. From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 13:15:45 2005 Return-Path: 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 E0C8A16A4CF for ; Tue, 12 Apr 2005 13:15:45 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [83.167.185.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D6DFE43D45 for ; Tue, 12 Apr 2005 13:15:44 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 7015C651FA for ; Tue, 12 Apr 2005 14:15:25 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 36163-01 for ; Tue, 12 Apr 2005 14:15:24 +0100 (BST) Received: from empiric.dek.spc.org (dhcp52.icir.org [192.150.187.52]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id C08C3651EB for ; Tue, 12 Apr 2005 14:15:23 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id C1FF9616D; Tue, 12 Apr 2005 06:15:35 -0700 (PDT) Date: Tue, 12 Apr 2005 06:15:35 -0700 From: Bruce M Simpson To: freebsd-current@freebsd.org Message-ID: <20050412131535.GA784@empiric.icir.org> Mail-Followup-To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="y0ulUmNC+osPPQO6" Content-Disposition: inline Subject: [PATCH] Allow pciconf(8) to be used with CardBus devices X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 12 Apr 2005 13:15:46 -0000 --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, Here is a patch which allows pciconf to manipulate configuration space registers on CardBus devices, in addition to devices which are direct children of "pci" instances. The patch is against branch RELENG_5_4. If there are no objections I'd like to commit it to -HEAD. Thanks, BMS --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="cardbus_pciconf.patch" Index: /usr/src/sys/dev/pci/pci_user.c =================================================================== RCS file: /home/ncvs/src/sys/dev/pci/pci_user.c,v retrieving revision 1.17 diff -u -p -r1.17 pci_user.c --- /usr/src/sys/dev/pci/pci_user.c 16 Jun 2004 09:46:53 -0000 1.17 +++ /usr/src/sys/dev/pci/pci_user.c 12 Apr 2005 12:54:15 -0000 @@ -173,7 +173,7 @@ pci_conf_match(struct pci_match_conf *ma static int pci_ioctl(struct cdev *dev, u_long cmd, caddr_t data, int flag, struct thread *td) { - device_t pci, pcib; + device_t pcidev; struct pci_io *io; const char *name; int error; @@ -386,20 +386,23 @@ getconfexit: io->pi_reg + io->pi_width > PCI_REGMAX || io->pi_reg & (io->pi_width - 1)) error = EINVAL; - /* * Assume that the user-level bus number is - * actually the pciN instance number. We map - * from that to the real pcib+bus combination. + * in fact the physical PCI bus number. + * Look up the grandparent, i.e. the bridge device, + * so that we can issue configuration space cycles. */ - pci = devclass_get_device(devclass_find("pci"), - io->pi_sel.pc_bus); - if (pci) { - int b = pcib_get_bus(pci); - pcib = device_get_parent(pci); + pcidev = pci_find_bsf(io->pi_sel.pc_bus, + io->pi_sel.pc_dev, io->pi_sel.pc_func); + if (pcidev) { + device_t busdev, brdev; + + busdev = device_get_parent(pcidev); + brdev = device_get_parent(busdev); + if (cmd == PCIOCWRITE) - PCIB_WRITE_CONFIG(pcib, - b, + PCIB_WRITE_CONFIG(brdev, + io->pi_sel.pc_bus, io->pi_sel.pc_dev, io->pi_sel.pc_func, io->pi_reg, @@ -407,8 +410,8 @@ getconfexit: io->pi_width); else io->pi_data = - PCIB_READ_CONFIG(pcib, - b, + PCIB_READ_CONFIG(brdev, + io->pi_sel.pc_bus, io->pi_sel.pc_dev, io->pi_sel.pc_func, io->pi_reg, --y0ulUmNC+osPPQO6-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 14:24:13 2005 Return-Path: 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 17B8C16A4CE; Tue, 12 Apr 2005 14:24:13 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28A5243D31; Tue, 12 Apr 2005 14:24:12 +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 j3CEOBYf075276; Tue, 12 Apr 2005 10:24:11 -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 j3CEOBQV037759; Tue, 12 Apr 2005 10:24:11 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 7A2177306E; Tue, 12 Apr 2005 10:24:11 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050412142411.7A2177306E@freebsd-current.sentex.ca> Date: Tue, 12 Apr 2005 10:24:11 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on clamscanner1 X-Virus-Status: Clean Subject: [current tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 14:24:13 -0000 TB --- 2005-04-12 12:41:16 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-12 12:41:16 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2005-04-12 12:41:16 - checking out the source tree TB --- 2005-04-12 12:41:16 - cd /home/tinderbox/CURRENT/ia64/ia64 TB --- 2005-04-12 12:41:16 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-12 12:47:47 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-12 12:47:47 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2005-04-12 12:47:47 - /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-04-12 14:19:49 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-12 14:19:49 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2005-04-12 14:19:49 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Tue Apr 12 14:19: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 >>> 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 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/ia64/ia64/src/sys -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/altq -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/pf -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/CURRENT/ia64/ia64/src/sys/dev/ata/ata-disk.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 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/ia64/ia64/src/sys -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/altq -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/pf -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/CURRENT/ia64/ia64/src/sys/dev/ata/ata-dma.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 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/ia64/ia64/src/sys -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/altq -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/pf -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/CURRENT/ia64/ia64/src/sys/dev/ata/ata-lowlevel.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 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/ia64/ia64/src/sys -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/altq -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/pf -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/CURRENT/ia64/ia64/src/sys/dev/ata/ata-pci.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 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/ia64/ia64/src/sys -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/altq -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/pf -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/CURRENT/ia64/ia64/src/sys/dev/ata/ata-queue.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 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/ia64/ia64/src/sys -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/altq -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/pf -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/CURRENT/ia64/ia64/src/sys/dev/ata/ata-raid.c /tinderbox/CURRENT/ia64/ia64/src/sys/dev/ata/ata-raid.c: In function `ata_raid_via_print_meta': /tinderbox/CURRENT/ia64/ia64/src/sys/dev/ata/ata-raid.c:3765: warning: long long unsigned int format, u_int64_t arg (arg 2) *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. TB --- 2005-04-12 14:24:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-12 14:24:11 - ERROR: failed to build generic kernel TB --- 2005-04-12 14:24:11 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 14:39:21 2005 Return-Path: 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 1A7F616A4CF for ; Tue, 12 Apr 2005 14:39:21 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DA4743D45 for ; Tue, 12 Apr 2005 14:39:20 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j3CEbfOY039479; Tue, 12 Apr 2005 08:37:41 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 12 Apr 2005 08:37:47 -0600 (MDT) Message-Id: <20050412.083747.00822461.imp@bsdimp.com> To: bms@spc.org From: "M. Warner Losh" In-Reply-To: <20050412131535.GA784@empiric.icir.org> References: <20050412131535.GA784@empiric.icir.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 cc: freebsd-current@freebsd.org Subject: Re: [PATCH] Allow pciconf(8) to be used with CardBus devices X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 12 Apr 2005 14:39:21 -0000 Be careful here. I have similar changes in my tree, but they broke the lspci port. Please test with that port before you commit. These changes are actually a little better than the ones I have knocking around, so subject to that one caveat, go fer it. Warner From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 14:41:18 2005 Return-Path: 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 3189A16A4CF; Tue, 12 Apr 2005 14:41:18 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.194.102.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id E282443D5A; Tue, 12 Apr 2005 14:41:17 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 29D5C5125F; Tue, 12 Apr 2005 07:41:17 -0700 (PDT) Date: Tue, 12 Apr 2005 07:41:17 -0700 From: Kris Kennaway To: Don Lewis Message-ID: <20050412144116.GA39174@xor.obsecurity.org> References: <20050412035111.GA31366@xor.obsecurity.org> <200504121201.j3CC1nZ1035643@gw.catspoiler.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="envbJBWh7q8WU6mo" Content-Disposition: inline In-Reply-To: <200504121201.j3CC1nZ1035643@gw.catspoiler.org> User-Agent: Mutt/1.4.2.1i cc: current@FreeBSD.org cc: kris@obsecurity.org Subject: Re: Softupdates not preventing lengthy fsck X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 12 Apr 2005 14:41:18 -0000 --envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 12, 2005 at 05:01:49AM -0700, Don Lewis wrote: > On 11 Apr, Kris Kennaway wrote: > > On Mon, Apr 11, 2005 at 06:43:17PM -0700, Don Lewis wrote: > >> On 11 Apr, Kris Kennaway wrote: > >> > I'm seeing the following problem: on 6.0 machines which have had a l= ot > >> > of FS activity in the past but are currently quiet, an unclean reboot > >> > will require an hour or more of fscking and will end up clearing > >> > thousands of inodes: > >> >=20 > >> > [...] > >> > /dev/da0s1e: UNREF FILE I=3D269731 OWNER=3Droot MODE=3D100644 > >> > /dev/da0s1e: SIZE=3D8555 MTIME=3DApr 18 02:29 2002 (CLEARED) > >>=20 > >> > /dev/da0s1e: UNREF FILE I=3D269741 OWNER=3Droot MODE=3D100644 > >> > [...] > >> >=20 > >> > It's as if dirty buffers aren't being written out properly, or > >> > something. Has anyone else seen this? > >>=20 > >> This looks a lot like it could be a vnode refcnt leak. Files won't get > >> removed from the disk while they are still in use (the old unlink while > >> open trick). Could nullfs be a factor? > >=20 > > Yes, I make extensive use of read-only nullfs. > >=20 > > Kris (fsck still running) >=20 > It would also be interesting to find out why fsck is taking so long to > run. I don't see anything obvious in the code. I can take a transcript of the entire fsck next time if you like :-) (it ran for more than 5 hours on the 24G drive and was still going after I went to bed) Kris --envbJBWh7q8WU6mo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCW94MWry0BWjoQKURAtIXAJ46XC8vUmBlFkh9CcuE2lYpr+B7nwCdFLpS zGrf0Nw5VPIA3Sm7XYEE1yU= =DJRf -----END PGP SIGNATURE----- --envbJBWh7q8WU6mo-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 14:55:37 2005 Return-Path: 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 9183716A4CE for ; Tue, 12 Apr 2005 14:55:37 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB45743D46 for ; Tue, 12 Apr 2005 14:55:36 +0000 (GMT) (envelope-from robbak@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so1901072wri for ; Tue, 12 Apr 2005 07:55:33 -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:references; b=gmYFbMe6w6dKEtSmL0vE9AMU0OLSIDSKzJR6UUH8rxzH4QoXZXJaxRrj7SkcZsO/rnbDR/8xisSic5/IKqlnMwU+J7UVoHWN4N8qmKohLSvc1l1UbEipcRg/IKl8wINJPpktWqkicrxqGCFtBsQWw+3/panPIhyr+AEG8EsEZz0= Received: by 10.54.53.77 with SMTP id b77mr441259wra; Tue, 12 Apr 2005 07:55:33 -0700 (PDT) Received: by 10.54.14.15 with HTTP; Tue, 12 Apr 2005 07:55:33 -0700 (PDT) Message-ID: Date: Wed, 13 Apr 2005 00:55:33 +1000 From: Robert Backhaus To: "M. Warner Losh" In-Reply-To: <20050412.083747.00822461.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <20050412131535.GA784@empiric.icir.org> <20050412.083747.00822461.imp@bsdimp.com> cc: bms@spc.org cc: freebsd-current@freebsd.org Subject: Re: [PATCH] Allow pciconf(8) to be used with CardBus devices X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Robert Backhaus List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 14:55:37 -0000 On Apr 13, 2005 12:37 AM, M. Warner Losh wrote: > Be careful here. I have similar changes in my tree, but they broke > the lspci port. Please test with that port before you commit. If anyone's searching, it's part of the /sysutils/pciutils port From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 14:59:59 2005 Return-Path: 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 5FE9F16A4CE for ; Tue, 12 Apr 2005 14:59:59 +0000 (GMT) Received: from mta13-winn.mailhost.ntl.com (smtpout19.mailhost.ntl.com [212.250.162.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A1CA43D5A for ; Tue, 12 Apr 2005 14:59:58 +0000 (GMT) (envelope-from tom.hurst@clara.net) Received: from aamta07-winn.mailhost.ntl.com ([212.250.162.8]) by mta13-winn.mailhost.ntl.com with ESMTP <20050412145957.ZBKG2577.mta13-winn.mailhost.ntl.com@aamta07-winn.mailhost.ntl.com>; Tue, 12 Apr 2005 15:59:57 +0100 Received: from voi.aagh.net ([81.104.55.176]) by aamta07-winn.mailhost.ntl.com with ESMTP <20050412145957.EDPW10174.aamta07-winn.mailhost.ntl.com@voi.aagh.net>; Tue, 12 Apr 2005 15:59:57 +0100 Received: from freaky by voi.aagh.net with local (Exim 4.44 (FreeBSD)) id 1DLMrr-000Pop-AD; Tue, 12 Apr 2005 15:59:55 +0100 Date: Tue, 12 Apr 2005 15:59:55 +0100 From: Thomas Hurst To: Stephen McKay Message-ID: <20050412145955.GA97179@voi.aagh.net> Mail-Followup-To: Stephen McKay , Garrett Wollman , freebsd-current@FreeBSD.org References: <20050327223238.GA749@polands.org> <010401c53385$584a04c0$6800000a@venti> <20050329041527.GA9586@VARK.MIT.EDU> <20050329062550.GA69824@cirb503493.alcatel.com.au> <200503301139.j2UBdMp5016442@dungeon.home> <200503301449.j2UEn1v5061914@khavrinen.lcs.mit.edu> <200503310148.j2V1mvL3006507@dungeon.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503310148.j2V1mvL3006507@dungeon.home> Organization: Not much. User-Agent: Mutt/1.5.6i Sender: Thomas Hurst cc: freebsd-current@FreeBSD.org cc: Garrett Wollman Subject: Re: Heads up: gtar gone from base system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 12 Apr 2005 14:59:59 -0000 * Stephen McKay (smckay@internode.on.net) wrote: > It's obvious that "cp" has split hard links for all its life because > the original programmer was lazy. That this laziness has been > codified in POSIX is not something to be cheered, although at this > late stage it may be too hard to fix. A little bird tells me GNU cp has a -d option which makes it handle hardlinks properly, and an -a option so you can just do cp -a src dest. Maybe worth adopting? -- Thomas 'Freaky' Hurst http://hur.st/ From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 15:01:48 2005 Return-Path: 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 28D2016A4DD; Tue, 12 Apr 2005 15:01:48 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C18143D48; Tue, 12 Apr 2005 15:01:45 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j3CF4xkI038127; Tue, 12 Apr 2005 09:04:59 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <425BE215.4090406@samsco.org> Date: Tue, 12 Apr 2005 08:58:29 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kris Kennaway References: <20050412035111.GA31366@xor.obsecurity.org> <200504121201.j3CC1nZ1035643@gw.catspoiler.org> <20050412144116.GA39174@xor.obsecurity.org> In-Reply-To: <20050412144116.GA39174@xor.obsecurity.org> 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: Don Lewis cc: current@freebsd.org Subject: Re: Softupdates not preventing lengthy fsck X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 12 Apr 2005 15:01:48 -0000 Kris Kennaway wrote: > On Tue, Apr 12, 2005 at 05:01:49AM -0700, Don Lewis wrote: > >>On 11 Apr, Kris Kennaway wrote: >> >>>On Mon, Apr 11, 2005 at 06:43:17PM -0700, Don Lewis wrote: >>> >>>>On 11 Apr, Kris Kennaway wrote: >>>> >>>>>I'm seeing the following problem: on 6.0 machines which have had a lot >>>>>of FS activity in the past but are currently quiet, an unclean reboot >>>>>will require an hour or more of fscking and will end up clearing >>>>>thousands of inodes: >>>>> >>>>>[...] >>>>>/dev/da0s1e: UNREF FILE I=269731 OWNER=root MODE=100644 >>>>>/dev/da0s1e: SIZE=8555 MTIME=Apr 18 02:29 2002 (CLEARED) >>>> >>>>>/dev/da0s1e: UNREF FILE I=269741 OWNER=root MODE=100644 >>>>>[...] >>>>> >>>>>It's as if dirty buffers aren't being written out properly, or >>>>>something. Has anyone else seen this? >>>> >>>>This looks a lot like it could be a vnode refcnt leak. Files won't get >>>>removed from the disk while they are still in use (the old unlink while >>>>open trick). Could nullfs be a factor? >>> >>>Yes, I make extensive use of read-only nullfs. >>> >>>Kris (fsck still running) >> >>It would also be interesting to find out why fsck is taking so long to >>run. I don't see anything obvious in the code. > > > I can take a transcript of the entire fsck next time if you like :-) > (it ran for more than 5 hours on the 24G drive and was still going > after I went to bed) > > Kris Don might not know that your workload involves creating and deleting full ports/ trees repeatedly, and those trees contain hundreds of tousands of inodes each. If there is a reference count leak and those deletions aren't ever being finalized, then there would be a whole lot of work for fsck to do =-) Might also explain why disks have been unexpectedly filling up on package machines (like mine). Scott From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 15:43:01 2005 Return-Path: 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 D5B1516A4CE; Tue, 12 Apr 2005 15:43:01 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39A0043D1D; Tue, 12 Apr 2005 15:43:01 +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 j3CFh0e5082654; Tue, 12 Apr 2005 11:43:00 -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 j3CFh8wi083697; Tue, 12 Apr 2005 11:43:08 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 6A8267306E; Tue, 12 Apr 2005 11:43:00 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050412154300.6A8267306E@freebsd-current.sentex.ca> Date: Tue, 12 Apr 2005 11:43:00 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.82, clamav-milter version 0.82 on clamscanner4 X-Virus-Status: Clean Subject: [current tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 15:43:02 -0000 TB --- 2005-04-12 14:24:11 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-12 14:24:11 - starting CURRENT tinderbox run for powerpc/powerpc TB --- 2005-04-12 14:24:11 - checking out the source tree TB --- 2005-04-12 14:24:11 - cd /home/tinderbox/CURRENT/powerpc/powerpc TB --- 2005-04-12 14:24:11 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-12 14:30:50 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-12 14:30:50 - cd /home/tinderbox/CURRENT/powerpc/powerpc/src TB --- 2005-04-12 14:30:50 - /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-04-12 15:39:02 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-12 15:39:02 - cd /home/tinderbox/CURRENT/powerpc/powerpc/src TB --- 2005-04-12 15:39:02 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Tue Apr 12 15:39:03 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 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/powerpc/powerpc/src/sys -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/altq -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/pf -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Wno-error /tinderbox/CURRENT/powerpc/powerpc/src/sys/powerpc/powermac/uninorth.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 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/powerpc/powerpc/src/sys -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/altq -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/pf -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Wno-error /tinderbox/CURRENT/powerpc/powerpc/src/sys/powerpc/psim/iobus.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 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/powerpc/powerpc/src/sys -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/altq -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/pf -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/powerpc/powerpc/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Wno-error /tinderbox/CURRENT/powerpc/powerpc/src/sys/powerpc/psim/ata_iobus.c /tinderbox/CURRENT/powerpc/powerpc/src/sys/powerpc/psim/ata_iobus.c: In function `ata_iobus_alloc_resource': /tinderbox/CURRENT/powerpc/powerpc/src/sys/powerpc/psim/ata_iobus.c:171: error: `ATA_ALTADDR_RID' undeclared (first use in this function) /tinderbox/CURRENT/powerpc/powerpc/src/sys/powerpc/psim/ata_iobus.c:171: error: (Each undeclared identifier is reported only once /tinderbox/CURRENT/powerpc/powerpc/src/sys/powerpc/psim/ata_iobus.c:171: error: for each function it appears in.) /tinderbox/CURRENT/powerpc/powerpc/src/sys/powerpc/psim/ata_iobus.c:174: error: `ATA_ALTIOSIZE' undeclared (first use in this function) *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/obj/powerpc/tinderbox/CURRENT/powerpc/powerpc/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. TB --- 2005-04-12 15:43:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-12 15:43:00 - ERROR: failed to build generic kernel TB --- 2005-04-12 15:43:00 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 15:51:32 2005 Return-Path: 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 84A5F16A4CE for ; Tue, 12 Apr 2005 15:51:32 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65EA043D41 for ; Tue, 12 Apr 2005 15:51:32 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 5549072DE4; Tue, 12 Apr 2005 08:51:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 509F872DDF; Tue, 12 Apr 2005 08:51:32 -0700 (PDT) Date: Tue, 12 Apr 2005 08:51:32 -0700 (PDT) From: Doug White To: Michael Vince In-Reply-To: <42598382.5020509@roq.com> Message-ID: <20050412084854.W2178@carver.gumbysoft.com> References: <787bbe1c0504070307670f5e5d@mail.gmail.com> <4255182E.1020002@centtech.com><42551E94.30800@centtech.com> <787bbe1c05040705254c89fea@mail.gmail.com> <42598382.5020509@roq.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: =?UTF-8?B?U8WCYXdlayDFu2Fr?= cc: freebsd-current@freebsd.org cc: Eric Anderson cc: Marian Hettwer Subject: Re: Serial console install X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 12 Apr 2005 15:51:32 -0000 On Mon, 11 Apr 2005, Michael Vince wrote: > Also I would like to make aware to the discussion IPMI which I believe > in Version 2 has console support, > This stuff seems to be the future of serial console, I have found it > frustrating that Dell sell most of their servers with only 1 serial > port, I believe there excuse is IPMI. > > http://people.freebsd.org/~dwhite/ipmi/ > http://www.intel.com/design/servers/ipmi/ > http://www.freebsdsystems.com/ipmi-tech.php This just rebroadcasts the BIOS console redirection. Once FreeBSD starts up that goes away. I looked at implementing an IPMIv2 console client and gave up since the serial console protocol is gnarly. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 15:59:20 2005 Return-Path: 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 E052316A4CE; Tue, 12 Apr 2005 15:59:19 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 916FE43D1D; Tue, 12 Apr 2005 15:59:19 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 79E9A72DE7; Tue, 12 Apr 2005 08:59:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 77C7872DE4; Tue, 12 Apr 2005 08:59:19 -0700 (PDT) Date: Tue, 12 Apr 2005 08:59:19 -0700 (PDT) From: Doug White To: David O'Brien In-Reply-To: <20050411032558.GA1406@dragon.NUXI.org> Message-ID: <20050412085900.Y2178@carver.gumbysoft.com> References: <20050411032558.GA1406@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=unknown-8bit Content-Transfer-Encoding: QUOTED-PRINTABLE cc: freebsd-current@freebsd.org Subject: Re: [PANIC] vm? vfs? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 12 Apr 2005 15:59:20 -0000 pseudoterminals. Join the ptcread/write panic club. :-) On Sun, 10 Apr 2005, David O'Brien wrote: > FreeBSD 6.0-CURRENT FreeBSD 6.0-CURRENT #0: Tue Apr 5 12:19:35 PDT 2005 > > GNU gdb 20040810 [GDB v6.x for FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you = are > welcome to change it and/or distribute copies of it under certain conditi= ons. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for detail= s. > This GDB was configured as "i386-portbld-freebsd6.0"... > panic: page fault > panic messages: > --- > Fatal trap 12: page fault while in kernel mode > cpuid =3D 1; apic id =3D 01 > fault virtual address=09=3D 0x0 > fault code=09=09=3D supervisor read, page not present > instruction pointer=09=3D 0x8:0xc063596a > stack pointer=09 =3D 0x10:0xf04e9b64 > frame pointer=09 =3D 0x10:0xf04e9b90 > code segment=09=09=3D base 0x0, limit 0xfffff, type 0x1b > =09=09=09=3D DPL 0, pres 1, def32 1, gran 1 > processor eflags=09=3D interrupt enabled, resume, IOPL =3D 0 > current process=09=09=3D 1062 (xterm-static) > trap number=09=09=3D 12 > panic: page fault > cpuid =3D 1 > KDB: stack backtrace: > kdb_backtrace(c067f02d,1,c065a072,f04e9a88,c344a730) at 0xc04f910e =3D kd= b_backtrace+0x2e > panic(c065a072,c0680005,f04e9b24,1,1) at 0xc04dc508 =3D panic+0x128 > trap_fatal(f04e9b24,0,c06801e7,2c3,c344a730) at 0xc0637a84 =3D trap_fatal= +0x304 > trap_pfault(f04e9b24,0,0,f04e9b1c,0) at 0xc0637758 =3D trap_pfault+0x1b8 > trap(18,10,10,f04e9bac,0) at 0xc0637340 =3D trap+0x350 > calltrap() at 0xc062408a =3D calltrap+0x5 > --- trap 0xc, eip =3D 0xc063596a, esp =3D 0xf04e9b64, ebp =3D 0xf04e9b90 = --- > generic_bcopy(c37d2038,f04e9bac,64,808cc30,c06b92a0) at 0xc063596a =3D ge= neric_bcopy+0x1a > ptcread(c33f1500,f04e9c80,4,3ae,1000) at 0xc0518d95 =3D ptcread+0x185 > devfs_read_f(c380a360,f04e9c80,c3395880,0,c344a730) at 0xc049a806 =3D dev= fs_read_f+0xa6 > dofileread(c344a730,c380a360,4,8085c20,1000) at 0xc0504aa2 =3D dofileread= +0xc2 > read(c344a730,f04e9d14,c,3ff,3) at 0xc050490b =3D read+0x6b > syscall(2f,2f,2f,8085c20,80a0084) at 0xc0637de2 =3D syscall+0x2b2 > Xint0x80_syscall() at 0xc06240df =3D Xint0x80_syscall+0x1f > --- syscall (3, FreeBSD ELF32, read), eip =3D 0x28382edf, esp =3D 0xbfbfe= 66c, ebp =3D 0xbfbfe698 --- > Uptime: 1d8h49m32s > Dumping 1536 MB > [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [= CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 16[CTRL-C to abort] [= CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTR= L-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 32[CTR= L-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 48[CTR= L-C to abort] 64 80[CTRL-C to abort] 96 112 128 144 160 176 192 208 224 2= 40 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 512 528 = 544 560 576 592 608 624 640 656 672 688 704 720 736 752 768 784 800 816 832= 848 864 880 896 912 928 944 960 976 992 1008 1024 1040 1056 1072 1088 1104= 1120 1136 1152 1168 1184 1200 1216 1232 1248 1264 1280 1296 1312 1328 1344= 1360 1376 1392 1408 1424 1440 1456 1472 1488 1504 1520 > --- > #0 doadump () at pcpu.h:164 > 164=09=09__asm __volatile("movl %%fs:0,%0" : "=3Dr" (td)); > doadump () at pcpu.h:164 > 164=09=09__asm __volatile("movl %%fs:0,%0" : "=3Dr" (td)); > (kgdb) where > #0 doadump () at pcpu.h:164 > #1 0xc04dc1d2 in boot (howto=3D260) at ../../../kern/kern_shutdown.c:398 > #2 0xc04dc583 in panic (fmt=3D0xc065a072 "%s") > at ../../../kern/kern_shutdown.c:554 > #3 0xc0637a84 in trap_fatal (frame=3D0xf04e9b24, eva=3D0) > at ../../../i386/i386/trap.c:806 > #4 0xc0637758 in trap_pfault (frame=3D0xf04e9b24, usermode=3D0, eva=3D0) > at ../../../i386/i386/trap.c:724 > #5 0xc0637340 in trap (frame=3D > {tf_fs =3D 24, tf_es =3D 16, tf_ds =3D 16, tf_edi =3D -263283796, t= f_esi =3D 0, tf_ebp =3D -263283824, tf_isp =3D -263283888, tf_ebx =3D 38, t= f_edx =3D 0, tf_ecx =3D 9, tf_eax =3D -263283796, tf_trapno =3D 12, tf_err = =3D 0, tf_eip =3D -1067230870, tf_cs =3D 8, tf_eflags =3D 66071, tf_esp =3D= -1015209928, tf_ss =3D 128}) > at ../../../i386/i386/trap.c:414 > #6 0xc062408a in calltrap () at ../../../i386/i386/exception.s:139 > #7 0x00000018 in ?? () > #8 0x00000010 in ?? () > #9 0x00000010 in ?? () > #10 0xf04e9bac in ?? () > #11 0x00000000 in ?? () > #12 0xf04e9b90 in ?? () > #13 0xf04e9b50 in ?? () > #14 0x00000026 in ?? () > #15 0x00000000 in ?? () > #16 0x00000009 in ?? () > #17 0xf04e9bac in ?? () > #18 0x0000000c in ?? () > #19 0x00000000 in ?? () > #20 0xc063596a in generic_bcopy () at ../../../i386/i386/support.s:489 > ---Type to continue, or q to quit--- > #21 0xc37d2038 in ?? () > #22 0x00000080 in ?? () > #23 0xc05199fa in q_to_b (clistp=3D0xc063596a, > dest=3D0xf04e9bac "\r\n/FBSD: write failed, filesystem is \025?=C3`= =A3\200=C3=F0\233N=F0=EA\003K=C0=A0\222k=C0", amount=3D100) at ../../../ker= n/tty_subr.c:290 > #24 0xc0518d95 in ptcread (dev=3D0x0, uio=3D0xf04e9c80, flag=3D4) at libk= ern.h:56 > #25 0xc049a806 in devfs_read_f (fp=3D0xc380a360, uio=3D0xf04e9c80, > cred=3D0xc3395880, flags=3D0, td=3D0xc344a730) > at ../../../fs/devfs/devfs_vnops.c:943 > #26 0xc0504aa2 in dofileread (td=3D0xc344a730, fp=3D0xc380a360, fd=3D0, b= uf=3D0x0, > nbyte=3D3228113056, offset=3DUnhandled dwarf expression opcode 0x93 > ) at file.h:234 > #27 0xc050490b in read (td=3D0xc344a730, uap=3D0xf04e9d14) > at ../../../kern/sys_generic.c:107 > #28 0xc0637de2 in syscall (frame=3D > {tf_fs =3D 47, tf_es =3D 47, tf_ds =3D 47, tf_edi =3D 134765600, tf= _esi =3D 134873220, tf_ebp =3D -1077942632, tf_isp =3D -263283340, tf_ebx = =3D 0, tf_edx =3D 0, tf_ecx =3D 4, tf_eax =3D 3, tf_trapno =3D 0, tf_err = =3D 2, tf_eip =3D 674770655, tf_cs =3D 31, tf_eflags =3D 642, tf_esp =3D -1= 077942676, tf_ss =3D 47}) > at ../../../i386/i386/trap.c:951 > #29 0xc06240df in Xint0x80_syscall () at ../../../i386/i386/exception.s:2= 00 > #30 0x0000002f in ?? () > #31 0x0000002f in ?? () > #32 0x0000002f in ?? () > #33 0x08085c20 in ?? () > #34 0x080a0084 in ?? () > #35 0xbfbfe698 in ?? () > #36 0xf04e9d74 in ?? () > #37 0x00000000 in ?? () > #38 0x00000000 in ?? () > ---Type to continue, or q to quit--- > #39 0x00000004 in ?? () > #40 0x00000003 in ?? () > #41 0x00000000 in ?? () > #42 0x00000002 in ?? () > #43 0x28382edf in ?? () > #44 0x0000001f in ?? () > #45 0x00000282 in ?? () > #46 0xbfbfe66c in ?? () > #47 0x0000002f in ?? () > #48 0x28184f96 in ?? () > #49 0x28184fa6 in ?? () > #50 0x28184fb6 in ?? () > #51 0x28184fc6 in ?? () > #52 0x49eee000 in ?? () > #53 0xc350a5f4 in ?? () > #54 0xc344a730 in ?? () > #55 0xf04e99b0 in ?? () > #56 0xf04e9990 in ?? () > #57 0xc2bc4a10 in ?? () > #58 0xc04efda0 in sched_switch (td=3D0x80a0084, newtd=3D0x0, flags=3D---C= an't read userspace from dump, or kernel process--- > > ) > at ../../../kern/sched_4bsd.c:963 > Previous frame inner to this frame (corrupt stack?) > _______________________________________________ > 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 Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 16:45:01 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 599C316A4CF; Tue, 12 Apr 2005 16:45:01 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.3/8.13.1) with ESMTP id j3CGjiSs058347; Tue, 12 Apr 2005 12:45:44 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.3/8.13.1/Submit) id j3CGjifM058346; Tue, 12 Apr 2005 12:45:44 -0400 (EDT) (envelope-from green) Date: Tue, 12 Apr 2005 12:45:44 -0400 From: Brian Fundakowski Feldman To: Doug White Message-ID: <20050412164544.GC981@green.homeunix.org> References: <20050411032558.GA1406@dragon.NUXI.org> <20050412085900.Y2178@carver.gumbysoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20050412085900.Y2178@carver.gumbysoft.com> User-Agent: Mutt/1.5.6i cc: freebsd-current@freebsd.org Subject: Re: [PANIC] vm? vfs? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 12 Apr 2005 16:45:01 -0000 On Tue, Apr 12, 2005 at 08:59:19AM -0700, Doug White wrote: > On Sun, 10 Apr 2005, David O'Brien wrote: > > > FreeBSD 6.0-CURRENT FreeBSD 6.0-CURRENT #0: Tue Apr 5 12:19:35 PDT 2005 > > > > GNU gdb 20040810 [GDB v6.x for FreeBSD] > > Copyright 2004 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and you are > > welcome to change it and/or distribute copies of it under certain conditions. > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for details. > > This GDB was configured as "i386-portbld-freebsd6.0"... > > panic: page fault > > panic messages: > > --- > > Fatal trap 12: page fault while in kernel mode > > cpuid = 1; apic id = 01 > > fault virtual address = 0x0 > > fault code = supervisor read, page not present > > instruction pointer = 0x8:0xc063596a > > stack pointer = 0x10:0xf04e9b64 > > frame pointer = 0x10:0xf04e9b90 > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, def32 1, gran 1 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 1062 (xterm-static) > > trap number = 12 > > panic: page fault > > cpuid = 1 > > KDB: stack backtrace: > > kdb_backtrace(c067f02d,1,c065a072,f04e9a88,c344a730) at 0xc04f910e = kdb_backtrace+0x2e > > panic(c065a072,c0680005,f04e9b24,1,1) at 0xc04dc508 = panic+0x128 > > trap_fatal(f04e9b24,0,c06801e7,2c3,c344a730) at 0xc0637a84 = trap_fatal+0x304 > > trap_pfault(f04e9b24,0,0,f04e9b1c,0) at 0xc0637758 = trap_pfault+0x1b8 > > trap(18,10,10,f04e9bac,0) at 0xc0637340 = trap+0x350 > > calltrap() at 0xc062408a = calltrap+0x5 > > --- trap 0xc, eip = 0xc063596a, esp = 0xf04e9b64, ebp = 0xf04e9b90 --- > > generic_bcopy(c37d2038,f04e9bac,64,808cc30,c06b92a0) at 0xc063596a = generic_bcopy+0x1a > > ptcread(c33f1500,f04e9c80,4,3ae,1000) at 0xc0518d95 = ptcread+0x185 > > devfs_read_f(c380a360,f04e9c80,c3395880,0,c344a730) at 0xc049a806 = devfs_read_f+0xa6 > > dofileread(c344a730,c380a360,4,8085c20,1000) at 0xc0504aa2 = dofileread+0xc2 > > read(c344a730,f04e9d14,c,3ff,3) at 0xc050490b = read+0x6b > > syscall(2f,2f,2f,8085c20,80a0084) at 0xc0637de2 = syscall+0x2b2 > > Xint0x80_syscall() at 0xc06240df = Xint0x80_syscall+0x1f > > --- syscall (3, FreeBSD ELF32, read), eip = 0x28382edf, esp = 0xbfbfe66c, ebp = 0xbfbfe698 --- > > Uptime: 1d8h49m32s > > Dumping 1536 MB > > [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 16[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 32[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 48[CTRL-C to abort] 64 80[CTRL-C to abort] 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624 640 656 672 688 704 720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976 992 1008 1024 1040 1056 1072 1088 1104 1120 1136 1152 1168 1184 1200 1216 1232 1248 1264 1280 1296 1312 1328 1344 1360 1376 1392 1408 1424 1440 1456 1472 1488 1504 1520 > > --- > > #0 doadump () at pcpu.h:164 > > 164 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); > > doadump () at pcpu.h:164 > > 164 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); > > (kgdb) where > > #0 doadump () at pcpu.h:164 > > #1 0xc04dc1d2 in boot (howto=260) at ../../../kern/kern_shutdown.c:398 > > #2 0xc04dc583 in panic (fmt=0xc065a072 "%s") > > at ../../../kern/kern_shutdown.c:554 > > #3 0xc0637a84 in trap_fatal (frame=0xf04e9b24, eva=0) > > at ../../../i386/i386/trap.c:806 > > #4 0xc0637758 in trap_pfault (frame=0xf04e9b24, usermode=0, eva=0) > > at ../../../i386/i386/trap.c:724 > > #5 0xc0637340 in trap (frame= > > {tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -263283796, tf_esi = 0, tf_ebp = -263283824, tf_isp = -263283888, tf_ebx = 38, tf_edx = 0, tf_ecx = 9, tf_eax = -263283796, tf_trapno = 12, tf_err = 0, tf_eip = -1067230870, tf_cs = 8, tf_eflags = 66071, tf_esp = -1015209928, tf_ss = 128}) > > at ../../../i386/i386/trap.c:414 > > #6 0xc062408a in calltrap () at ../../../i386/i386/exception.s:139 > > #7 0x00000018 in ?? () > > #8 0x00000010 in ?? () > > #9 0x00000010 in ?? () > > #10 0xf04e9bac in ?? () > > #11 0x00000000 in ?? () > > #12 0xf04e9b90 in ?? () > > #13 0xf04e9b50 in ?? () > > #14 0x00000026 in ?? () > > #15 0x00000000 in ?? () > > #16 0x00000009 in ?? () > > #17 0xf04e9bac in ?? () > > #18 0x0000000c in ?? () > > #19 0x00000000 in ?? () > > #20 0xc063596a in generic_bcopy () at ../../../i386/i386/support.s:489 > > ---Type to continue, or q to quit--- > > #21 0xc37d2038 in ?? () > > #22 0x00000080 in ?? () > > #23 0xc05199fa in q_to_b (clistp=0xc063596a, > > dest=0xf04e9bac "\r\n/FBSD: write failed, filesystem is \025?Ã`£\200Ãð\233Nðê\003KÀ \222kÀ", amount=100) at ../../../kern/tty_subr.c:290 > > #24 0xc0518d95 in ptcread (dev=0x0, uio=0xf04e9c80, flag=4) at libkern.h:56 > > #25 0xc049a806 in devfs_read_f (fp=0xc380a360, uio=0xf04e9c80, > > cred=0xc3395880, flags=0, td=0xc344a730) > > at ../../../fs/devfs/devfs_vnops.c:943 > > #26 0xc0504aa2 in dofileread (td=0xc344a730, fp=0xc380a360, fd=0, buf=0x0, > > nbyte=3228113056, offset=Unhandled dwarf expression opcode 0x93 > > ) at file.h:234 > > #27 0xc050490b in read (td=0xc344a730, uap=0xf04e9d14) > > at ../../../kern/sys_generic.c:107 > > #28 0xc0637de2 in syscall (frame= > > {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134765600, tf_esi = 134873220, tf_ebp = -1077942632, tf_isp = -263283340, tf_ebx = 0, tf_edx = 0, tf_ecx = 4, tf_eax = 3, tf_trapno = 0, tf_err = 2, tf_eip = 674770655, tf_cs = 31, tf_eflags = 642, tf_esp = -1077942676, tf_ss = 47}) > > at ../../../i386/i386/trap.c:951 > > #29 0xc06240df in Xint0x80_syscall () at ../../../i386/i386/exception.s:200 > [...] > pseudoterminals. Join the ptcread/write panic club. :-) I don't see anything that should be corrupting the stack. The uio parameter is corrupt all the way up to the dofileread() call (but it can't possibly be incorrect within dofileread()). -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 17:08:33 2005 Return-Path: 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 689BE16A4D1 for ; Tue, 12 Apr 2005 17:08:33 +0000 (GMT) Received: from mail26.sea5.speakeasy.net (mail26.sea5.speakeasy.net [69.17.117.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DC1B43D1D for ; Tue, 12 Apr 2005 17:08:33 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 9661 invoked from network); 12 Apr 2005 17:08:32 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 12 Apr 2005 17:08:32 -0000 Received: from [131.106.57.68] (p178.n-lapop01.stsn.com [12.129.240.178]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j3CH871I022095; Tue, 12 Apr 2005 13:08:24 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Antoine Brodin Date: Tue, 12 Apr 2005 12:52:07 -0400 User-Agent: KMail/1.8 References: <200504112031.26979.jhb@FreeBSD.org> <20050412092732.72c9c87a.antoine.brodin@laposte.net> In-Reply-To: <20050412092732.72c9c87a.antoine.brodin@laposte.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504121252.09014.jhb@FreeBSD.org> X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: freebsd-current@FreeBSD.org cc: k-gleb@yandex.ru cc: dan.cojocar@gmail.com cc: nate@root.org Subject: Re: Interrupt storm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 12 Apr 2005 17:08:33 -0000 On Tuesday 12 April 2005 03:27 am, Antoine Brodin wrote: > John Baldwin wrote: > > On Saturday 09 April 2005 05:57 am, Antoine Brodin wrote: > > > John Baldwin wrote: > > > > I think your other link devices are meant to be used in APIC mode > > > > (note their names start with 'A') and thus I think they are aliases > > > > for the other link devices. So when I turn off the alias, I turn off > > > > the non-APIC mode one as well. Working BIOSen handle this by having > > > > the same link device change its behavior (different _PRS return > > > > values) depending on the PIC mode. It's not easy to determine if a > > > > link is just not used (for example, if no card is plugged into a slot > > > > with a dedicated link) or if it's an alias. I think having two ACPI > > > > devices alias to the same hardware is a bug in the BIOS though. > > > > Perhaps your BIOS vendor can be convinced to fix this. Can you see > > > > if Linux has the same problem btw? > > > > > > I've just sent a technical support request to ASUS. I'll let you know > > > when they reply. > > > Linux doesn't have the same problem: I tested with a knoppix live cd > > > yesterday. > > > dmesg: http://bsd.miki.eu.org/~antoine/knoppix36.dmesg , but it doesn't > > > look very helpful. > > > > Actually, it is. What Linux is doing is probing all the link devices > > before it probes any PCI devices, so all the _DIS calls happen before any > > interrupts are routed. I believe Nate knows how to get FreeBSD to do > > something similar via a hack. > > There's this hack that works here: > > %%% > Index: acpi.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/acpica/acpi.c,v > retrieving revision 1.210 > diff -u -p -r1.210 acpi.c > --- acpi.c 31 Mar 2005 19:07:26 -0000 1.210 > +++ acpi.c 9 Apr 2005 09:50:54 -0000 > @@ -1503,6 +1503,9 @@ acpi_probe_order(ACPI_HANDLE handle, int > } else if (acpi_MatchHid(handle, "PNP0C09")) { > *order = 2; > ret = 1; > + } else if (acpi_MatchHid(handle, "PNP0C0F")) { > + *order = 3; > + ret = 1; > } > > return (ret); > %%% > > Cheers, > > Antoine Right. Do you think it would be ok to commit that Nate? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 17:08:37 2005 Return-Path: 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 8B61316A4D1 for ; Tue, 12 Apr 2005 17:08:37 +0000 (GMT) Received: from mail27.sea5.speakeasy.net (mail27.sea5.speakeasy.net [69.17.117.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F94E43D31 for ; Tue, 12 Apr 2005 17:08:37 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 18968 invoked from network); 12 Apr 2005 17:08:37 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 12 Apr 2005 17:08:36 -0000 Received: from [131.106.57.68] (p178.n-lapop01.stsn.com [12.129.240.178]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j3CH871J022095; Tue, 12 Apr 2005 13:08:31 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Divacky Roman Date: Tue, 12 Apr 2005 12:53:50 -0400 User-Agent: KMail/1.8 References: <20050406130909.GA90294@stud.fit.vutbr.cz> <200504112038.32964.jhb@FreeBSD.org> <20050412073810.GA89527@stud.fit.vutbr.cz> In-Reply-To: <20050412073810.GA89527@stud.fit.vutbr.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504121253.50950.jhb@FreeBSD.org> X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: current@FreeBSD.org Subject: Re: slow kbd input on 6-current on amd64@nforce3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 12 Apr 2005 17:08:37 -0000 On Tuesday 12 April 2005 03:38 am, Divacky Roman wrote: > On Mon, Apr 11, 2005 at 08:38:32PM -0400, John Baldwin wrote: > > On Wednesday 06 April 2005 09:09 am, Divacky Roman wrote: > > > as I have mentioned on the list I have very slow keyboard input. it > > > might be related to kbd not having an IRQ assigned. I repeat once again > > > that it worked on 5.3R. > > > > Actually, now that I look at this, you have a buggy BIOS. It is lying > > and claiming that some PCI interrupts are active-hi rather than > > active-low. Hmm, the 5.3 dmesg you gave me included APIC, while this one > > does not. Does disabling ACPI make your keyboard happy on 6.0 by chance? > > It doesnt boot with acpi enabled (stops in probing ata devices, but it > never worked so I think ata is not the only culprit) Ok. > what can I do with it? would some quirk made the trick? why it worked in > 5.3R? I don't know at this point. Does 6.0 in any configuration work ok? (ACPI !APIC, ACPI APIC, !ACPI APIC, !ACPI !APIC) -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 17:57:52 2005 Return-Path: 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 A455A16A4CE; Tue, 12 Apr 2005 17:57:52 +0000 (GMT) Received: from ylpvm01.prodigy.net (ylpvm01-ext.prodigy.net [207.115.57.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1C1E43D39; Tue, 12 Apr 2005 17:57:51 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222])j3CHvn4H032150; Tue, 12 Apr 2005 13:57:50 -0400 Message-ID: <425C0B98.7060605@root.org> Date: Tue, 12 Apr 2005 10:55:36 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041205) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Antoine Brodin References: <200504081529.33026.jhb@FreeBSD.org> <20050409115745.31a0059c.antoine.brodin@laposte.net> <200504112031.26979.jhb@FreeBSD.org> <20050412092732.72c9c87a.antoine.brodin@laposte.net> In-Reply-To: <20050412092732.72c9c87a.antoine.brodin@laposte.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@FreeBSD.org cc: k-gleb@yandex.ru cc: dan.cojocar@gmail.com cc: John Baldwin Subject: Re: Interrupt storm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 12 Apr 2005 17:57:52 -0000 Antoine Brodin wrote: > John Baldwin wrote: > >>On Saturday 09 April 2005 05:57 am, Antoine Brodin wrote: >> >>>John Baldwin wrote: >>> >>>>I think your other link devices are meant to be used in APIC mode (note >>>>their names start with 'A') and thus I think they are aliases for the >>>>other link devices. So when I turn off the alias, I turn off the >>>>non-APIC mode one as well. Working BIOSen handle this by having the same >>>>link device change its behavior (different _PRS return values) depending >>>>on the PIC mode. It's not easy to determine if a link is just not used >>>>(for example, if no card is plugged into a slot with a dedicated link) or >>>>if it's an alias. I think having two ACPI devices alias to the same >>>>hardware is a bug in the BIOS though. Perhaps your BIOS vendor can be >>>>convinced to fix this. Can you see if Linux has the same problem btw? >>> >>>I've just sent a technical support request to ASUS. I'll let you know >>>when they reply. >>>Linux doesn't have the same problem: I tested with a knoppix live cd >>>yesterday. >>>dmesg: http://bsd.miki.eu.org/~antoine/knoppix36.dmesg , but it doesn't >>>look very helpful. >> >>Actually, it is. What Linux is doing is probing all the link devices before >>it probes any PCI devices, so all the _DIS calls happen before any interrupts >>are routed. I believe Nate knows how to get FreeBSD to do something similar >>via a hack. > > > There's this hack that works here: > > %%% > Index: acpi.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/acpica/acpi.c,v > retrieving revision 1.210 > diff -u -p -r1.210 acpi.c > --- acpi.c 31 Mar 2005 19:07:26 -0000 1.210 > +++ acpi.c 9 Apr 2005 09:50:54 -0000 > @@ -1503,6 +1503,9 @@ acpi_probe_order(ACPI_HANDLE handle, int > } else if (acpi_MatchHid(handle, "PNP0C09")) { > *order = 2; > ret = 1; > + } else if (acpi_MatchHid(handle, "PNP0C0F")) { > + *order = 3; > + ret = 1; > } > > return (ret); > %%% That is exactly the right one and we should have been doing this already. -- Nate From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 18:51:15 2005 Return-Path: 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 077A716A4D0; Tue, 12 Apr 2005 18:51:15 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBA4D43D62; Tue, 12 Apr 2005 18:51:14 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id BA3D77A41E; Tue, 12 Apr 2005 11:51:14 -0700 (PDT) Message-ID: <425C18A2.8010807@elischer.org> Date: Tue, 12 Apr 2005 11:51:14 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en, hu MIME-Version: 1.0 To: FreeBSD Current , multimedia@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Anyone working on V4L2 for BSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 12 Apr 2005 18:51:15 -0000 I'm considerring it.. It looks quite doable. (assuming we can get compatible include files without copyright problems.) For compatibility we'd probably want to keep all the V4L prefixes etc. Is anyone else playing with this? I remember someone said they had implemented part of the interface for some specific device recently. Julian From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 19:02:24 2005 Return-Path: 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 C2C0B16A4CF for ; Tue, 12 Apr 2005 19:02:24 +0000 (GMT) Received: from smtp-relay.tamu.edu (smtp-relay.tamu.edu [165.91.143.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8644943D1F for ; Tue, 12 Apr 2005 19:02:21 +0000 (GMT) (envelope-from tyler@tamu.edu) Received: from [192.168.1.161] (evilbit.resnet.tamu.edu [128.194.4.186]) (authenticated bits=0) by smtp-relay.tamu.edu (8.12.10/8.12.10) with ESMTP id j3CJ2FM9039656 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 12 Apr 2005 14:02:19 -0500 (CDT) From: "R. Tyler Ballance" To: FreeBSD Current Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-EJHlE2ItK1iGs1avqBIo" Date: Tue, 12 Apr 2005 14:06:02 -0500 Message-Id: <1113332762.27362.29.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 Subject: strtonum(3) in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 12 Apr 2005 19:02:24 -0000 --=-EJHlE2ItK1iGs1avqBIo Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Quick, sort of, question. Is it worth it to bring strtonum(3) from OpenBSD into FreeBSD-CURRENT. I have the diffs if that's the case, I know that the newer packet filter code from OPENBSD_3_7 that mlaier@ and I are working on uses it in a few places (see: pflogd) but I'm not sure of the merits of bringing strtonum(3) into lib/libc/stdlib... In theory, it should be a better implementation of what atoi(3) and strtol(3) do, but as tg@(mirbsd.org) pointed out to the OpenBSD fellows and myself, it doesn't take hexadecimal values well... Somebody let me know, i've got diffs ready, sort of ;) (or let me know why it's a bad idea) -R. Tyler Ballance --=-EJHlE2ItK1iGs1avqBIo Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iQIVAwUAQlwcGIBeTbTGPYVBAQLz9w//Z+MVdPsFFwlYBKv5AwWhjI6RMWQ7k5pk Km+kF/ivnIJOEqudRvNevByArG9aTA3+PGwn5FNVhv3NiP66Xo0jLlSGPr6RZkip /oQHzMj1eo+/4XfmQp4VmuHDf5DWzkh6MgJYpAKbQpHVKkT83Mhsd9kpJ65zQijG NKwIOQT0LBRrTup9hXL886BTlb1t3+DIbMc0GN+EhQQ0Ar3d4KkmLnpX12UwDOeq MZk3ixcAFEAhWBWEl2FGSkyXgzRVx2FdnVL9gUZ52nJisGlI0qJSxjCggvTJaqlU czAfqPp7v1xv3PVsg3gIVyiUgXFMwKjdL/xKcD1cRi+8HWmMQ4/Tkr0B8YmXpMok V0J9YN+uY0jbiSKwCFEgYkr63I5s5DgGSHGwqLBPpDagrfa7BIJvcYza+mXpnxvu YNe+MjPIqF1WoWXGlXIopQ7nVWota6UVmvAoxrGOEdBRXosI/mmXKtiMqFVqnP8A d34QROs19RTVvcjTQkSD1su0PBcgYFjgdq59IyuQzlHCKL3vbk7NHoEenI0V5L9T Q3avUSn03M+Q5z4JRgNfxSI+cprPJHblDmRAzFAxjPmTbno3jB/Wm6z1E41Nv4UM lzfs4jPu3DU7XDzXg1lUR5Quuq+cuSU+00qZPngLb5tZHGB/b76wwQyaINueD+V/ YPseYNfZ8Bw= =DfA7 -----END PGP SIGNATURE----- --=-EJHlE2ItK1iGs1avqBIo-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 19:12:09 2005 Return-Path: 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 CA50416A4CE for ; Tue, 12 Apr 2005 19:12:09 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F75643D39 for ; Tue, 12 Apr 2005 19:12:09 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j3CJC9YY023701; Tue, 12 Apr 2005 12:12:09 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j3CJC8ZE023700; Tue, 12 Apr 2005 12:12:08 -0700 Date: Tue, 12 Apr 2005 12:12:08 -0700 From: Brooks Davis To: "R. Tyler Ballance" Message-ID: <20050412191208.GA12516@odin.ac.hmc.edu> References: <1113332762.27362.29.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bp/iNruPH9dso1Pn" Content-Disposition: inline In-Reply-To: <1113332762.27362.29.camel@localhost.localdomain> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: FreeBSD Current Subject: Re: strtonum(3) in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 12 Apr 2005 19:12:09 -0000 --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 12, 2005 at 02:06:02PM -0500, R. Tyler Ballance wrote: > Quick, sort of, question. Is it worth it to bring strtonum(3) from > OpenBSD into FreeBSD-CURRENT. I have the diffs if that's the case, I > know that the newer packet filter code from OPENBSD_3_7 that mlaier@ and > I are working on uses it in a few places (see: pflogd) but I'm not sure > of the merits of bringing strtonum(3) into lib/libc/stdlib... >=20 > In theory, it should be a better implementation of what atoi(3) and > strtol(3) do, but as tg@(mirbsd.org) pointed out to the OpenBSD fellows > and myself, it doesn't take hexadecimal values well... >=20 > Somebody let me know, i've got diffs ready, sort of ;) > (or let me know why it's a bad idea) The lack of base handling argument does make it less appealing, but now that OpenBSD has used this name, we're stuck with the API. I would request that you use intmax_t rather than "long long" for the integers. Then the API scales cleanly when some future processor adds 128-bit ints. Since intmax_t is "long long" on all current platforms that wouldn't cause compatability problems with OpenBSD. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --bp/iNruPH9dso1Pn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCXB2IXY6L6fI4GtQRAhKPAJ9LfujeK9u1yOF4yjd2BhX9q39vngCggE2r V3uU1ELwGqeJijQlDpOhrLc= =jRqB -----END PGP SIGNATURE----- --bp/iNruPH9dso1Pn-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 19:45:56 2005 Return-Path: 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 8511F16A4CE for ; Tue, 12 Apr 2005 19:45:56 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F6D443D53 for ; Tue, 12 Apr 2005 19:45:56 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.1/8.13.1) with ESMTP id j3CJjmh3036670; Tue, 12 Apr 2005 12:45:52 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200504121945.j3CJjmh3036670@gw.catspoiler.org> Date: Tue, 12 Apr 2005 12:45:48 -0700 (PDT) From: Don Lewis To: kris@obsecurity.org In-Reply-To: <20050412144116.GA39174@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: current@FreeBSD.org Subject: Re: Softupdates not preventing lengthy fsck X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 12 Apr 2005 19:45:56 -0000 On 12 Apr, Kris Kennaway wrote: > On Tue, Apr 12, 2005 at 05:01:49AM -0700, Don Lewis wrote: >> It would also be interesting to find out why fsck is taking so long to >> run. I don't see anything obvious in the code. > > I can take a transcript of the entire fsck next time if you like :-) > (it ran for more than 5 hours on the 24G drive and was still going > after I went to bed) An approximate number of files and directories deleted and the info returned by ^T would be useful. It would also be useful to know which path to clri() was most commonly being taken. A profile might also be nice to have. From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 19:51:23 2005 Return-Path: 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 8383B16A4CF for ; Tue, 12 Apr 2005 19:51:23 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCF8A43D5C for ; Tue, 12 Apr 2005 19:51:22 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.1/8.13.1) with ESMTP id j3CJpCCY036689; Tue, 12 Apr 2005 12:51:18 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200504121951.j3CJpCCY036689@gw.catspoiler.org> Date: Tue, 12 Apr 2005 12:51:12 -0700 (PDT) From: Don Lewis To: scottl@samsco.org In-Reply-To: <425BE215.4090406@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: current@FreeBSD.org cc: kris@obsecurity.org Subject: Re: Softupdates not preventing lengthy fsck X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 12 Apr 2005 19:51:23 -0000 On 12 Apr, Scott Long wrote: > Kris Kennaway wrote: >> I can take a transcript of the entire fsck next time if you like :-) >> (it ran for more than 5 hours on the 24G drive and was still going >> after I went to bed) >> >> Kris > > Don might not know that your workload involves creating and deleting > full ports/ trees repeatedly, and those trees contain hundreds of > tousands of inodes each. I suspected that, especially given the inode timestamps in the partial transcript. > If there is a reference count leak and those > deletions aren't ever being finalized, then there would be a whole lot > of work for fsck to do =-) Might also explain why disks have been > unexpectedly filling up on package machines (like mine). Sounds likely. When the disk starts looking unexpectedly full, can you unmount the file system or does the attempt fail with and EBUSY error? What happens if you fsck the file system after it has been unmounted? Are snapshots being used? From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 19:57:04 2005 Return-Path: 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 AA5C416A4CE for ; Tue, 12 Apr 2005 19:57:04 +0000 (GMT) Received: from mail16.syd.optusnet.com.au (mail16.syd.optusnet.com.au [211.29.132.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E36743D1D for ; Tue, 12 Apr 2005 19:57:04 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j3CJv15F031224 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 13 Apr 2005 05:57:02 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j3CJv17l000372; Wed, 13 Apr 2005 05:57:01 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j3CJv1k0000371; Wed, 13 Apr 2005 05:57:01 +1000 (EST) (envelope-from pjeremy) Date: Wed, 13 Apr 2005 05:57:01 +1000 From: Peter Jeremy To: "R. Tyler Ballance" Message-ID: <20050412195700.GN89047@cirb503493.alcatel.com.au> References: <1113332762.27362.29.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1113332762.27362.29.camel@localhost.localdomain> User-Agent: Mutt/1.4.2i cc: FreeBSD Current Subject: Re: strtonum(3) in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 12 Apr 2005 19:57:04 -0000 On Tue, 2005-Apr-12 14:06:02 -0500, R. Tyler Ballance wrote: >Quick, sort of, question. Is it worth it to bring strtonum(3) from >OpenBSD into FreeBSD-CURRENT. Based on the manpage, I'd suggest not. >In theory, it should be a better implementation of what atoi(3) and >strtol(3) do, but as tg@(mirbsd.org) pointed out to the OpenBSD fellows >and myself, it doesn't take hexadecimal values well... Based on the man page, I see the following deficiencies: 1) No support for bases other than 10 2) No provision to return the end of the converted string 3) No simple way to distinguish errors from a valid zero. Based on the behaviour documented in the manpage, it's just as difficult to use safely as atoi() or strtol(). The example given in the man page relies on behaviour which is not documented in the man page - namely that errstr is set to NULL on a successful conversion. If this behaviour was documented then that would remove the third point above and make it useful as a replacement for atoi() in some cases. -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 21:12:43 2005 Return-Path: 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 E664D16A4CE for ; Tue, 12 Apr 2005 21:12:43 +0000 (GMT) Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F7D143D49 for ; Tue, 12 Apr 2005 21:12:43 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: from sentinel (195.198.193.104) by pne-smtpout2-sn2.hy.skanova.net (7.1.026.7) id 41E3223E00B603F9 for freebsd-current@freebsd.org; Tue, 12 Apr 2005 23:12:42 +0200 From: "Daniel Eriksson" To: "'FreeBSD Current'" Date: Tue, 12 Apr 2005 23:13:09 +0200 Organization: Home Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcU/pG254VxRTrrETTuhb5uzDE3itA== Subject: task queue: supervisor write, page not present X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 12 Apr 2005 21:12:44 -0000 This is the third time in 4 days that I get the following crash on one of my servers. It's a dual AthlonMP machine, and at the time of the crash it wasn't doing much at all (running a few instances of a proprietary video server app). There's a dmesg at the bottom too. The log below is from a system running CURRENT from earlier today (2005.04.12.06.30.00). The other two crashes happened using sources dated 2005.04.08.04.00.00. /Daniel Eriksson Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 01 fault virtual address = 0xc2b760b4 fault code = supervisor write, page not present instruction pointer = 0x8:0xc0578f53 stack pointer = 0x10:0xe09e7ca4 frame pointer = 0x10:0xe09e7ccc code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 40 (swi6: task queue) [thread pid 40 tid 100036 ] Stopped at taskqueue_run+0x123: andl $-0x2,0x14(%ebx) db> where Tracing pid 40 tid 100036 td 0xc1eccd80 taskqueue_run(c1f3c180,e09e7d14,c053a678,0,0) at taskqueue_run+0x123 taskqueue_swi_run(0,0,0,0,0) at taskqueue_swi_run+0x13 ithread_loop(c1ed9180,e09e7d48,0,0,0) at ithread_loop+0x1a8 fork_exit(c053a4d0,c1ed9180,e09e7d48) at fork_exit+0x80 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe09e7d7c, ebp = 0 --- db> ps pid proc uid ppid pgrp flag stat wmesg wchan cmd 11120 c25bb7f0 0 612 11120 0004100 [CPU 1] mcvidserv 10639 c28c09ec 0 612 10639 0004100 [SLPQ biord 0xd17c6b30][SLP] mcvidserv 10532 c3e9a1fc 0 612 10532 0004100 [SLPQ sbwait 0xc2456cb4][SLP] mcvidserv 7902 c250e5f4 0 612 7902 0004100 [SLPQ sbwait 0xc2284cb4][SLP] mcvidserv 1725 c2814be8 0 612 1725 0004100 [SLPQ nanslp 0xc07930ac][SLP] mcvidserv 3372 c28bd9ec 0 533 533 0000101 [SLPQ select 0xc0799c04][SLP] smbd 860 c25b57f0 0 850 860 0004002 [SLPQ nanslp 0xc07930ac][SLP] mfk 850 c2814de4 0 849 850 0004002 [SLPQ pause 0xc2814e18][SLP] csh 849 c25b59ec 0 1 849 0000000 [SLPQ select 0xc0799c04][SLP] screen 771 c28c03f8 1001 1 771 0000002 [SLPQ select 0xc0799c04][SLP] ctrail 720 c28145f4 0 1 720 0000000 [SLPQ ggwait 0xc27b6000][SLP] ggatec 714 c212b1fc 0 1 714 0000000 [SLPQ ggwait 0xc27ac000][SLP] ggatec 705 c218c9ec 0 1 705 0000000 [SLPQ ggwait 0xc27b5000][SLP] ggatec 696 c25bb000 0 1 696 0000000 [SLPQ ggwait 0xc2773000][SLP] ggatec 685 c25b53f8 0 1 685 0000000 [SLPQ ggwait 0xc215c000][SLP] ggatec 678 c25b5de4 0 1 678 0000000 [SLPQ ggwait 0xc2506000][SLP] ggatec 635 c25b5be8 0 0 0 0000204 [SLPQ - 0xc1f47000][SLP] g_bde da0s1g.bde 627 c250e9ec 0 0 0 0000204 [SLPQ - 0xc218e000][SLP] gv_v 480GB 626 c25bb1fc 0 0 0 0000204 [SLPQ - 0xc1f88a00][SLP] gv_p 480GB.p0 625 c25bb3f8 0 0 0 0000204 [SLPQ - 0xc25b9c00][SLP] gv_d vd2 624 c25bb5f4 0 0 0 0000204 [SLPQ - 0xc218ee00][SLP] gv_d vd3 623 c250f3f8 0 0 0 0000204 [SLPQ - 0xc21bab00][SLP] gv_d vd0 622 c250e7f0 0 0 0 0000204 [SLPQ - 0xc2513600][SLP] gv_d vd1 621 c212ade4 0 1 621 0004002 [SLPQ ttyin 0xc1fcfc10][SLP] getty 620 c218c3f8 0 1 620 0004002 [SLPQ ttyin 0xc1fd7410][SLP] getty 619 c212abe8 0 1 619 0004002 [SLPQ ttyin 0xc1fa3c10][SLP] getty 618 c250f1fc 0 1 618 0004002 [SLPQ ttyin 0xc1fd7010][SLP] getty 617 c212a9ec 0 1 617 0004002 [SLPQ ttyin 0xc1fd6810][SLP] getty 612 c218c7f0 0 1 612 0000000 [SLPQ select 0xc0799c04][SLP] inetd 572 c250e1fc 0 1 571 0000000 [SLPQ select 0xc0799c04][SLP] snmpd 564 c250ebe8 0 1 563 0000000 [SLPQ nanslp 0xc07930ac][SLP] smartd 560 c21899ec 0 559 560 0004002 [SLPQ ttyin 0xc20f0010][SLP] csh 559 c250f000 1001 546 559 0004102 [SLPQ wait 0xc250f000][SLP] su 546 c2189de4 1001 545 546 0004002 [SLPQ pause 0xc2189e18][SLP] csh 545 c212b9ec 1001 542 542 0000100 [SLPQ select 0xc0799c04][SLP] sshd 542 c1fdbde4 0 470 542 0004100 [SLPQ sbwait 0xc2490718][SLP] sshd 541 c212b3f8 0 533 533 0000101 [SLPQ pause 0xc212b42c][SLP] smbd 533 c21893f8 0 1 533 0000101 [SLPQ select 0xc0799c04][SLP] smbd 529 c21891fc 0 1 529 0000001 [SLPQ select 0xc0799c04][SLP] nmbd 509 c21897f0 65534 1 509 0000100 [SLPQ select 0xc0799c04][SLP] identd 496 c218c1fc 0 1 496 0000000 [SLPQ nanslp 0xc07930ac][SLP] cron 480 c212bde4 25 1 480 0000100 [SLPQ pause 0xc212be18][SLP] sendmail 476 c212a1fc 0 1 476 0000100 [SLPQ select 0xc0799c04][SLP] sendmail 470 c212a5f4 0 1 470 0000100 [SLPQ select 0xc0799c04][SLP] sshd 451 c21895f4 0 1 451 0000000 [SLPQ select 0xc0799c04][SLP] ntpd 344 c218c000 0 1 344 0000000 [SLPQ select 0xc0799c04][SLP] syslogd 315 c212a7f0 0 1 315 0000000 [SLPQ select 0xc0799c04][SLP] devd 171 c212a3f8 0 1 171 0000000 [SLPQ pause 0xc212a42c][SLP] adjkerntz 56 c212b7f0 0 0 0 0000204 [SLPQ - 0xe46a4d0c][SLP] schedcpu 55 c1ecd3f8 0 0 0 0000204 [SLPQ - 0xc079d52c][SLP] nfsiod 3 54 c1ecd5f4 0 0 0 0000204 [SLPQ - 0xc079d528][SLP] nfsiod 2 53 c1ecd7f0 0 0 0 0000204 [SLPQ - 0xc079d524][SLP] nfsiod 1 52 c1ecd9ec 0 0 0 0000204 [SLPQ - 0xc079d520][SLP] nfsiod 0 51 c1ecdbe8 0 0 0 0000204 [SLPQ vlruwt 0xc1ecdbe8][SLP] vnlru 50 c1ecdde4 0 0 0 0000204 [SLPQ syncer 0xc0792e0c][SLP] syncer 49 c1fdb000 0 0 0 0000204 [SLPQ psleep 0xc079a170][SLP] bufdaemon 48 c1fdb1fc 0 0 0 0000204 [SLPQ pollid 0xc0792464][SLP] idlepoll 47 c1fdb3f8 0 0 0 000020c [SLPQ pgzero 0xc07a3c24][SLP] pagezero 46 c1fdb5f4 0 0 0 0000204 [SLPQ psleep 0xc07a3774][SLP] vmdaemon 45 c1fdb7f0 0 0 0 0000204 [SLPQ psleep 0xc07a3730][SLP] pagedaemon 9 c1fdb9ec 0 0 0 0000204 [SLPQ - 0xc1fb843c][SLP] fdc0 44 c1fdbbe8 0 0 0 0000204 [IWAIT] swi0: sio 8 c1ec0be8 0 0 0 0000204 [SLPQ idle 0xc1f6dc74][SLP] ciss_notify0 7 c1ec0de4 0 0 0 0000204 [SLPQ actask 0xc08a0f2c][SLP] acpi_task0 43 c1ecb000 0 0 0 0000204 [IWAIT] swi5:+ 42 c1ecb1fc 0 0 0 0000204 [IWAIT] swi6: acpitaskq 6 c1ecb3f8 0 0 0 0000204 [SLPQ - 0xc1f3c080][SLP] thread taskq 41 c1ecb5f4 0 0 0 0000204 [IWAIT] swi6:+ 40 c1ecb7f0 0 0 0 0000204 [CPU 0] swi6: task queue 5 c1ecb9ec 0 0 0 0000204 [SLPQ - 0xc1f3c1c0][SLP] kqueue taskq 39 c1ecbbe8 0 0 0 0000204 [IWAIT] swi2: cambio 38 c1ecbde4 0 0 0 0000204 [SLPQ - 0xc078bdc0][SLP] yarrow 4 c1ecd000 0 0 0 0000204 [SLPQ - 0xc0790228][SLP] g_down 3 c1ecd1fc 0 0 0 0000204 [SLPQ - 0xc0790224][SLP] g_up 2 c1eb05f4 0 0 0 0000204 [SLPQ - 0xc079021c][SLP] g_event 37 c1eb07f0 0 0 0 0000204 [RUNQ] swi1: net 36 c1eb09ec 0 0 0 0000204 [IWAIT] swi3: vm 35 c1eb0be8 0 0 0 000020c [RUNQ] swi4: clock sio 34 c1eb0de4 0 0 0 0000204 [IWAIT] irq23: 33 c1ec0000 0 0 0 0000204 [IWAIT] irq22: em1 32 c1ec01fc 0 0 0 0000204 [IWAIT] irq21: em0 31 c1ec03f8 0 0 0 0000204 [IWAIT] irq20: ciss0 30 c1ec05f4 0 0 0 0000204 [IWAIT] irq19: atapci3+ 29 c1ec07f0 0 0 0 0000204 [IWAIT] irq18: 28 c1ec09ec 0 0 0 0000204 [LOCK taskqueue c1e01140] irq17: atapci1+ 27 c1e0b1fc 0 0 0 0000204 [IWAIT] irq16: 26 c1e0b3f8 0 0 0 0000204 [IWAIT] irq15: ata1 25 c1e0b5f4 0 0 0 0000204 [IWAIT] irq14: ata0 24 c1e0b7f0 0 0 0 0000204 [IWAIT] irq13: 23 c1e0b9ec 0 0 0 0000204 [IWAIT] irq12: 22 c1e0bbe8 0 0 0 0000204 [IWAIT] irq11: 21 c1e0bde4 0 0 0 0000204 [IWAIT] irq10: 20 c1eb0000 0 0 0 0000204 [IWAIT] irq9: acpi0 19 c1eb01fc 0 0 0 0000204 [IWAIT] irq8: 18 c1eb03f8 0 0 0 0000204 [IWAIT] irq7: 17 c1e06000 0 0 0 0000204 [IWAIT] irq6: fdc0 16 c1e061fc 0 0 0 0000204 [IWAIT] irq5: 15 c1e063f8 0 0 0 0000204 [IWAIT] irq4: sio0 14 c1e065f4 0 0 0 0000204 [IWAIT] irq3: 13 c1e067f0 0 0 0 0000204 [IWAIT] irq0: 12 c1e069ec 0 0 0 0000204 [IWAIT] irq1: atkbd0 11 c1e06be8 0 0 0 000020c [Can run] idle: cpu0 10 c1e06de4 0 0 0 000020c [Can run] idle: cpu1 1 c1e0b000 0 0 1 0004200 [SLPQ wait 0xc1e0b000][SLP] init 0 c0790320 0 0 0 0000200 [SLPQ sched 0xc0790320][SLP] swapper And here's part of the dmesg: /boot/kernel/kernel text=0x3528bc data=0x36388+0x33c38 syms=[0x4+0x42940+0x4+0x537ec] /boot/kernel/acpi.ko text=0x49fa0 data=0x2124+0x110c syms=[0x4+0x7730+0x4+0x9ec3] KDB: debugger backends: ddb KDB: current backend: ddb 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-CURRENT #0: Tue Apr 12 10:23:40 CEST 2005 daniel@xxx:/usr/obj/usr/src/sys/XXX Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) MP 2600+ (2000.08-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x6a0 Stepping = 0 Features=0x383fbff AMD Features=0xc0480000 real memory = 804782080 (767 MB) avail memory = 778342400 (742 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 1 cpu1 (AP): APIC ID: 0 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-23 on motherboard npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff,0x8000-0x807f,0x8080-0x80ff iomem 0xd8000-0xdbfff on acpi0 pci0: on pcib0 agp0: port 0x1490-0x1493 mem 0xec000000-0xedffffff,0xea100000-0xea100fff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 5.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 7.1 on pci0 ata0: on atapci0 ata1: on atapci0 pci0: at device 7.3 (no driver attached) ciss0: port 0x1000-0x10ff mem 0xe8100000-0xe813ffff,0xe8000000-0xe80fffff irq 20 at device 8.0 on pci0 ciss0: [GIANT-LOCKED] em0: port 0x1400-0x143f mem 0xe81c0000-0xe81dffff,0xe8140000-0xe817ffff irq 21 at device 9.0 on pci0 em0: Ethernet address: 00:04:23:ac:20:8a em0: Speed:N/A Duplex:N/A em1: port 0x1440-0x147f mem 0xe81e0000-0xe81fffff,0xe8180000-0xe81bffff irq 22 at device 9.1 on pci0 em1: Ethernet address: 00:04:23:ac:20:8b em1: Speed:N/A Duplex:N/A pcib2: at device 16.0 on pci0 pci2: on pcib2 atapci1: port 0x3010-0x3017,0x3004-0x3007,0x3008-0x300f,0x3000-0x3003,0x2000-0x20ff irq 17 at device 5.0 on pci2 ata2: on atapci1 ata3: on atapci1 atapci2: port 0x3028-0x302f,0x301c-0x301f,0x3020-0x3027,0x3018-0x301b,0x2400-0x24ff irq 17 at device 5.1 on pci2 ata4: on atapci2 ata5: on atapci2 atapci3: port 0x3040-0x3047,0x3034-0x3037,0x3038-0x303f,0x3030-0x3033,0x2800-0x28ff irq 19 at device 7.0 on pci2 ata6: on atapci3 ata7: on atapci3 atapci4: port 0x3058-0x305f,0x304c-0x304f,0x3050-0x3057,0x3048-0x304b,0x2c00-0x2cff irq 19 at device 7.1 on pci2 ata8: on atapci4 ata9: on atapci4 pci_link0: irq 5 on acpi0 pci_link1: irq 3 on acpi0 pci_link2: irq 11 on acpi0 pci_link3: irq 10 on acpi0 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 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcafff,0xcb000-0xcefff,0xe0000-0xe3fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled Timecounters tick every 1.000 msec ipfw2 initialized, divert loadable, rule-based forwarding disabled, default to accept, logging unlimited ad0: 117800MB at ata0-master UDMA100 ad1: 117800MB at ata0-slave UDMA100 ad2: 117800MB at ata1-master UDMA100 ad3: 117800MB at ata1-slave UDMA100 ad4: 238475MB at ata2-master UDMA100 ad5: 238475MB at ata2-slave UDMA100 ad6: 239372MB at ata3-master UDMA133 ad7: 239372MB at ata3-slave UDMA133 ad8: 194481MB at ata4-master UDMA133 ad9: 194481MB at ata4-slave UDMA133 ad10: 239372MB at ata5-master UDMA133 ad12: 114473MB at ata6-master UDMA100 ad13: 114473MB at ata6-slave UDMA100 ad14: 117246MB at ata7-master UDMA133 ad15: 117246MB at ata7-slave UDMA133 ad16: 114473MB at ata8-master UDMA100 ad17: 117800MB at ata8-slave UDMA100 ad18: 194481MB at ata9-master UDMA133 ad19: 239372MB at ata9-slave UDMA133 da0 at ciss0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-0 device da0: 135.168MB/s transfers da0: 105008MB (215056800 512 byte sectors: 255H 32S/T 26355C) da1 at ciss0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-0 device da1: 135.168MB/s transfers da1: 486240MB (995821155 512 byte sectors: 255H 63S/T 61987C) ATA PseudoRAID loaded ar0: 476950MB status: READY ar0: disk0 READY using ad4 at ata2-master ar0: disk1 READY using ad5 at ata2-slave ar1: 478744MB status: READY ar1: disk0 READY using ad6 at ata3-master ar1: disk1 READY using ad7 at ata3-slave ar2: 583442MB status: READY ar2: disk0 READY using ad8 at ata4-master ar2: disk1 READY using ad9 at ata4-slave ar2: disk2 READY using ad18 at ata9-master ar3: 478744MB status: READY ar3: disk0 READY using ad19 at ata9-slave ar3: disk1 READY using ad10 at ata5-master ar4: 343420MB status: READY ar4: disk0 READY using ad12 at ata6-master ar4: disk1 READY using ad13 at ata6-slave ar4: disk2 READY using ad16 at ata8-master ar5: 351740MB status: READY ar5: disk0 READY using ad14 at ata7-master ar5: disk1 READY using ad15 at ata7-slave ar5: disk2 READY using ad17 at ata8-slave SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/da0s1a Pre-seeding PRNG: kickstart. Loading configuration files. kernel dumps on /dev/da0s1b Entropy harvesting: point_to_point kickstart. swapon: adding /dev/da0s1b as swap device Starting file system checks: /dev/da0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/da0s1a: clean, 124444 free (1100 frags, 15418 blocks, 0.4% fragmentation) /dev/da0s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/da0s1e: clean, 253807 free (31 frags, 31722 blocks, 0.0% fragmentation) /dev/da0s1f: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/da0s1f: clean, 3082494 free (29310 frags, 381648 blocks, 0.6% fragmentation) /dev/da0s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/da0s1d: clean, 207823 free (975 frags, 25856 blocks, 0.4% fragmentation) /dev/da0s1h: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/da0s1h: clean, 31567485 free (557 frags, 3945866 blocks, 0.0% fragmentation) Setting hostname: xxx. net.inet.tcp.sendspace: 32768 -> 2097152 net.inet.tcp.recvspace: 65536 -> 2097152 kern.ipc.maxsockbuf: 262144 -> 16777216 kern.ipc.somaxconn: 128 -> 256 net.inet.ip.intr_queue_maxlen: 50 -> 128 kern.polling.enable: 0 -> 1 kern.polling.burst_max: 150 -> 300 kern.polling.each_burst: 5 -> 50 kern.polling.poll_in_trap: 0 -> 1 kern.polling.user_frac: 50 -> 33 vfs.hirunningspace: 1048576 -> 8388608 ... From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 21:34:28 2005 Return-Path: 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 DAEA816A4D6 for ; Tue, 12 Apr 2005 21:34:28 +0000 (GMT) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id A168F43D46 for ; Tue, 12 Apr 2005 21:34:28 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id IBA74465 for ; Tue, 12 Apr 2005 14:34:28 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 41F1F5D07 for ; Tue, 12 Apr 2005 14:34:28 -0700 (PDT) To: current@freebsd.org Date: Tue, 12 Apr 2005 14:34:28 -0700 From: "Kevin Oberman" Message-Id: <20050412213428.41F1F5D07@ptavv.es.net> Subject: Weird display problem in recent current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 12 Apr 2005 21:34:29 -0000 Since I updated my current kernel yesterday, I have been seeing a weird problem that appears to be in X. I did not have the problem with the build I did on Friday, Apr. 8. I run gkrellm, a GTK based system monitor. I also run Gnome 2.10 and X.org. All of these ports are up to date. System is a P4M IBM T30. After my new kernel was installed yesterday, gkrellm would work until the screen blanks (screensaver set to blank). When the screen is re-activated, all of the applications refresh except that one. I just have an empty grey are where gkrellm should be. top shows that gkrellm is continually in RUN state, although it is using very little CPU. The second problem is that Gnome will no longer shut down. (This may be an artifact of th problems gkrellm is having.) I have to CTRL-ALT-BS. (Ugh!) I'd look at gkrellm except that I only updated the kernel on Monday, not world, let alone the gkrellm port. I thought some user-land/kernel issue may have cropped up, so I just finished rebuilding both the kernel and world. No change in behavior. Any ideas what might have changed between Friday morning and today to cause this? I'm not even sure where to start looking. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 22:15:49 2005 Return-Path: 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 56BFE16A4CE; Tue, 12 Apr 2005 22:15:49 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.194.102.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1140443D2D; Tue, 12 Apr 2005 22:15:49 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 8B506530EE; Tue, 12 Apr 2005 15:15:47 -0700 (PDT) Date: Tue, 12 Apr 2005 15:15:47 -0700 From: Kris Kennaway To: Don Lewis Message-ID: <20050412221546.GB65915@xor.obsecurity.org> References: <425BE215.4090406@samsco.org> <200504121951.j3CJpCCY036689@gw.catspoiler.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VrqPEDrXMn8OVzN4" Content-Disposition: inline In-Reply-To: <200504121951.j3CJpCCY036689@gw.catspoiler.org> User-Agent: Mutt/1.4.2.1i cc: current@FreeBSD.org cc: kris@obsecurity.org Subject: Re: Softupdates not preventing lengthy fsck X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 12 Apr 2005 22:15:49 -0000 --VrqPEDrXMn8OVzN4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 12, 2005 at 12:51:12PM -0700, Don Lewis wrote: > On 12 Apr, Scott Long wrote: > > Kris Kennaway wrote: >=20 > >> I can take a transcript of the entire fsck next time if you like :-) > >> (it ran for more than 5 hours on the 24G drive and was still going > >> after I went to bed) > >>=20 > >> Kris > >=20 > > Don might not know that your workload involves creating and deleting > > full ports/ trees repeatedly, and those trees contain hundreds of > > tousands of inodes each. >=20 > I suspected that, especially given the inode timestamps in the partial > transcript. Actually the ports trees are not recreated (they're mounted via nullfs and accessed read-only), and the files that are created are due to building, installing and uninstalling of ports on a plain old ufs2. It's still a lot of files though. > > If there is a reference count leak and those > > deletions aren't ever being finalized, then there would be a whole lot > > of work for fsck to do =3D-) Might also explain why disks have been > > unexpectedly filling up on package machines (like mine). >=20 > Sounds likely. When the disk starts looking unexpectedly full, can you > unmount the file system or does the attempt fail with and EBUSY error? > What happens if you fsck the file system after it has been unmounted? > Are snapshots being used? Scott was the one who tried to repair the system after this happened, so he can probably answer it better. I'm certainly not using snapshots myself. Kris --VrqPEDrXMn8OVzN4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCXEiRWry0BWjoQKURAhjcAKCetahLDM7F7CzixeqfiCIv9y6XuACdHH0O v0BuzOt28SZVkeHF605xXBE= =ZiXP -----END PGP SIGNATURE----- --VrqPEDrXMn8OVzN4-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 22:43:35 2005 Return-Path: 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 C39F616A4CE; Tue, 12 Apr 2005 22:43:35 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id C241243D5A; Tue, 12 Apr 2005 22:43:32 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j3CMkmdf040732; Tue, 12 Apr 2005 16:46:48 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <425C4E55.6090304@samsco.org> Date: Tue, 12 Apr 2005 16:40:21 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kris Kennaway References: <425BE215.4090406@samsco.org> <200504121951.j3CJpCCY036689@gw.catspoiler.org> <20050412221546.GB65915@xor.obsecurity.org> In-Reply-To: <20050412221546.GB65915@xor.obsecurity.org> 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: Don Lewis cc: current@FreeBSD.org Subject: Re: Softupdates not preventing lengthy fsck X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 12 Apr 2005 22:43:35 -0000 Kris Kennaway wrote: > On Tue, Apr 12, 2005 at 12:51:12PM -0700, Don Lewis wrote: > >>On 12 Apr, Scott Long wrote: >> >>>Kris Kennaway wrote: >> >>>>I can take a transcript of the entire fsck next time if you like :-) >>>>(it ran for more than 5 hours on the 24G drive and was still going >>>>after I went to bed) >>>> >>>>Kris >>> >>>Don might not know that your workload involves creating and deleting >>>full ports/ trees repeatedly, and those trees contain hundreds of >>>tousands of inodes each. >> >>I suspected that, especially given the inode timestamps in the partial >>transcript. > > > Actually the ports trees are not recreated (they're mounted via nullfs > and accessed read-only), and the files that are created are due to > building, installing and uninstalling of ports on a plain old ufs2. > It's still a lot of files though. > Sorry, from the files that I tried to repair on my system it looked like there was a ports tree removal involved. > >>>If there is a reference count leak and those >>>deletions aren't ever being finalized, then there would be a whole lot >>>of work for fsck to do =-) Might also explain why disks have been >>>unexpectedly filling up on package machines (like mine). >> >>Sounds likely. When the disk starts looking unexpectedly full, can you >>unmount the file system or does the attempt fail with and EBUSY error? >>What happens if you fsck the file system after it has been unmounted? >>Are snapshots being used? > > > Scott was the one who tried to repair the system after this happened, > so he can probably answer it better. I'm certainly not using > snapshots myself. > > Kris > I gave up after lost+found filled up (literally) with directory inodes that couldn't be removed. Using clri on them only made fsck more upset. That filesystem is still hanging around on a disk that is powered down now, bit I'd be happy to ship it to someone for a post-mortem if desired. It's a SCSI disk, though. Scott From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 02:05:34 2005 Return-Path: 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 3367E16A4CE; Wed, 13 Apr 2005 02:05:34 +0000 (GMT) Received: from avscan1.sentex.ca (avscan1.sentex.ca [199.212.134.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id C230943D1D; Wed, 13 Apr 2005 02:05:33 +0000 (GMT) (envelope-from mike@sentex.net) Received: from localhost (localhost.sentex.ca [127.0.0.1]) by avscan1.sentex.ca (8.12.11/8.12.11) with ESMTP id j3D25Weo054414; Tue, 12 Apr 2005 22:05:32 -0400 (EDT) (envelope-from mike@sentex.net) Received: from avscan1.sentex.ca ([127.0.0.1]) by localhost (avscan1.sentex.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 53601-09; Tue, 12 Apr 2005 22:05:32 -0400 (EDT) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by avscan1.sentex.ca (8.12.11/8.12.11) with ESMTP id j3D25WJD054372; Tue, 12 Apr 2005 22:05:32 -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.12.11) with ESMTP id j3D25Qep022989; Tue, 12 Apr 2005 22:05:26 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.2.1.2.0.20050412220212.055c5d48@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 12 Apr 2005 22:04:46 -0400 To: freebsd-current@freebsd.org From: Mike Tancsa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at avscan1b Subject: ichwd fixes / patches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 02:05:34 -0000 Any chance someone could champion / commit the fixes in http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/79698 and perhaps MFC ? Its non functional right now and the patches provided there make it work once again. ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 03:05:52 2005 Return-Path: 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 80CCA16A4CE for ; Wed, 13 Apr 2005 03:05:52 +0000 (GMT) Received: from sp.dominia.org (efnet-math.org [69.60.109.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C65543D55 for ; Wed, 13 Apr 2005 03:05:52 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from [192.168.1.12] (63-170-138-118.cst-sg.blacksburg.ntc-com.net [63.170.138.118]) (authenticated bits=0) by sp.dominia.org (8.13.1/8.13.1) with ESMTP id j3D35o7q005164 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Tue, 12 Apr 2005 23:05:51 -0400 Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: <0842a01b5aa0cfcd84763fff4a30113e@FreeBSD.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: current@FreeBSD.org From: Suleiman Souhlal Date: Tue, 12 Apr 2005 23:05:45 -0400 X-Mailer: Apple Mail (2.619.2) Subject: [PATCH] Allow watching of vnodes that reside on non-UFS filesystems with kqueue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 03:05:52 -0000 Hello, The patch at http://people.freebsd.org/~ssouhlal/testing/kqueue-hooks-20050412.diff allows watching vnodes on non-UFS filesystems with kqueue. It moves the VN_KNOTE calls to pre and post VOP_* hooks. These hooks are currently used for VFS lock debugging only, but I made them unconditional. I think that they we could eventually move the mac_check_vnode_* calls into them too, with a bit of work. I would like to commit this to HEAD, if there are no objections. Bye, -- Suleiman Souhlal | ssouhlal@vt.edu The FreeBSD Project | ssouhlal@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 03:08:27 2005 Return-Path: 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 AF54816A4CE for ; Wed, 13 Apr 2005 03:08:27 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FEE043D1D for ; Wed, 13 Apr 2005 03:08:27 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.3/8.13.1) with ESMTP id j3D38FHO021429; Tue, 12 Apr 2005 23:08:15 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.3/8.13.1/Submit) id j3D38FAN021428; Tue, 12 Apr 2005 23:08:15 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Tue, 12 Apr 2005 23:08:15 -0400 From: David Schultz To: Peter Jeremy Message-ID: <20050413030814.GA21318@VARK.MIT.EDU> Mail-Followup-To: Peter Jeremy , "R. Tyler Ballance" , FreeBSD Current References: <1113332762.27362.29.camel@localhost.localdomain> <20050412195700.GN89047@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050412195700.GN89047@cirb503493.alcatel.com.au> cc: "R. Tyler Ballance" cc: FreeBSD Current Subject: Re: strtonum(3) in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 03:08:27 -0000 On Wed, Apr 13, 2005, Peter Jeremy wrote: > On Tue, 2005-Apr-12 14:06:02 -0500, R. Tyler Ballance wrote: > >Quick, sort of, question. Is it worth it to bring strtonum(3) from > >OpenBSD into FreeBSD-CURRENT. > > Based on the manpage, I'd suggest not. > > >In theory, it should be a better implementation of what atoi(3) and > >strtol(3) do, but as tg@(mirbsd.org) pointed out to the OpenBSD fellows > >and myself, it doesn't take hexadecimal values well... > > Based on the man page, I see the following deficiencies: > 1) No support for bases other than 10 > 2) No provision to return the end of the converted string > 3) No simple way to distinguish errors from a valid zero. It actually has a sensible way of distinguishing errors (it always sets errno, even if to 0), but this is unintuitive to anyone who is used to the broken POSIX way of doing it. It's a nice attempt, but consistency is important, too. So unless we really need it, I would vote against it as well. From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 03:26:32 2005 Return-Path: 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 8D33116A52C for ; Wed, 13 Apr 2005 03:26:32 +0000 (GMT) Received: from web54006.mail.yahoo.com (web54006.mail.yahoo.com [206.190.36.230]) by mx1.FreeBSD.org (Postfix) with SMTP id ED15B43D53 for ; Wed, 13 Apr 2005 03:26:31 +0000 (GMT) (envelope-from spamrefuse@yahoo.com) Received: (qmail 53071 invoked by uid 60001); 13 Apr 2005 03:26:31 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=NJDf46P1euxPqFC8M3u4R8qCfBjJaoUVxFXTWUSTfaabl0U8xjiTdjazyfc6elJD3tNWFTK2+wZ1Gn8xu+JiFovEpoTAx/kIKSbI1LI1sPkWQ9kPEIC/cF1J2y3gzUKCrYascrVozqCwQaZsIRfl4SSPArznWzD63dlma3VaQ4o= ; Message-ID: <20050413032631.53069.qmail@web54006.mail.yahoo.com> Received: from [147.46.44.181] by web54006.mail.yahoo.com via HTTP; Tue, 12 Apr 2005 20:26:31 PDT Date: Tue, 12 Apr 2005 20:26:31 -0700 (PDT) From: Rob To: Ruslan Ermilov In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: FreeBSD current Subject: Re: xl(4) & polling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 03:26:32 -0000 --- Ruslan Ermilov wrote: >> On Sun, Apr 10, 2005 at 09:16:44PM -0700, Rob wrote: > >>>> >>>> Will it also go into RELENG_5, after the 5.4 >>>> release? > >> >> Yes, probably. After I hear more reports of >> success. >> The HEAD sources can be used on RELENG_5 to test >> the functionality. While you're at it: Since applying your patch I have been watching carefully the network traffic over my xl LAN cards. So far so good; however, I noticed today following lines in my dmesg.today file: xl1: transmission error: 90 xl1: tx underrun, increasing tx start threshold to 120 bytes These lines are only in that file, nowhere else. They may also have been generated before I applied your patch, but then I was not yet monitoring the xl cards. From googling, I learn that I can safely ignore these messages. If you apply the polling changes to xl driver, then please also add a few lines to the DIAGNOSTICS section of the xl-manpage to describe above messages. For example, dc(4) has an entry on the 'TX underrun' in its DIAGNOSTICS section. Regards, Rob. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 05:31:30 2005 Return-Path: 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 93D8116A4CE for ; Wed, 13 Apr 2005 05:31:30 +0000 (GMT) Received: from anduin.net (anduin.net [212.12.46.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F48443D2D for ; Wed, 13 Apr 2005 05:31:30 +0000 (GMT) (envelope-from ltning@anduin.net) Received: from ranger.anduin.net ([81.0.162.52] helo=[192.168.1.10]) by anduin.net with esmtpa (Exim 4.50 (FreeBSD)) id 1DLaTF-0000EX-GL for current@freebsd.org; Wed, 13 Apr 2005 07:31:26 +0200 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Wed, 13 Apr 2005 07:28:01 +0200 From: Eirik =?ISO-8859-1?B?2A==?=verby To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Mysterious hangs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 05:31:30 -0000 Hi, For some time I've been seeing infrequent and seemingly random hangs on my dual opteron system. Motherboard is Tyan K8S Pro. Until now I thought it was a "hard" hang, but I've got serial console hooked up and BREAK_TO_DEBUGGER, DDB and KDB in the kernel, and when sending a break through telnet I get: telnet> send brk KDB: enter: Line break on console And nothing more. Which means the box is sort of alive, but fails to present even the kernel debugger. The machine is currently on 5.4 as of yesterday. It's been hanging before (with anything from days to weeks between), under various variations of 5.x, but I haven't had the serial console before now. Has any one seen this before? Any ideas what I could look at? I suspected hardware, but it seems that isn't the case as most HW errors I've seen would cause a total freeze. Here's to hoping. Thanks, /Eirik From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 05:32:56 2005 Return-Path: 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 6A08C16A4CE for ; Wed, 13 Apr 2005 05:32:56 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF9E443D45 for ; Wed, 13 Apr 2005 05:32:55 +0000 (GMT) (envelope-from leafy7382@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so64944rng for ; Tue, 12 Apr 2005 22:32: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:mime-version:content-type:content-transfer-encoding:content-disposition; b=UxYsdWAnOTq66s6A3EVe4As5sApZFpwlvXGul86NlrXrJftBW/sOdfdtgOT48MKyhRGj9TEMJQZxBXoCcbTXIqvZGdReUQxgL59DoALvIFBQYhwzgzSAprRHfFx0fuTJI1K7q+5Ohts0izW8ws9ZNpQxTayeZT4u70spT2K1jec= Received: by 10.38.74.31 with SMTP id w31mr266018rna; Tue, 12 Apr 2005 22:32:55 -0700 (PDT) Received: by 10.38.22.48 with HTTP; Tue, 12 Apr 2005 22:32:55 -0700 (PDT) Message-ID: Date: Wed, 13 Apr 2005 13:32:55 +0800 From: Jiawei Ye To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: How does one know how many thread a process owns? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Jiawei Ye List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 05:32:56 -0000 >From top in pkgsrc, one can know that a certain process has some number of LWP in it. load averages: 1.89, 1.72, 1.68; up 119+05:28:10 13:3= 0:48 154 processes: 152 sleeping, 1 running, 1 on cpu CPU states: % idle, % user, % kernel, % iowait, % swap Memory: 1024M real, 414M free, 841M swap in use, 1956M swap free PID USERNAME LWP PRI NICE SIZE RES STATE TIME CPU COMMAND 21891 bond 1 4 2 19M 1864K run 31.7H 77.04% upd_twd_15min 17153 bond 1 50 2 82M 6164K sleep 37:37 12.98% dataserver.ts= k 17151 bond 1 53 2 82M 81M sleep 41:57 0.96% dataserver.ts= k 13742 otc 1 53 2 30M 21M sleep 3:31 0.89% dataserver.ts= k 17204 mtrs 1 53 2 82M 6144K sleep 2:47 0.67% dataserver.ts= k 17321 mtrs 1 53 2 25M 7908K sleep 2:21 0.49% otcmgr.tsk 16250 root 1 59 0 4136K 2224K sleep 0:00 0.47% sshd 13745 otc 1 53 2 30M 2496K sleep 2:55 0.36% dataserver.ts= k 3821 jessica 1 59 0 31M 4816K sleep 6:25 0.34% dataserver.ts= k 17227 bond 1 53 2 25M 7908K sleep 2:46 0.31% otcmgr.tsk 17553 otc 1 53 2 17M 1208K sleep 0:46 0.18% icbc_pricing 16269 leafy 1 45 0 3360K 1688K sleep 0:00 0.13% bash 17202 mtrs 1 53 2 82M 19M sleep 1:08 0.12% dataserver.ts= k 17154 bond 1 53 2 82M 8004K sleep 0:35 0.12% dataserver.ts= k 13746 otc 1 53 2 30M 5136K sleep 0:37 0.11% dataserver.ts= k In our top, show threads does not tell you how many threads exactly exists in a process, is there any way to imitate the other top's behaviour? Jiawei --=20 "Without the userland, the kernel is useless." --inspired by The Tao of Programming From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 05:40:23 2005 Return-Path: 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 4010A16A4CE for ; Wed, 13 Apr 2005 05:40:23 +0000 (GMT) Received: from mail26.sea5.speakeasy.net (mail26.sea5.speakeasy.net [69.17.117.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id B900C43D49 for ; Wed, 13 Apr 2005 05:40:22 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 16298 invoked from network); 13 Apr 2005 05:40:22 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail26.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 13 Apr 2005 05:40:22 -0000 Received: from hydrogen.funkthat.com (cdsdyb@localhost.funkthat.com [127.0.0.1])j3D5eKGH002606; Tue, 12 Apr 2005 22:40:21 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id j3D5eK6K002605; Tue, 12 Apr 2005 22:40:20 -0700 (PDT) Date: Tue, 12 Apr 2005 22:40:20 -0700 From: John-Mark Gurney To: Suleiman Souhlal Message-ID: <20050413054020.GL56487@funkthat.com> Mail-Followup-To: Suleiman Souhlal , current@FreeBSD.org References: <0842a01b5aa0cfcd84763fff4a30113e@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0842a01b5aa0cfcd84763fff4a30113e@FreeBSD.org> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: current@FreeBSD.org Subject: Re: [PATCH] Allow watching of vnodes that reside on non-UFS filesystems with kqueue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 05:40:23 -0000 Suleiman Souhlal wrote this message on Tue, Apr 12, 2005 at 23:05 -0400: > Hello, > > The patch at > http://people.freebsd.org/~ssouhlal/testing/kqueue-hooks-20050412.diff > allows watching vnodes on non-UFS filesystems with kqueue. > > It moves the VN_KNOTE calls to pre and post VOP_* hooks. These hooks > are currently used for VFS lock debugging only, but I made them > unconditional. I think that they we could eventually move the > mac_check_vnode_* calls into them too, with a bit of work. > > I would like to commit this to HEAD, if there are no objections. I would prefer to move the vfs_kqfilter and filt_vfs* functions either be moved to a vfs specific file, or be moved to their own file.. also, it appears that we lost support for extending of files... though I can't confirm that... Have you verified that extending still gets notified? Other wise looks good... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 06:05:07 2005 Return-Path: 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 DECEF16A4CF for ; Wed, 13 Apr 2005 06:05:07 +0000 (GMT) Received: from mail28.sea5.speakeasy.net (mail28.sea5.speakeasy.net [69.17.117.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BB3243D2D for ; Wed, 13 Apr 2005 06:05:07 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 4354 invoked from network); 13 Apr 2005 06:05:07 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail28.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 13 Apr 2005 06:05:07 -0000 Received: from hydrogen.funkthat.com (xydilc@localhost.funkthat.com [127.0.0.1])j3D655GH003212; Tue, 12 Apr 2005 23:05:06 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id j3D655OE003211; Tue, 12 Apr 2005 23:05:05 -0700 (PDT) Date: Tue, 12 Apr 2005 23:05:05 -0700 From: John-Mark Gurney To: Suleiman Souhlal , current@FreeBSD.org Message-ID: <20050413060505.GM56487@funkthat.com> Mail-Followup-To: Suleiman Souhlal , current@FreeBSD.org References: <0842a01b5aa0cfcd84763fff4a30113e@FreeBSD.org> <20050413054020.GL56487@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050413054020.GL56487@funkthat.com> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Subject: Re: [PATCH] Allow watching of vnodes that reside on non-UFS filesystems with kqueue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 06:05:08 -0000 John-Mark Gurney wrote this message on Tue, Apr 12, 2005 at 22:40 -0700: > Suleiman Souhlal wrote this message on Tue, Apr 12, 2005 at 23:05 -0400: > > The patch at > > http://people.freebsd.org/~ssouhlal/testing/kqueue-hooks-20050412.diff > > allows watching vnodes on non-UFS filesystems with kqueue. > > > > It moves the VN_KNOTE calls to pre and post VOP_* hooks. These hooks > > are currently used for VFS lock debugging only, but I made them > > unconditional. I think that they we could eventually move the > > mac_check_vnode_* calls into them too, with a bit of work. > > > > I would like to commit this to HEAD, if there are no objections. > > I would prefer to move the vfs_kqfilter and filt_vfs* functions either > be moved to a vfs specific file, or be moved to their own file.. also, > it appears that we lost support for extending of files... though I can't > confirm that... Have you verified that extending still gets notified? > > Other wise looks good... Just to clarify, I'm only ok'ing the kqueue changes (as long as the concers above are cleared).. I don't have enough VFS experience to say how the VFS changes will effect things.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 06:08:26 2005 Return-Path: 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 22A7816A4CE; Wed, 13 Apr 2005 06:08:26 +0000 (GMT) Received: from hex.athame.co.uk (guru164.netsonic.fi [194.29.193.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8AE7243D1F; Wed, 13 Apr 2005 06:08:25 +0000 (GMT) (envelope-from andy@athame.co.uk) Received: from hex.int.athame.co.uk ([192.168.1.1] helo=localhost) by hex.athame.co.uk with esmtp (Exim 4.50 (FreeBSD)) id 1DLb32-000JNM-0h; Wed, 13 Apr 2005 09:08:24 +0300 From: Andy Fawcett To: freebsd-current@freebsd.org Date: Wed, 13 Apr 2005 09:08:18 +0300 User-Agent: KMail/1.8 References: <20050413032631.53069.qmail@web54006.mail.yahoo.com> In-Reply-To: <20050413032631.53069.qmail@web54006.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504130908.20519.andy@athame.co.uk> cc: Rob Subject: Re: xl(4) & polling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 06:08:26 -0000 On Wednesday 13 April 2005 06:26, Rob wrote: > --- Ruslan Ermilov wrote: > >> On Sun, Apr 10, 2005 at 09:16:44PM -0700, Rob > > wrote: > >>>> Will it also go into RELENG_5, after the 5.4 > >>>> release? > >> > >> Yes, probably. After I hear more reports of > >> success. > >> The HEAD sources can be used on RELENG_5 to test > >> the functionality. > > While you're at it: > > Since applying your patch I have been watching > carefully the network traffic over my xl LAN cards. > > So far so good; however, I noticed today following > lines in my dmesg.today file: > > xl1: transmission error: 90 > xl1: tx underrun, increasing tx start threshold > to 120 bytes FWIW, I see these on my firewall box with a pair of xl cards, even without the polling patch. They've been showing up on and off since about 5.3-RELEASE, and usually only during the first day after a reboot. A. From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 06:33:21 2005 Return-Path: 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 DC19016A4CE; Wed, 13 Apr 2005 06:33:20 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45D0E43D5F; Wed, 13 Apr 2005 06:33:20 +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 j3D6XJqT013734; Wed, 13 Apr 2005 02:33:19 -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 j3D6XSNd078838; Wed, 13 Apr 2005 02:33:28 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 3C5677306E; Wed, 13 Apr 2005 02:33:19 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050413063319.3C5677306E@freebsd-current.sentex.ca> Date: Wed, 13 Apr 2005 02:33:19 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.82, clamav-milter version 0.82 on clamscanner2 X-Virus-Status: Clean Subject: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 06:33:21 -0000 TB --- 2005-04-13 04:19:57 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-13 04:19:57 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2005-04-13 04:19:57 - checking out the source tree TB --- 2005-04-13 04:19:57 - cd /home/tinderbox/CURRENT/amd64/amd64 TB --- 2005-04-13 04:19:57 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-13 04:38:09 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-13 04:38:09 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-04-13 04:38:09 - /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-04-13 06:31:45 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-13 06:31:45 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-04-13 06:31:45 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Wed Apr 13 06:31:45 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 [...] /tinderbox/CURRENT/amd64/amd64/src/sys/dev/twa/tw_cl_misc.c:47:27: tw_cl_externs.h: No such file or directory /tinderbox/CURRENT/amd64/amd64/src/sys/dev/twa/tw_cl_misc.c:48:26: tw_osl_ioctl.h: No such file or directory /tinderbox/CURRENT/amd64/amd64/src/sys/dev/twa/tw_osl_cam.c:42:29: tw_osl_includes.h: No such file or directory /tinderbox/CURRENT/amd64/amd64/src/sys/dev/twa/tw_osl_freebsd.c:45:29: tw_osl_includes.h: No such file or directory /tinderbox/CURRENT/amd64/amd64/src/sys/dev/twa/tw_osl_freebsd.c:46:24: tw_cl_fwif.h: No such file or directory /tinderbox/CURRENT/amd64/amd64/src/sys/dev/twa/tw_osl_freebsd.c:47:25: tw_cl_ioctl.h: No such file or directory /tinderbox/CURRENT/amd64/amd64/src/sys/dev/twa/tw_osl_freebsd.c:48:26: tw_osl_ioctl.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. TB --- 2005-04-13 06:33:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-13 06:33:19 - ERROR: failed to build generic kernel TB --- 2005-04-13 06:33:19 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 06:45:00 2005 Return-Path: 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 02AFF16A4CE; Wed, 13 Apr 2005 06:45:00 +0000 (GMT) Received: from sasami.jurai.net (sasami.jurai.net [69.17.104.113]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7AA8743D54; Wed, 13 Apr 2005 06:44:59 +0000 (GMT) (envelope-from mdodd@FreeBSD.ORG) Received: from sasami.jurai.net (winter@sasami.jurai.net [69.17.104.113]) by sasami.jurai.net (8.13.1/8.13.1) with ESMTP id j3D6iuMw081590; Wed, 13 Apr 2005 02:44:58 -0400 (EDT) (envelope-from mdodd@FreeBSD.ORG) Date: Wed, 13 Apr 2005 02:44:56 -0400 (EDT) From: "Matthew N. Dodd" X-X-Sender: winter@sasami.jurai.net To: Suleiman Souhlal In-Reply-To: <0842a01b5aa0cfcd84763fff4a30113e@FreeBSD.org> Message-ID: <20050413024419.I3762@sasami.jurai.net> References: <0842a01b5aa0cfcd84763fff4a30113e@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.5.6 (sasami.jurai.net [69.17.104.113]); Wed, 13 Apr 2005 02:44:58 -0400 (EDT) cc: current@FreeBSD.ORG Subject: Re: [PATCH] Allow watching of vnodes that reside on non-UFSfilesystems with kqueue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 06:45:00 -0000 On Tue, 12 Apr 2005, Suleiman Souhlal wrote: > I would like to commit this to HEAD, if there are no objections. You should probably wait until you've heard from someone working on the AUDIT code before going forward with this change. -- 10 40 80 C0 00 FF FF FF FF C0 00 00 00 00 10 AA AA 03 00 00 00 08 00 From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 07:22:32 2005 Return-Path: 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 EDF3616A4CE for ; Wed, 13 Apr 2005 07:22:32 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48F1F43D4C for ; Wed, 13 Apr 2005 07:22:32 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j3D7PhDl042879; Wed, 13 Apr 2005 01:25:44 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <425CC7F8.3030803@samsco.org> Date: Wed, 13 Apr 2005 01:19:20 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jiawei Ye References: In-Reply-To: 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 Subject: Re: How does one know how many thread a process owns? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 07:22:33 -0000 Jiawei Ye wrote: >>From top in pkgsrc, one can know that a certain process has some > number of LWP in it. > load averages: 1.89, 1.72, 1.68; up 119+05:28:10 13:30:48 > 154 processes: 152 sleeping, 1 running, 1 on cpu > CPU states: % idle, % user, % kernel, % iowait, % swap > Memory: 1024M real, 414M free, 841M swap in use, 1956M swap free > > PID USERNAME LWP PRI NICE SIZE RES STATE TIME CPU COMMAND > 21891 bond 1 4 2 19M 1864K run 31.7H 77.04% upd_twd_15min > 17153 bond 1 50 2 82M 6164K sleep 37:37 12.98% dataserver.tsk > 17151 bond 1 53 2 82M 81M sleep 41:57 0.96% dataserver.tsk > 13742 otc 1 53 2 30M 21M sleep 3:31 0.89% dataserver.tsk > 17204 mtrs 1 53 2 82M 6144K sleep 2:47 0.67% dataserver.tsk > 17321 mtrs 1 53 2 25M 7908K sleep 2:21 0.49% otcmgr.tsk > 16250 root 1 59 0 4136K 2224K sleep 0:00 0.47% sshd > 13745 otc 1 53 2 30M 2496K sleep 2:55 0.36% dataserver.tsk > 3821 jessica 1 59 0 31M 4816K sleep 6:25 0.34% dataserver.tsk > 17227 bond 1 53 2 25M 7908K sleep 2:46 0.31% otcmgr.tsk > 17553 otc 1 53 2 17M 1208K sleep 0:46 0.18% icbc_pricing > 16269 leafy 1 45 0 3360K 1688K sleep 0:00 0.13% bash > 17202 mtrs 1 53 2 82M 19M sleep 1:08 0.12% dataserver.tsk > 17154 bond 1 53 2 82M 8004K sleep 0:35 0.12% dataserver.tsk > 13746 otc 1 53 2 30M 5136K sleep 0:37 0.11% dataserver.tsk > > In our top, show threads does not tell you how many threads exactly > exists in a process, is there any way to imitate the other top's > behaviour? > > Jiawei With KSE threads (the default libpthread.so library), the kernel doesn't know about all of the process-scope threads that are alive it only knows about the ones that are running currently or are blocked within the kernel. These are not the same as LWP, since they are scheduled in userland and thus are somewhat invisible to the kernel. There are various ways to set libpthread to create only process-scope threads that look a little more like LWP, or you can switch to the libthr.so library that exclusively creates 1:1 threads that are always visible to the kernel. Scott From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 07:29:28 2005 Return-Path: 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 A045316A4CE for ; Wed, 13 Apr 2005 07:29:28 +0000 (GMT) Received: from anduin.net (anduin.net [212.12.46.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 509D443D1F for ; Wed, 13 Apr 2005 07:29:28 +0000 (GMT) (envelope-from ltning@anduin.net) Received: from [213.225.74.166] (helo=[10.0.16.10]) by anduin.net with esmtpa (Exim 4.50 (FreeBSD)) id 1DLcJT-0000fH-DP for current@freebsd.org; Wed, 13 Apr 2005 09:29:27 +0200 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Wed, 13 Apr 2005 09:29:25 +0200 From: Eirik =?ISO-8859-1?B?2A==?=verby To: "current@freebsd.org" Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Subject: Re: Mysterious hangs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 07:29:28 -0000 Sorry, this was meant for the amd64 list. Got another report for this list. Confused the addresses. On 13-04-05 07:28, "Eirik =D8verby" wrote: > Hi, >=20 > For some time I've been seeing infrequent and seemingly random hangs on m= y > dual opteron system. Motherboard is Tyan K8S Pro. Until now I thought it = was a > "hard" hang, but I've got serial console hooked up and BREAK_TO_DEBUGGER,= DDB > and KDB in the kernel, and when sending a break through telnet I get: >=20 > telnet> send brk=20 > KDB: enter: Line break on console >=20 > And nothing more. Which means the box is sort of alive, but fails to pres= ent > even the kernel debugger. The machine is currently on 5.4 as of yesterday= . > It's been hanging before (with anything from days to weeks between), unde= r > various variations of 5.x, but I haven't had the serial console before no= w. >=20 > Has any one seen this before? Any ideas what I could look at? I suspected > hardware, but it seems that isn't the case as most HW errors I've seen wo= uld > cause a total freeze. >=20 > Here's to hoping. >=20 > Thanks, > /Eirik From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 07:32:38 2005 Return-Path: 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 220D416A4CE for ; Wed, 13 Apr 2005 07:32:38 +0000 (GMT) Received: from anduin.net (anduin.net [212.12.46.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCA4943D45 for ; Wed, 13 Apr 2005 07:32:37 +0000 (GMT) (envelope-from ltning@anduin.net) Received: from [213.225.74.166] (helo=[10.0.16.10]) by anduin.net with esmtpa (Exim 4.50 (FreeBSD)) id 1DLcMW-0000i3-WF for current@freebsd.org; Wed, 13 Apr 2005 09:32:37 +0200 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Wed, 13 Apr 2005 09:32:35 +0200 From: Eirik =?ISO-8859-1?B?2A==?=verby To: "current@freebsd.org" Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Panic after "in_cksum_skip: out of data by 260" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 07:32:38 -0000 Hi, Today I received this message on my serial console: in_cksum_skip: out of data by 260 Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 00 fault virtual address = 0xc fault code = supervisor read, page not present instruction pointer = 0x8:0xc066ec33 stack pointer = 0x10:0xd5437974 frame pointer = 0x10:0xd5437998 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 36 (swi1: net) trap number = 12 panic: page fault cpuid = 1 boot() called on cpu#0 Uptime: 1d15h8m10s This server has been very stable for a very long time. This crash surprises me somewhat. Uname output: FreeBSD carnen.net 5.3-STABLE FreeBSD 5.3-STABLE #0: Wed Feb 2 21:02:44 CET 2005 root@carnen.net:/usr/obj/usr/src/sys/CARNEN i386 Any idea what could have caused this? Thanks, /Eirik From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 07:53:12 2005 Return-Path: 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 3617316A4CE for ; Wed, 13 Apr 2005 07:53:12 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E239C43D2D; Wed, 13 Apr 2005 07:53:11 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j3D7rAfQ014967; Wed, 13 Apr 2005 07:53:10 GMT (envelope-from davidxu@freebsd.org) Message-ID: <425CD009.6040208@freebsd.org> Date: Wed, 13 Apr 2005 15:53:45 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050319 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Long References: <425CC7F8.3030803@samsco.org> In-Reply-To: <425CC7F8.3030803@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: Jiawei Ye Subject: Re: How does one know how many thread a process owns? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 07:53:12 -0000 Scott Long wrote: > Jiawei Ye wrote: > >>> From top in pkgsrc, one can know that a certain process has some >> >> number of LWP in it. >> load averages: 1.89, 1.72, 1.68; up >> 119+05:28:10 13:30:48 >> 154 processes: 152 sleeping, 1 running, 1 on cpu >> CPU states: % idle, % user, % kernel, % iowait, % >> swap >> Memory: 1024M real, 414M free, 841M swap in use, 1956M swap free >> >> PID USERNAME LWP PRI NICE SIZE RES STATE TIME CPU COMMAND >> 21891 bond 1 4 2 19M 1864K run 31.7H 77.04% >> upd_twd_15min >> 17153 bond 1 50 2 82M 6164K sleep 37:37 12.98% >> dataserver.tsk >> 17151 bond 1 53 2 82M 81M sleep 41:57 0.96% >> dataserver.tsk >> 13742 otc 1 53 2 30M 21M sleep 3:31 0.89% >> dataserver.tsk >> 17204 mtrs 1 53 2 82M 6144K sleep 2:47 0.67% >> dataserver.tsk >> 17321 mtrs 1 53 2 25M 7908K sleep 2:21 0.49% otcmgr.tsk >> 16250 root 1 59 0 4136K 2224K sleep 0:00 0.47% sshd >> 13745 otc 1 53 2 30M 2496K sleep 2:55 0.36% >> dataserver.tsk >> 3821 jessica 1 59 0 31M 4816K sleep 6:25 0.34% >> dataserver.tsk >> 17227 bond 1 53 2 25M 7908K sleep 2:46 0.31% otcmgr.tsk >> 17553 otc 1 53 2 17M 1208K sleep 0:46 0.18% >> icbc_pricing >> 16269 leafy 1 45 0 3360K 1688K sleep 0:00 0.13% bash >> 17202 mtrs 1 53 2 82M 19M sleep 1:08 0.12% >> dataserver.tsk >> 17154 bond 1 53 2 82M 8004K sleep 0:35 0.12% >> dataserver.tsk >> 13746 otc 1 53 2 30M 5136K sleep 0:37 0.11% >> dataserver.tsk >> >> In our top, show threads does not tell you how many threads exactly >> exists in a process, is there any way to imitate the other top's >> behaviour? >> >> Jiawei > > > With KSE threads (the default libpthread.so library), the kernel doesn't > know about all of the process-scope threads that are alive it only > knows about the ones that are running currently or are blocked within > the kernel. These are not the same as LWP, since they are scheduled in > userland and thus are somewhat invisible to the kernel. There are > various ways to set libpthread to create only process-scope threads that > look a little more like LWP, or you can switch to the libthr.so library > that exclusively creates 1:1 threads that are always visible to the > kernel. > > Scott I believe he wants to see total threads number in a process. add a column to top to display total kernel threads in per-process, p_numthreads in proc structure is what you need . :) David Xu From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 08:00:00 2005 Return-Path: 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 5210A16A4CE for ; Wed, 13 Apr 2005 08:00:00 +0000 (GMT) Received: from mail17.syd.optusnet.com.au (mail17.syd.optusnet.com.au [211.29.132.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7943543D5E for ; Wed, 13 Apr 2005 07:59:59 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j3D7xvli020393 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 13 Apr 2005 17:59:58 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j3D7xu7l000952 for ; Wed, 13 Apr 2005 17:59:56 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost) by cirb503493.alcatel.com.au (8.12.10/8.12.9/Submit) id j3D7xuWq000951 for freebsd-current@FreeBSD.ORG; Wed, 13 Apr 2005 17:59:56 +1000 (EST) (envelope-from pjeremy) Date: Wed, 13 Apr 2005 17:59:56 +1000 From: Peter Jeremy To: FreeBSD Current Message-ID: <20050413075956.GO89047@cirb503493.alcatel.com.au> References: <1113332762.27362.29.camel@localhost.localdomain> <20050412195700.GN89047@cirb503493.alcatel.com.au> <20050413030814.GA21318@VARK.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050413030814.GA21318@VARK.MIT.EDU> User-Agent: Mutt/1.4.2i Subject: Re: strtonum(3) in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 08:00:00 -0000 On Tue, 2005-Apr-12 23:08:15 -0400, David Schultz wrote: >It actually has a sensible way of distinguishing errors (it always >sets errno, even if to 0), I thought so initially but on closer reading, it does correctly preserve errno on success. > but this is unintuitive to anyone who >is used to the broken POSIX way of doing it. I would dispute the 'broken' adjective. Having errno only affected by errors means that you can issue a series of system calls and determine that something failed - which may be enough. POSIX inherited this behaviour from Unix - which has always behaved this way AFAIK. (That said, there are a couple of library functions that change errno but return success). -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 08:01:37 2005 Return-Path: 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 EB90316A4CE; Wed, 13 Apr 2005 08:01:37 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 420C543D4C; Wed, 13 Apr 2005 08:01:37 +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 j3D81al4031546; Wed, 13 Apr 2005 04:01:36 -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 j3D81jEb013489; Wed, 13 Apr 2005 04:01:45 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id A3C777306E; Wed, 13 Apr 2005 04:01:36 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050413080136.A3C777306E@freebsd-current.sentex.ca> Date: Wed, 13 Apr 2005 04:01:36 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.82, clamav-milter version 0.82 on clamscanner4 X-Virus-Status: Clean Subject: [current tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 08:01:38 -0000 TB --- 2005-04-13 06:33:19 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-13 06:33:19 - starting CURRENT tinderbox run for i386/i386 TB --- 2005-04-13 06:33:19 - checking out the source tree TB --- 2005-04-13 06:33:19 - cd /home/tinderbox/CURRENT/i386/i386 TB --- 2005-04-13 06:33:19 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-13 06:40:05 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-13 06:40:05 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-04-13 06:40:05 - /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-04-13 08:00:01 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-13 08:00:01 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-04-13 08:00:01 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Wed Apr 13 08:00: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 [...] /tinderbox/CURRENT/i386/i386/src/sys/dev/twa/tw_cl_misc.c:47:27: tw_cl_externs.h: No such file or directory /tinderbox/CURRENT/i386/i386/src/sys/dev/twa/tw_cl_misc.c:48:26: tw_osl_ioctl.h: No such file or directory /tinderbox/CURRENT/i386/i386/src/sys/dev/twa/tw_osl_cam.c:42:29: tw_osl_includes.h: No such file or directory /tinderbox/CURRENT/i386/i386/src/sys/dev/twa/tw_osl_freebsd.c:45:29: tw_osl_includes.h: No such file or directory /tinderbox/CURRENT/i386/i386/src/sys/dev/twa/tw_osl_freebsd.c:46:24: tw_cl_fwif.h: No such file or directory /tinderbox/CURRENT/i386/i386/src/sys/dev/twa/tw_osl_freebsd.c:47:25: tw_cl_ioctl.h: No such file or directory /tinderbox/CURRENT/i386/i386/src/sys/dev/twa/tw_osl_freebsd.c:48:26: tw_osl_ioctl.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. TB --- 2005-04-13 08:01:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-13 08:01:36 - ERROR: failed to build generic kernel TB --- 2005-04-13 08:01:36 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 08:10:54 2005 Return-Path: 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 EEC4716A500; Wed, 13 Apr 2005 08:10:54 +0000 (GMT) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9EBF143D31; Wed, 13 Apr 2005 08:10:53 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) (8.13.4/8.13.3) with ESMTP id j3D8Ao0F077076 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 13 Apr 2005 10:10:50 +0200 (CEST) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.4/8.13.3/Submit) id j3D8AoWJ077075; Wed, 13 Apr 2005 10:10:50 +0200 (CEST) Date: Wed, 13 Apr 2005 10:10:50 +0200 From: Divacky Roman To: John Baldwin Message-ID: <20050413081050.GA76859@stud.fit.vutbr.cz> References: <20050406130909.GA90294@stud.fit.vutbr.cz> <200504112038.32964.jhb@FreeBSD.org> <20050412073810.GA89527@stud.fit.vutbr.cz> <200504121253.50950.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504121253.50950.jhb@FreeBSD.org> User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.49 on 147.229.10.14 cc: current@freebsd.org Subject: Re: slow kbd input on 6-current on amd64@nforce3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 08:10:55 -0000 On Tue, Apr 12, 2005 at 12:53:50PM -0400, John Baldwin wrote: > On Tuesday 12 April 2005 03:38 am, Divacky Roman wrote: > > On Mon, Apr 11, 2005 at 08:38:32PM -0400, John Baldwin wrote: > > > On Wednesday 06 April 2005 09:09 am, Divacky Roman wrote: > > > > as I have mentioned on the list I have very slow keyboard input. it > > > > might be related to kbd not having an IRQ assigned. I repeat once again > > > > that it worked on 5.3R. > > > > > > Actually, now that I look at this, you have a buggy BIOS. It is lying > > > and claiming that some PCI interrupts are active-hi rather than > > > active-low. Hmm, the 5.3 dmesg you gave me included APIC, while this one > > > does not. Does disabling ACPI make your keyboard happy on 6.0 by chance? > > > > It doesnt boot with acpi enabled (stops in probing ata devices, but it > > never worked so I think ata is not the only culprit) > > Ok. > > > what can I do with it? would some quirk made the trick? why it worked in > > 5.3R? > > I don't know at this point. Does 6.0 in any configuration work ok? > (ACPI !APIC, ACPI APIC, !ACPI APIC, !ACPI !APIC) it doesnt boot with ACPI which eliminates first two cases, and I tried all combinations of # Workarounds for some known-to-be-broken chipsets (nVidia nForce3-Pro150) device atpic # 8259A compatability options NO_MIXED_MODE # Don't penalize working chipsets and none worked... ie. I think it eliminates later two cases you said the logic of active interrupts is reverted. where in the code can I revert this? I'll try it and if it works I can define some quirk... thnx for answer roman From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 08:40:14 2005 Return-Path: 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 84D0C16A4CE for ; Wed, 13 Apr 2005 08:40:14 +0000 (GMT) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id B93D043D1D for ; Wed, 13 Apr 2005 08:40:10 +0000 (GMT) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: from ednmsw501.dsto.defence.gov.au (ednmsw501.dsto.defence.gov.au [131.185.2.150]) by digger1.defence.gov.au with ESMTP id j3D8cdIJ012542 for ; Wed, 13 Apr 2005 18:08:39 +0930 (CST) Received: from muttley.dsto.defence.gov.au (unverified) by ednmsw501.dsto.defence.gov.au (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Wed, 13 Apr 2005 18:10:04 +0930 Received: from ednex501.dsto.defence.gov.au (ednex501.dsto.defence.gov.au [131.185.2.81]) by muttley.dsto.defence.gov.au (8.11.3/8.11.3) with ESMTP id j3D8WY022728 for ; Wed, 13 Apr 2005 18:02:35 +0930 (CST) Received: from squash.dsto.defence.gov.au ([131.185.40.212]) by ednex501.dsto.defence.gov.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HC90C3HR; Wed, 13 Apr 2005 18:02:21 +0930 Received: from squash.dsto.defence.gov.au (localhost [127.0.0.1]) by squash.dsto.defence.gov.au (8.12.11/8.12.11) with ESMTP id j3D8ZnG5038963 ; Wed, 13 Apr 2005 18:05:49 +0930 (CST) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by squash.dsto.defence.gov.au (8.12.11/8.12.11/Submit) id j3D8Zn6t038962; Wed, 13 Apr 2005 18:05:49 +0930 (CST) (envelope-from wilkinsa) Date: Wed, 13 Apr 2005 18:05:49 +0930 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org Message-ID: <20050413083545.GA38947@squash.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org, matthew.thyer@dsto.defence.gov.au Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline User-Agent: Mutt/1.5.6i cc: matthew.thyer@dsto.defence.gov.au Subject: LOR - vnode interlock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 08:40:14 -0000 FreeBSD 6.0-CURRENT #3: Fri Apr 1 08:10:42 CST 2005 acquiring duplicate lock of same type: "vnode interlock" 1st vnode interlock @ /usr/src/sys/kern/vfs_vnops.c:800 2nd vnode interlock @ /usr/src/sys/modules/nullfs/../../fs/nullfs/null_vnops.c:533 KDB: stack backtrace: witness_checkorder(c2e663b8,9,c2e6c5a1,215,c09ccdcc) at witness_checkorder+0x5ed _mtx_lock_flags(c2e663b8,0,c2e6c5a1,215,c2bf4cf0) at _mtx_lock_flags+0x54 null_lock(e97d8b14,1002,c2e61e04) at null_lock+0x67 VOP_LOCK_APV(c2e6d820,e97d8b14,c08c3443,320,c2e61e04) at VOP_LOCK_APV+0x69 vn_lock(c2e61e04,1002,c2bf4cf0,c2e6d720,e97d8cbc) at vn_lock+0x5a nullfs_root(c2d90000,2,e97d8ba0,c2bf4cf0,0) at nullfs_root+0x32 vfs_donmount(c2de8780,6,e97d8cd0,c2de8780,0) at vfs_donmount+0xd6d nmount(c2bf4cf0,e97d8d14,c08dcb40,3ad,3) at nmount+0x6f syscall(2f,2f,2f,bfbfe64a,bfbfeeb0) at syscall+0x13b Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280b7f6b, esp = 0xbfbfe5ec, ebp = 0xbfbfee84 --- X will not exec. Just a blank screen. Can ssh(1) into the box however. - aW From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 09:15:23 2005 Return-Path: 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 CA72A16A4CE for ; Wed, 13 Apr 2005 09:15:23 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76ACD43D5D for ; Wed, 13 Apr 2005 09:15:23 +0000 (GMT) (envelope-from leafy7382@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so99380rng for ; Wed, 13 Apr 2005 02:15: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=Cr7cOBHM2o70FCkgQtAnJxTazrSdl2uavny1EOrebpbKnDNLPsi/nuUhsnDDMBJUSVTiWm+7gFoQssRHyKEuFMdh0aeOxU0S6BP3eANRuUrDQ3bGLpRIR43I5Jgx/ZnGLyyUDpU+9GBi17QFb6KM9jcasa+z3Vvs2SFdUsr+0XI= Received: by 10.39.1.41 with SMTP id d41mr409519rni; Wed, 13 Apr 2005 02:15:23 -0700 (PDT) Received: by 10.38.22.48 with HTTP; Wed, 13 Apr 2005 02:15:23 -0700 (PDT) Message-ID: Date: Wed, 13 Apr 2005 17:15:23 +0800 From: Jiawei Ye To: David Xu In-Reply-To: <425CD009.6040208@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <425CC7F8.3030803@samsco.org> <425CD009.6040208@freebsd.org> cc: freebsd-current@freebsd.org Subject: Re: How does one know how many thread a process owns? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Jiawei Ye List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 09:15:23 -0000 On 4/13/05, David Xu wrote: > I believe he wants to see total threads number in a process. add a column > to top to display total kernel threads in per-process, p_numthreads in pr= oc > structure is what you need . :) >=20 > David Xu Exactly what I want. Is is possible to modify our top? Jiawei Ye --=20 "Without the userland, the kernel is useless." --inspired by The Tao of Programming From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 09:44:14 2005 Return-Path: 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 47BCD16A4CE for ; Wed, 13 Apr 2005 09:44:14 +0000 (GMT) Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id AFB6A43D1F for ; Wed, 13 Apr 2005 09:44:13 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix3-1.free.fr (Postfix) with ESMTP id B1ED91734F5; Wed, 13 Apr 2005 11:44:12 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 19030405A; Wed, 13 Apr 2005 11:43:38 +0200 (CEST) Date: Wed, 13 Apr 2005 11:43:38 +0200 From: Jeremie Le Hen To: Eirik =?iso-8859-1?Q?=D8verby?= Message-ID: <20050413094338.GE63229@obiwan.tataz.chchile.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i cc: "current@freebsd.org" Subject: Re: Panic after "in_cksum_skip: out of data by 260" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 09:44:14 -0000 Hi Eirik, > Today I received this message on my serial console: > > in_cksum_skip: out of data by 260 > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 00 > fault virtual address = 0xc > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc066ec33 > stack pointer = 0x10:0xd5437974 > frame pointer = 0x10:0xd5437998 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 36 (swi1: net) > trap number = 12 > panic: page fault > cpuid = 1 > boot() called on cpu#0 > Uptime: 1d15h8m10s > > This server has been very stable for a very long time. This crash surprises > me somewhat. > Uname output: > FreeBSD carnen.net 5.3-STABLE FreeBSD 5.3-STABLE #0: Wed Feb 2 21:02:44 CET > 2005 root@carnen.net:/usr/obj/usr/src/sys/CARNEN i386 > > Any idea what could have caused this? I have no idea about what could have caused this, but in this case, it would be useful to have a crashdump and its associated kernel.debug file, or at least a backtrace (but you must have enabled the break to debugger on panic). I guess you could also use addr2line(1) to determine which function caused the panic from the instruction pointer, but it's likely not enough to help understanding the problem. In order to get a crashdump, your swap space must at least be as large as your RAM and you will have to set the following variables : dumpdev="AUTO" dumpdir="/usr/space/crash" Note that if dumpdir is not set, it defaults to /var/crash. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 09:50:16 2005 Return-Path: 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 694C216A4CF for ; Wed, 13 Apr 2005 09:50:16 +0000 (GMT) Received: from sp.dominia.org (efnet-math.org [69.60.109.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8F3143D48 for ; Wed, 13 Apr 2005 09:50:15 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from [192.168.1.12] (63-170-138-118.cst-sg.blacksburg.ntc-com.net [63.170.138.118]) (authenticated bits=0) by sp.dominia.org (8.13.1/8.13.1) with ESMTP id j3D9oDPI007577 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 13 Apr 2005 05:50:14 -0400 In-Reply-To: <20050413054020.GL56487@funkthat.com> References: <0842a01b5aa0cfcd84763fff4a30113e@FreeBSD.org> <20050413054020.GL56487@funkthat.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Suleiman Souhlal Date: Wed, 13 Apr 2005 05:50:08 -0400 To: John-Mark Gurney X-Mailer: Apple Mail (2.619.2) cc: current@FreeBSD.org Subject: Re: [PATCH] Allow watching of vnodes that reside on non-UFS filesystems with kqueue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 09:50:16 -0000 Hi, On Apr 13, 2005, at 1:40 AM, John-Mark Gurney wrote: > also, > it appears that we lost support for extending of files... though I > can't > confirm that... Have you verified that extending still gets notified? extending files still actually works.. -- Suleiman Souhlal | ssouhlal@vt.edu The FreeBSD Project | ssouhlal@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 09:59:45 2005 Return-Path: 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 A397216A4CE; Wed, 13 Apr 2005 09:59:45 +0000 (GMT) Received: from sp.dominia.org (efnet-math.org [69.60.109.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A95C43D48; Wed, 13 Apr 2005 09:59:45 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from [192.168.1.12] (63-170-138-118.cst-sg.blacksburg.ntc-com.net [63.170.138.118]) (authenticated bits=0) by sp.dominia.org (8.13.1/8.13.1) with ESMTP id j3D9xhmC007596 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 13 Apr 2005 05:59:44 -0400 In-Reply-To: <20050413024419.I3762@sasami.jurai.net> References: <0842a01b5aa0cfcd84763fff4a30113e@FreeBSD.org> <20050413024419.I3762@sasami.jurai.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9f5d2c0035da3f743cc00e15b60e7eb9@FreeBSD.org> Content-Transfer-Encoding: 7bit From: Suleiman Souhlal Date: Wed, 13 Apr 2005 05:59:39 -0400 To: "Matthew N. Dodd" X-Mailer: Apple Mail (2.619.2) cc: current@FreeBSD.org Subject: Re: [PATCH] Allow watching of vnodes that reside on non-UFS filesystems with kqueue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 09:59:45 -0000 Hi, On Apr 13, 2005, at 2:44 AM, Matthew N. Dodd wrote: > On Tue, 12 Apr 2005, Suleiman Souhlal wrote: >> I would like to commit this to HEAD, if there are no objections. > > You should probably wait until you've heard from someone working on > the AUDIT code before going forward with this change. I didn't actually touch anything mac/audit related. I was just saying what those hooks could be used for in the future.. -- Suleiman Souhlal | ssouhlal@vt.edu The FreeBSD Project | ssouhlal@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 10:15:45 2005 Return-Path: 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 D020416A4CE for ; Wed, 13 Apr 2005 10:15:45 +0000 (GMT) Received: from anduin.net (anduin.net [212.12.46.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B39C43D1F for ; Wed, 13 Apr 2005 10:15:45 +0000 (GMT) (envelope-from ltning@anduin.net) Received: from [213.225.74.166] (helo=[10.0.16.10]) by anduin.net with esmtpa (Exim 4.50 (FreeBSD)) id 1DLeuN-0001QP-Vu; Wed, 13 Apr 2005 12:15:44 +0200 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Wed, 13 Apr 2005 12:15:41 +0200 From: Eirik =?ISO-8859-1?B?2A==?=verby To: Jeremie Le Hen Message-ID: In-Reply-To: <20050413094338.GE63229@obiwan.tataz.chchile.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit cc: "current@freebsd.org" Subject: Re: Panic after "in_cksum_skip: out of data by 260" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 10:15:45 -0000 On 13-04-05 11:43, "Jeremie Le Hen" wrote: > Hi Eirik, > >> Today I received this message on my serial console: >> >> in_cksum_skip: out of data by 260 >> Fatal trap 12: page fault while in kernel mode >> cpuid = 1; apic id = 00 >> fault virtual address = 0xc >> fault code = supervisor read, page not present >> instruction pointer = 0x8:0xc066ec33 >> stack pointer = 0x10:0xd5437974 >> frame pointer = 0x10:0xd5437998 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, def32 1, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 36 (swi1: net) >> trap number = 12 >> panic: page fault >> cpuid = 1 >> boot() called on cpu#0 >> Uptime: 1d15h8m10s >> >> This server has been very stable for a very long time. This crash surprises >> me somewhat. >> Uname output: >> FreeBSD carnen.net 5.3-STABLE FreeBSD 5.3-STABLE #0: Wed Feb 2 21:02:44 CET >> 2005 root@carnen.net:/usr/obj/usr/src/sys/CARNEN i386 >> >> Any idea what could have caused this? > > I have no idea about what could have caused this, but in this case, it > would be useful to have a crashdump and its associated kernel.debug file, > or at least a backtrace (but you must have enabled the break to debugger > on panic). I guess you could also use addr2line(1) to determine which > function caused the panic from the instruction pointer, but it's likely > not enough to help understanding the problem. I understand that, but this is a production server that has otherwise been stable for a long time. I suspect that this won't happen again for a while. I'll reconfigure it as you suggest at the next opportunity ;) /Eirik > > In order to get a crashdump, your swap space must at least be as large > as your RAM and you will have to set the following variables : > > dumpdev="AUTO" > dumpdir="/usr/space/crash" > > Note that if dumpdir is not set, it defaults to /var/crash. > > Best regards, From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 10:37:48 2005 Return-Path: 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 23B0D16A4CE for ; Wed, 13 Apr 2005 10:37:48 +0000 (GMT) Received: from postfix4-2.free.fr (postfix4-2.free.fr [213.228.0.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2BFE43D41 for ; Wed, 13 Apr 2005 10:37:47 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix4-2.free.fr (Postfix) with ESMTP id 7F2363192F2; Wed, 13 Apr 2005 12:37:46 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 5A90D405A; Wed, 13 Apr 2005 12:37:10 +0200 (CEST) Date: Wed, 13 Apr 2005 12:37:10 +0200 From: Jeremie Le Hen To: Eirik =?iso-8859-1?Q?=D8verby?= Message-ID: <20050413103710.GF63229@obiwan.tataz.chchile.org> References: <20050413094338.GE63229@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i cc: Jeremie Le Hen cc: "current@freebsd.org" Subject: Re: Panic after "in_cksum_skip: out of data by 260" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 10:37:48 -0000 > > I have no idea about what could have caused this, but in this case, it > > would be useful to have a crashdump and its associated kernel.debug file, > > or at least a backtrace (but you must have enabled the break to debugger > > on panic). I guess you could also use addr2line(1) to determine which > > function caused the panic from the instruction pointer, but it's likely > > not enough to help understanding the problem. > > I understand that, but this is a production server that has otherwise been > stable for a long time. I suspect that this won't happen again for a while. > > I'll reconfigure it as you suggest at the next opportunity ;) In case of a production server, you should be sure that you want to drop to debugger on panic since the machine won't reboot itself and thus will be down until human intervention. What I would advise you for now is to configure your rc.conf(5) in order to allow rc.d/savecore to save a coredump (see my previous mail). Since you must have rebooted your server now without having dumpdev and dumpdir set in rc.conf(5) at boot time, you should manually run dumpon -v $your_swap_device With this, upon next panic, FreeBSD will try to dump the whole memory into you swap device and then rc.d/savecore will save it in a file when booting. Finally, be sure that you will have enough space on the filesystem where $dumpdir points to. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 10:41:04 2005 Return-Path: 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 9156B16A4CE for ; Wed, 13 Apr 2005 10:41:04 +0000 (GMT) Received: from anduin.net (anduin.net [212.12.46.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3845443D54 for ; Wed, 13 Apr 2005 10:41:04 +0000 (GMT) (envelope-from ltning@anduin.net) Received: from [213.225.74.166] (helo=[10.0.16.10]) by anduin.net with esmtpa (Exim 4.50 (FreeBSD)) id 1DLfIt-0001c2-9y; Wed, 13 Apr 2005 12:41:03 +0200 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Wed, 13 Apr 2005 12:41:01 +0200 From: Eirik =?ISO-8859-1?B?2A==?=verby To: Jeremie Le Hen Message-ID: In-Reply-To: <20050413103710.GF63229@obiwan.tataz.chchile.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit cc: "current@freebsd.org" Subject: Re: Panic after "in_cksum_skip: out of data by 260" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 10:41:04 -0000 On 13-04-05 12:37, "Jeremie Le Hen" wrote: >>> I have no idea about what could have caused this, but in this case, it >>> would be useful to have a crashdump and its associated kernel.debug file, >>> or at least a backtrace (but you must have enabled the break to debugger >>> on panic). I guess you could also use addr2line(1) to determine which >>> function caused the panic from the instruction pointer, but it's likely >>> not enough to help understanding the problem. >> >> I understand that, but this is a production server that has otherwise been >> stable for a long time. I suspect that this won't happen again for a while. >> >> I'll reconfigure it as you suggest at the next opportunity ;) > > In case of a production server, you should be sure that you want to > drop to debugger on panic since the machine won't reboot itself and > thus will be down until human intervention. What I would advise you > for now is to configure your rc.conf(5) in order to allow rc.d/savecore > to save a coredump (see my previous mail). On it. Besides, the server fails to reboot at this stage anyway, so it doesn't matter. The server is surveilled 24/7 and all personnel at the monitoring centre knows how to reboot it via power sockets (remote controlled).. Whoever invented those should receive a nobel prize or something ;) > Since you must have rebooted your server now without having dumpdev and > dumpdir set in rc.conf(5) at boot time, you should manually run > > dumpon -v $your_swap_device > > With this, upon next panic, FreeBSD will try to dump the whole memory > into you swap device and then rc.d/savecore will save it in a file > when booting. > > Finally, be sure that you will have enough space on the filesystem > where $dumpdir points to. Thanks for your advice! /Eirik > Regards, From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 10:51:50 2005 Return-Path: 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 419D916A4CE for ; Wed, 13 Apr 2005 10:51:50 +0000 (GMT) Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8CA843D4C for ; Wed, 13 Apr 2005 10:51:49 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix3-2.free.fr (Postfix) with ESMTP id 37AF5C085; Wed, 13 Apr 2005 12:51:49 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id EADA1405A; Wed, 13 Apr 2005 12:51:15 +0200 (CEST) Date: Wed, 13 Apr 2005 12:51:15 +0200 From: Jeremie Le Hen To: Eirik =?iso-8859-1?Q?=D8verby?= Message-ID: <20050413105115.GG63229@obiwan.tataz.chchile.org> References: <20050413094338.GE63229@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050413094338.GE63229@obiwan.tataz.chchile.org> User-Agent: Mutt/1.5.8i cc: "current@freebsd.org" Subject: Re: Panic after "in_cksum_skip: out of data by 260" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 10:51:50 -0000 > I have no idea about what could have caused this, but in this case, it > would be useful to have a crashdump and its associated kernel.debug file, > or at least a backtrace (but you must have enabled the break to debugger > on panic). I guess you could also use addr2line(1) to determine which > function caused the panic from the instruction pointer, but it's likely > not enough to help understanding the problem. Since it's a NULL pointer derefence, mux@ told me the addr2line(1) result could be relevant, assuming you have a debug kernel compiled. Could you give back the result of the following command please : addr2line -e kernel.debug 0xc066ec33 Once addr2line(1) gave you the file and the line, it is also important to tell us the revision of the file. If you don't have a debug kernel, and you *absolutely* change neither the sources from which you compiled it nor the kernel configuration file, you should be able to rebuild it. -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 10:57:08 2005 Return-Path: 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 6EAC516A4CE for ; Wed, 13 Apr 2005 10:57:08 +0000 (GMT) Received: from anduin.net (anduin.net [212.12.46.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 17C6643D2F for ; Wed, 13 Apr 2005 10:57:08 +0000 (GMT) (envelope-from ltning@anduin.net) Received: from [213.225.74.166] (helo=[10.0.16.10]) by anduin.net with esmtpa (Exim 4.50 (FreeBSD)) id 1DLfYQ-0001fF-Mu; Wed, 13 Apr 2005 12:57:07 +0200 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Wed, 13 Apr 2005 12:56:58 +0200 From: Eirik =?ISO-8859-1?B?2A==?=verby To: Jeremie Le Hen Message-ID: In-Reply-To: <20050413105115.GG63229@obiwan.tataz.chchile.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit cc: "current@freebsd.org" Subject: Re: Panic after "in_cksum_skip: out of data by 260" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 10:57:08 -0000 On 13-04-05 12:51, "Jeremie Le Hen" wrote: >> I have no idea about what could have caused this, but in this case, it >> would be useful to have a crashdump and its associated kernel.debug file, >> or at least a backtrace (but you must have enabled the break to debugger >> on panic). I guess you could also use addr2line(1) to determine which >> function caused the panic from the instruction pointer, but it's likely >> not enough to help understanding the problem. > > Since it's a NULL pointer derefence, mux@ told me the addr2line(1) > result could be relevant, assuming you have a debug kernel > compiled. Could you give back the result of the following command > please : > > addr2line -e kernel.debug 0xc066ec33 > > Once addr2line(1) gave you the file and the line, it is also important > to tell us the revision of the file. > > If you don't have a debug kernel, and you *absolutely* change neither > the sources from which you compiled it nor the kernel configuration file, > you should be able to rebuild it. In that case I'm pretty much screwed ... I ran a 'make update' yesterday, but never got around to compiling a new kernel. Damn :( For next time - how do default to building a debug kernel along with the normal one? Thanks for your efforts though.. /Eirik From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 11:19:55 2005 Return-Path: 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 DE9B516A4CE for ; Wed, 13 Apr 2005 11:19:55 +0000 (GMT) Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 974FF43D1D for ; Wed, 13 Apr 2005 11:19:55 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix3-1.free.fr (Postfix) with ESMTP id E0E291734E4; Wed, 13 Apr 2005 13:19:54 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 755CD405A; Wed, 13 Apr 2005 13:19:21 +0200 (CEST) Date: Wed, 13 Apr 2005 13:19:21 +0200 From: Jeremie Le Hen To: Eirik =?iso-8859-1?Q?=D8verby?= Message-ID: <20050413111921.GH63229@obiwan.tataz.chchile.org> References: <20050413105115.GG63229@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i cc: Jeremie Le Hen cc: "current@freebsd.org" Subject: Re: Panic after "in_cksum_skip: out of data by 260" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 11:19:56 -0000 > In that case I'm pretty much screwed ... I ran a 'make update' yesterday, > but never got around to compiling a new kernel. Damn :( For next time - how > do default to building a debug kernel along with the normal one? The easiest way is to add the following line to your kernel configuration file : makeoptions DEBUG=-g -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 12:31:44 2005 Return-Path: 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 981DD16A4CE; Wed, 13 Apr 2005 12:31:44 +0000 (GMT) Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id CEBE943D53; Wed, 13 Apr 2005 12:31:43 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd26.aul.t-online.de by mailout06.sul.t-online.com with smtp id 1DLh1w-0004Pk-05; Wed, 13 Apr 2005 14:31:40 +0200 Received: from Andro-Beta.Leidinger.net (XH7oD4ZDoeZQHP8JfkALmMzcJEhWkgvkffJv3qrCqweCyCNGRIlkgX@[84.128.203.188]) by fwd26.sul.t-online.de with esmtp id 1DLh1o-1HA9wm0; Wed, 13 Apr 2005 14:31:32 +0200 Received: from localhost (localhost [127.0.0.1])j3DCVRZG004199; Wed, 13 Apr 2005 14:31:27 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from 141.113.101.32 ([141.113.101.32]) by netchild.homeip.net (Horde MIME library) with HTTP for ; Wed, 13 Apr 2005 14:31:26 +0200 Message-ID: <20050413143126.7e0jufn80c0cwow4@netchild.homeip.net> X-Priority: 3 (Normal) Date: Wed, 13 Apr 2005 14:31:26 +0200 From: Alexander Leidinger To: Julian Elischer References: <425C18A2.8010807@elischer.org> In-Reply-To: <425C18A2.8010807@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.2) / FreeBSD-4.11 X-ID: XH7oD4ZDoeZQHP8JfkALmMzcJEhWkgvkffJv3qrCqweCyCNGRIlkgX@t-dialin.net X-TOI-MSGID: d4943db9-dcd0-4f94-b995-b718f2a0bba5 cc: jmg@freebsd.org cc: FreeBSD Current cc: multimedia@freebsd.org Subject: Re: Anyone working on V4L2 for BSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 12:31:44 -0000 Julian Elischer wrote: > > I'm considerring it.. It looks quite doable. (assuming we can get > compatible include files > without copyright problems.) > > For compatibility we'd probably want to keep all the V4L prefixes etc. > > Is anyone else playing with this? There was a discussion about something like this a while ago... a, I see you participated in it too: http://lists.freebsd.org/pipermail/freebsd-multimedia/2003-July/000328.html http://people.freebsd.org/~jmg/videobsd.html Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 BOFH excuse #316: Elves on strike (Why do they call EMAG Elf Magic?) From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 13:00:19 2005 Return-Path: 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 C834316A4CE for ; Wed, 13 Apr 2005 13:00:19 +0000 (GMT) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B47D43D1F for ; Wed, 13 Apr 2005 13:00:18 +0000 (GMT) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: from ednmsw501.dsto.defence.gov.au (ednmsw501.dsto.defence.gov.au [131.185.2.150]) by digger1.defence.gov.au with ESMTP id j3DCwlB4028832 for ; Wed, 13 Apr 2005 22:28:47 +0930 (CST) Received: from muttley.dsto.defence.gov.au (unverified) by ednmsw501.dsto.defence.gov.au (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Wed, 13 Apr 2005 22:30:12 +0930 Received: from ednex501.dsto.defence.gov.au (ednex501.dsto.defence.gov.au [131.185.2.81]) by muttley.dsto.defence.gov.au (8.11.3/8.11.3) with ESMTP id j3DCrB020512 for ; Wed, 13 Apr 2005 22:23:11 +0930 (CST) Received: from squash.dsto.defence.gov.au ([131.185.40.212]) by ednex501.dsto.defence.gov.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HC90CVRS; Wed, 13 Apr 2005 22:22:57 +0930 Received: from squash.dsto.defence.gov.au (localhost [127.0.0.1]) by squash.dsto.defence.gov.au (8.12.11/8.12.11) with ESMTP id j3DCuQVm039925 ; Wed, 13 Apr 2005 22:26:26 +0930 (CST) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by squash.dsto.defence.gov.au (8.12.11/8.12.11/Submit) id j3DCuQIg039924; Wed, 13 Apr 2005 22:26:26 +0930 (CST) (envelope-from wilkinsa) Date: Wed, 13 Apr 2005 22:26:26 +0930 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org Message-ID: <20050413125622.GA39802@squash.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org, matthew.thyer@dsto.defence.gov.au Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline User-Agent: Mutt/1.5.6i cc: matthew.thyer@dsto.defence.gov.au Subject: panic upon bootstrap'ing - 6.0-CURRENT #4: Wed Apr 13 2005 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 13:00:19 -0000 FreeBSD 6.0-CURRENT #4: Wed Apr 13 21:06:05 CST 2005 FreeBSD/i386 bootstrap loader, Revision 1.1 (root@hostname.dsto.defence.gov.au, Wed Apr 13 18:58:54 CST 2005) Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x4e8874 data=0x7f7f0+0x9bd10 syms=[0x4+0x59560+0x4+0x6da15] /boot/kernel/linux.ko text=0x14ec8 data=0x1254+0x54 syms=[0x4+0x28b0+0x4+0x263e] /boot/kernel/agp.ko text=0xead4 data=0xc18+0x24 syms=[0x4+0x1730+0x4+0x1fc6] /boot/modules/nvidia.ko text=0x21a01c data=0x5d000+0x202a98 syms=[0x4+0x1e5b0+0x4+0x16d12] - Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... /boot/kernel/acpi.ko text=0x49ac0 data=0x2124+0x110c syms=[0x4+0x77c0+0x4+0x9f1a] GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb 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-CURRENT #4: Wed Apr 13 21:06:05 CST 2005 root@hostname.dsto.defence.gov.au:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2793.20-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff real memory = 1073741824 (1024 MB) avail memory = 1033625600 (985 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 acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xf808-0xf80b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 pci_link0: irq 10 on acpi0 pci_link1: irq 5 on acpi0 pci_link2: irq 10 on acpi0 pci_link3: irq 11 on acpi0 pci_link4: irq 5 on acpi0 pci_link5: irq 0 on acpi0 pci_link6: irq 0 on acpi0 pci_link7: irq 10 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xec000000-0xefffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 nvidia0: mem 0xf9000000-0xf9ffffff,0xf0000000-0xf7ffffff irq 18 at device 0.0 on pci1 WARNING: Device driver "lock order reversal 1st 0xc09831e0 cdev (cdev) @ /usr/src/sys/kern/kern_conf.c:60 2nd 0xc0982f84 user map (user map) @ /usr/src/sys/vm/vm_map.c:2998 KDB: stack backtrace: witness_checkorder(c0982f84,9,c08d9700,bb6,b) at witness_checkorder+0x5f1 _sx_xlock(c0982f84,c08d9700,bb6,1000001,480000) at _sx_xlock+0x5c vm_map_lookup(c1420728,480000,1,c142072c,c142071c) at vm_map_lookup+0x2e vm_fault(c0982f40,480000,1,0,c0982de0) at vm_fault+0x7b trap_pfault(480008,c142083c,c0682d05,c183afe4,480008) at trap_pfault+0x159 trap(18,c1420010,c06a0010,480008,c08bb8f5) at trap+0x34d calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc06d6224, esp = 0xc142083c, ebp = 0xc142083c --- strlen(480008,c1420924,1,6,18) at strlen+0x8 kvprintf(c08bb8db,c0682d5b,c1420924,a,c1420948) at kvprintf+0xbff printf(c08bb8db,480008,c08bb8b3,c2bcb60c,0) at printf+0x55 prep_cdevsw(c2bcb680,c2bcb580,1,c2bb7c20,0) at prep_cdevsw+0x33 make_dev(c0d73d00,0,0,0,1b6) at make_dev+0x28 nvidia_dev_attach(c2bb7c00,c2bcb580,a,c14209e0,c2bcb580) at nvidia_dev_attach+0x5f nvidia_attach(c2bcb580,c2bcb580,4,2,c091cd00) at nvidia_attach+0x2b9 nvidia_pci_attach(c2bcb580,c2b8804c,c091cd00,c08c10ad,0) at nvidia_pci_attach+0x1f0 device_attach(c2bcb580,1,c1420a9c,c05a691e,c2bcb680) at device_attach+0x2a7 bus_generic_attach(c2bcb680,1,7c,c1420a90,1) at bus_generic_attach+0x17 pci_attach(c2bcb680,c2b1104c,c091cd00,c08c10ad,0) at pci_attach+0x8a device_attach(c2bcb680,c2babb00,c1420b24,c067cde1,c2bab880) at device_attach+0x2a7 bus_generic_attach(c2bab880,c2b1084c,c091cd00,c08c10ad,0) at bus_generic_attach+0x17 device_attach(c2bab880,c2ae4a00,c1420b64,c0fdd927,c2babb00) at device_attach+0x2a7 bus_generic_attach(c2babb00,c2a6e7e0,1,c0fdd524,c2babb00) at bus_generic_attach+0x17 acpi_pci_attach(c2babb00,c2b8304c,c091cd00,c08c10ad,0) at acpi_pci_attach+0x11c device_attach(c2babb00,c2bab480,c1420be0,c0fddb4a,c2ae4a00) at device_attach+0x2a7 bus_generic_attach(c2ae4a00,c0ff2fd1,0,c1420bd0,c1420be0) at bus_generic_attach+0x17 acpi_pcib_attach(c2ae4a00,c2b189d4,0,c1420c08,c0fd8976) at acpi_pcib_attach+0xea acpi_pcib_acpi_attach(c2ae4a00,c2b9704c,c091cd00,c08c10ad,0) at acpi_pcib_acpi_attach+0xf5 device_attach(c2ae4a00,dffff,c1420cbc,c0fdb1cc,c2bab480) at device_attach+0x2a7 bus_generic_attach(c2bab480,d5400,dffff,c2b18ac8,d5400) at bus_generic_attach+0x17 acpi_attach(c2bab480,c2b8504c,c091cd00,c08c10ad,0) at acpi_attach+0x8cf device_attach(c2bab480,c2bab600,c1420d18,c0852e21,c2bab600) at device_attach+0x2a7 bus_generic_attach(c2bab600) at bus_generic_attach+0x17 nexus_attach(c2bab600,c2b6804c,c091cd00,c08c10ad,0) at nexus_attach+0x1a device_attach(c2bab600,c095b950,c1420d78,c083fe66,c2ae3480) at device_attach+0x2a7 root_bus_configure(c2ae3480,c08e1fad,0,c1420d98,c0636d35) at root_bus_configure+0x19 configure(0,0,c2a72c58,141ec00,141e000) at configure+0x29 mi_startup() at mi_startup+0xb1 begin() at begin+0x2c Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x480008 fault code = supervisor read, page not present instruction pointer = 0x8:0xc06d6224 stack pointer = 0x10:0xc142083c frame pointer = 0x10:0xc142083c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) [thread pid 0 tid 0 ] Stopped at strlen+0x8: cmpb $0,0(%edx) db> tr Tracing pid 0 tid 0 td 0xc0982de0 strlen(480008,c1420924,1,6,18) at strlen+0x8 kvprintf(c08bb8db,c0682d5b,c1420924,a,c1420948) at kvprintf+0xbff printf(c08bb8db,480008,c08bb8b3,c2bcb60c,0) at printf+0x55 prep_cdevsw(c2bcb680,c2bcb580,1,c2bb7c20,0) at prep_cdevsw+0x33 make_dev(c0d73d00,0,0,0,1b6) at make_dev+0x28 nvidia_dev_attach(c2bb7c00,c2bcb580,a,c14209e0,c2bcb580) at nvidia_dev_attach+0x5f nvidia_attach(c2bcb580,c2bcb580,4,2,c091cd00) at nvidia_attach+0x2b9 nvidia_pci_attach(c2bcb580,c2b8804c,c091cd00,c08c10ad,0) at nvidia_pci_attach+0x1f0 device_attach(c2bcb580,1,c1420a9c,c05a691e,c2bcb680) at device_attach+0x2a7 bus_generic_attach(c2bcb680,1,7c,c1420a90,1) at bus_generic_attach+0x17 pci_attach(c2bcb680,c2b1104c,c091cd00,c08c10ad,0) at pci_attach+0x8a device_attach(c2bcb680,c2babb00,c1420b24,c067cde1,c2bab880) at device_attach+0x2a7 bus_generic_attach(c2bab880,c2b1084c,c091cd00,c08c10ad,0) at bus_generic_attach+0x17 device_attach(c2bab880,c2ae4a00,c1420b64,c0fdd927,c2babb00) at device_attach+0x2a7 bus_generic_attach(c2babb00,c2a6e7e0,1,c0fdd524,c2babb00) at bus_generic_attach+0x17 acpi_pci_attach(c2babb00,c2b8304c,c091cd00,c08c10ad,0) at acpi_pci_attach+0x11c device_attach(c2babb00,c2bab480,c1420be0,c0fddb4a,c2ae4a00) at device_attach+0x2a7 bus_generic_attach(c2ae4a00,c0ff2fd1,0,c1420bd0,c1420be0) at bus_generic_attach+0x17 acpi_pcib_attach(c2ae4a00,c2b189d4,0,c1420c08,c0fd8976) at acpi_pcib_attach+0xea acpi_pcib_acpi_attach(c2ae4a00,c2b9704c,c091cd00,c08c10ad,0) at acpi_pcib_acpi_attach+0xf5 device_attach(c2ae4a00,dffff,c1420cbc,c0fdb1cc,c2bab480) at device_attach+0x2a7 bus_generic_attach(c2bab480,d5400,dffff,c2b18ac8,d5400) at bus_generic_attach+0x17 acpi_attach(c2bab480,c2b8504c,c091cd00,c08c10ad,0) at acpi_attach+0x8cf device_attach(c2bab480,c2bab600,c1420d18,c0852e21,c2bab600) at device_attach+0x2a7 bus_generic_attach(c2bab600) at bus_generic_attach+0x17 nexus_attach(c2bab600,c2b6804c,c091cd00,c08c10ad,0) at nexus_attach+0x1a device_attach(c2bab600,c095b950,c1420d78,c083fe66,c2ae3480) at device_attach+0x2a7 root_bus_configure(c2ae3480,c08e1fad,0,c1420d98,c0636d35) at root_bus_configure+0x19 configure(0,0,c2a72c58,141ec00,141e000) at configure+0x29 mi_startup() at mi_startup+0xb1 begin() at begin+0x2c db> show pcpu cpuid = 0 curthread = 0xc0982de0: pid 0 "swapper" curpcb = 0xc1420da0 fpcurthread = none idlethread = 0xc2a8b600: pid 11 "idle: cpu0" APIC ID = 0 currentldt = 0x28 spin locks held: db> show lockedvnods Locked vnodes db> show locks exclusive sleep mutex cdev r = 0 (0xc09831e0) locked @ /usr/src/sys/kern/kern_conf.c:60 exclusive sleep mutex Giant r = 0 (0xc0984ce0) locked @ /usr/src/sys/vm/vm_contig.c:550 db> ps pid proc uid ppid pgrp flag stat wmesg wchan cmd 7 c2aeede4 0 0 0 0000204 [RUNQ] acpi_task0 43 c2afa000 0 0 0 0000204 [RUNQ] swi6: acpitaskq 6 c2afa1fc 0 0 0 0000204 [RUNQ] kqueue taskq 42 c2afa3f8 0 0 0 0000204 [IWAIT] swi2: cambio 41 c2afa5f4 0 0 0 0000204 [IWAIT] swi6: task queue 40 c2afa7f0 0 0 0 0000204 [IWAIT] swi6:+ 5 c2afa9ec 0 0 0 0000204 [RUNQ] thread taskq 39 c2afabe8 0 0 0 0000204 [IWAIT] swi5:+ 38 c2afade4 0 0 0 0000204 [RUNQ] yarrow 4 c2afc000 0 0 0 0000204 [RUNQ] g_down 3 c2afc1fc 0 0 0 0000204 [RUNQ] g_up 2 c2ae15f4 0 0 0 0000204 [RUNQ] g_event 37 c2ae17f0 0 0 0 0000204 [IWAIT] swi3: vm 36 c2ae19ec 0 0 0 000020c [IWAIT] swi4: clock 35 c2ae1be8 0 0 0 0000204 [IWAIT] swi1: net 34 c2ae1de4 0 0 0 0000204 [IWAIT] irq0: 33 c2aee000 0 0 0 0000204 [IWAIT] irq23: 32 c2aee1fc 0 0 0 0000204 [IWAIT] irq22: 31 c2aee3f8 0 0 0 0000204 [IWAIT] irq21: 30 c2aee5f4 0 0 0 0000204 [IWAIT] irq20: 29 c2aee7f0 0 0 0 0000204 [IWAIT] irq19: 28 c2aee9ec 0 0 0 0000204 [IWAIT] irq18: 27 c2a8f1fc 0 0 0 0000204 [IWAIT] irq17: 26 c2a8f3f8 0 0 0 0000204 [IWAIT] irq16: 25 c2a8f5f4 0 0 0 0000204 [IWAIT] irq15: 24 c2a8f7f0 0 0 0 0000204 [IWAIT] irq14: 23 c2a8f9ec 0 0 0 0000204 [IWAIT] irq13: 22 c2a8fbe8 0 0 0 0000204 [IWAIT] irq12: 21 c2a8fde4 0 0 0 0000204 [IWAIT] irq11: 20 c2ae1000 0 0 0 0000204 [IWAIT] irq10: 19 c2ae11fc 0 0 0 0000204 [IWAIT] irq9: acpi0 18 c2ae13f8 0 0 0 0000204 [IWAIT] irq8: 17 c2a8a000 0 0 0 0000204 [IWAIT] irq7: 16 c2a8a1fc 0 0 0 0000204 [IWAIT] irq6: 15 c2a8a3f8 0 0 0 0000204 [IWAIT] irq5: 14 c2a8a5f4 0 0 0 0000204 [IWAIT] irq4: 13 c2a8a7f0 0 0 0 0000204 [IWAIT] irq3: 12 c2a8a9ec 0 0 0 0000204 [IWAIT] irq1: 11 c2a8abe8 0 0 0 000020c [Can run] idle: cpu0 1 c2a8ade4 0 0 0 0000200 [INACTIVE] swapper 10 c2a8f000 0 0 0 0000204 [RUNQ] ktrace 0 c0982be0 0 0 0 0000200 [CPU 0] swapper db> Cannot get a vmcore unless anyone can tell me the trick. db> call doadump Cannot dump. No dump device defined. 0x25 db> dumpon /dev/ad0s3b No such command - aW From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 13:26:08 2005 Return-Path: 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 6B6B816A4CE; Wed, 13 Apr 2005 13:26:08 +0000 (GMT) Received: from kane.otenet.gr (kane.otenet.gr [195.170.0.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BBCF43D2F; Wed, 13 Apr 2005 13:26:07 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from orion.daedalusnetworks.priv (aris.bedc.ondsl.gr [62.103.39.226])j3DDP38B024465; Wed, 13 Apr 2005 16:25:03 +0300 Received: from orion.daedalusnetworks.priv (orion [127.0.0.1]) j3DDQ4Cl039104; Wed, 13 Apr 2005 16:26:04 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost)j3DDQ4Z6039103; Wed, 13 Apr 2005 16:26:04 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Wed, 13 Apr 2005 16:26:04 +0300 From: Giorgos Keramidas To: Jiawei Ye Message-ID: <20050413132603.GA39006@orion.daedalusnetworks.priv> References: <425CC7F8.3030803@samsco.org> <425CD009.6040208@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: cc: freebsd-current@freebsd.org cc: David Xu Subject: Re: How does one know how many thread a process owns? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 13:26:08 -0000 On 2005-04-13 17:15, Jiawei Ye wrote: > On 4/13/05, David Xu wrote: > > I believe he wants to see total threads number in a process. add a column > > to top to display total kernel threads in per-process, p_numthreads in proc > > structure is what you need . :) > > > > David Xu > > Exactly what I want. Is is possible to modify our top? Can you try the following patch? I've added a THR column when top displays only one line per process. So when the "display each thread separately" mode is off, you should see something like this: % last pid: 39064; load averages: 0.08, 0.05, 0.32 up 0+02:00:58 16:22:00 % 69 processes: 1 running, 65 sleeping, 3 stopped % CPU states: % user, % nice, % system, % interrupt, % idle % Mem: 117M Active, 211M Inact, 77M Wired, 14M Cache, 54M Buf, 11M Free % Swap: 1535M Total, 4K Used, 1535M Free % % PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND % 662 keramida 1 96 0 84584K 29864K select 1:08 0.00% 0.00% Xorg % 16554 keramida 4 20 0 50136K 38240K kserel 0:40 0.00% 0.00% mozilla-bin % 700 keramida 1 96 0 6012K 4440K select 0:25 0.00% 0.00% xterm-static % 711 root 1 96 0 3368K 2864K select 0:13 0.00% 0.00% screen % 718 keramida 1 96 0 5348K 3772K select 0:10 0.00% 0.00% xterm-static % 691 keramida 1 96 0 6896K 4920K select 0:09 0.00% 0.00% wmaker The sprintf() calls near the end of format_next_process() are duplicated, which is ugly as hell, but I couldn't find a good way to avoid the code duplication. If people don't have a problem with constantly displaying this column, even when no threads are used, this will be even easier to do without the extra clutter. Then, we can add a sort function to order by number of threads and then I think we're pretty much done :-) %%% Index: contrib/top/top.c =================================================================== RCS file: /home/ncvs/src/contrib/top/top.c,v retrieving revision 1.15 diff -u -r1.15 top.c --- contrib/top/top.c 16 Aug 2004 07:51:21 -0000 1.15 +++ contrib/top/top.c 13 Apr 2005 12:56:10 -0000 @@ -84,6 +84,7 @@ static int max_topn; /* maximum displayable processes */ /* miscellaneous things */ +struct process_select ps; char *myname = "top"; jmp_buf jmp_int; @@ -179,7 +180,6 @@ char *iptr; char no_command = 1; struct timeval timeout; - struct process_select ps; #ifdef ORDER char *order_name = NULL; int order_index = 0; @@ -987,8 +987,10 @@ case CMD_thrtog: ps.thread = !ps.thread; new_message(MT_standout | MT_delayed, - " %sisplaying threads.", - ps.thread ? "D" : "Not d"); + "Displaying threads %s", + ps.thread ? "separately" : "as a count"); + header_text = format_header(uname_field); + reset_display(); putchar('\r'); break; case CMD_viewtog: Index: usr.bin/top/machine.c =================================================================== RCS file: /home/ncvs/src/usr.bin/top/machine.c,v retrieving revision 1.69 diff -u -r1.69 machine.c --- usr.bin/top/machine.c 4 Apr 2005 21:19:48 -0000 1.69 +++ usr.bin/top/machine.c 13 Apr 2005 13:18:45 -0000 @@ -55,6 +55,7 @@ #define GETSYSCTL(name, var) getsysctl(name, &(var), sizeof(var)) +extern struct process_select ps; extern char* printable(char *); int swapmode(int *retavail, int *retfree); static int smpmode; @@ -101,18 +102,25 @@ #define io_Proc_format \ "%5d %-*.*s %6ld %6ld %6ld %6ld %6ld %6ld %6.2f%% %.*s" +static char smp_header_thr[] = + " PID %-*.*s THR PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND"; static char smp_header[] = - " PID %-*.*s PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND"; + " PID %-*.*s " "PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND"; +#define smp_Proc_format_thr \ + "%5d %-*.*s %3d %3d %4d%7s %6s %-6.6s %1x%7s %5.2f%% %5.2f%% %.*s" #define smp_Proc_format \ - "%5d %-*.*s %3d %4d%7s %6s %-6.6s %1x%7s %5.2f%% %5.2f%% %.*s" + "%5d %-*.*s %s%3d %4d%7s %6s %-6.6s %1x%7s %5.2f%% %5.2f%% %.*s" +static char up_header_thr[] = + " PID %-*.*s THR PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND"; static char up_header[] = - " PID %-*.*s PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND"; + " PID %-*.*s " "PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND"; +#define up_Proc_format_thr \ + "%5d %-*.*s %3d %3d %4d%7s %6s %-6.6s%.0d%7s %5.2f%% %5.2f%% %.*s" #define up_Proc_format \ - "%5d %-*.*s %3d %4d%7s %6s %-6.6s%.0d%7s %5.2f%% %5.2f%% %.*s" - + "%5d %-*.*s %s%3d %4d%7s %6s %-6.6s%.0d%7s %5.2f%% %5.2f%% %.*s" /* process state names for the "STATE" column of the display */ @@ -286,7 +294,15 @@ switch (displaymode) { case DISP_CPU: - prehead = smpmode ? smp_header : up_header; + /* + * The logic of picking the right header format seems reverse + * here because we only want to display a THR column when + * "thread mode" is off (and threads are not listed as + * separate lines). + */ + prehead = smpmode ? + (ps.thread ? smp_header : smp_header_thr) : + (ps.thread ? up_header : up_header_thr); break; case DISP_IO: prehead = io_header; @@ -646,6 +662,7 @@ int state; struct rusage ru, *rup; long p_tot, s_tot; + char *proc_fmt; /* find and remember the next proc structure */ hp = (struct handle *)handle; @@ -737,12 +754,48 @@ printable(pp->ki_comm)); return (fmt); } + /* format this entry */ - sprintf(fmt, - smpmode ? smp_Proc_format : up_Proc_format, + proc_fmt = smpmode ? + (ps.thread ? smp_Proc_format : smp_Proc_format_thr) : + (ps.thread ? up_Proc_format : up_Proc_format_thr); + + if (ps.thread) { + sprintf(fmt, proc_fmt, + pp->ki_pid, + namelength, namelength, + (*get_userid)(pp->ki_ruid), + "", + pp->ki_pri.pri_level - PZERO, + + /* + * normal time -> nice value -20 - +20 + * real time 0 - 31 -> nice value -52 - -21 + * idle time 0 - 31 -> nice value +21 - +52 + */ + (pp->ki_pri.pri_class == PRI_TIMESHARE ? + pp->ki_nice - NZERO : + (PRI_IS_REALTIME(pp->ki_pri.pri_class) ? + (PRIO_MIN - 1 - (PRI_MAX_REALTIME - pp->ki_pri.pri_level)) : + (PRIO_MAX + 1 + pp->ki_pri.pri_level - PRI_MIN_IDLE))), + format_k2(PROCSIZE(pp)), + format_k2(pagetok(pp->ki_rssize)), + status, + smpmode ? pp->ki_lastcpu : 0, + format_time(cputime), + 100.0 * weighted_cpu(pct, pp), + 100.0 * pct, + screen_width > cmdlengthdelta ? + screen_width - cmdlengthdelta : + 0, + printable(pp->ki_comm)); + return (fmt); + } + sprintf(fmt, proc_fmt, pp->ki_pid, namelength, namelength, (*get_userid)(pp->ki_ruid), + pp->ki_numthreads, pp->ki_pri.pri_level - PZERO, /* %%% From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 13:40:52 2005 Return-Path: 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 1F0DD16A4CE; Wed, 13 Apr 2005 13:40:52 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD1E043D54; Wed, 13 Apr 2005 13:40:51 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j3DDel1D058887; Wed, 13 Apr 2005 13:40:49 GMT (envelope-from davidxu@freebsd.org) Message-ID: <425D2163.4090603@freebsd.org> Date: Wed, 13 Apr 2005 21:40:51 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.5) Gecko/20050402 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Giorgos Keramidas References: <425CC7F8.3030803@samsco.org> <425CD009.6040208@freebsd.org> <20050413132603.GA39006@orion.daedalusnetworks.priv> In-Reply-To: <20050413132603.GA39006@orion.daedalusnetworks.priv> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: Jiawei Ye Subject: Re: How does one know how many thread a process owns? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 13:40:52 -0000 Giorgos Keramidas wrote: >On 2005-04-13 17:15, Jiawei Ye wrote: > > >>On 4/13/05, David Xu wrote: >> >> >>>I believe he wants to see total threads number in a process. add a column >>>to top to display total kernel threads in per-process, p_numthreads in proc >>>structure is what you need . :) >>> >>>David Xu >>> >>> >>Exactly what I want. Is is possible to modify our top? >> >> > >Can you try the following patch? > >I've added a THR column when top displays only one line per process. >So when the "display each thread separately" mode is off, you should see >something like this: > >% last pid: 39064; load averages: 0.08, 0.05, 0.32 up 0+02:00:58 16:22:00 >% 69 processes: 1 running, 65 sleeping, 3 stopped >% CPU states: % user, % nice, % system, % interrupt, % idle >% Mem: 117M Active, 211M Inact, 77M Wired, 14M Cache, 54M Buf, 11M Free >% Swap: 1535M Total, 4K Used, 1535M Free >% >% PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND >% 662 keramida 1 96 0 84584K 29864K select 1:08 0.00% 0.00% Xorg >% 16554 keramida 4 20 0 50136K 38240K kserel 0:40 0.00% 0.00% mozilla-bin >% 700 keramida 1 96 0 6012K 4440K select 0:25 0.00% 0.00% xterm-static >% 711 root 1 96 0 3368K 2864K select 0:13 0.00% 0.00% screen >% 718 keramida 1 96 0 5348K 3772K select 0:10 0.00% 0.00% xterm-static >% 691 keramida 1 96 0 6896K 4920K select 0:09 0.00% 0.00% wmaker > >The sprintf() calls near the end of format_next_process() are duplicated, >which is ugly as hell, but I couldn't find a good way to avoid the code >duplication. If people don't have a problem with constantly displaying this >column, even when no threads are used, this will be even easier to do without >the extra clutter. Then, we can add a sort function to order by number of >threads and then I think we're pretty much done :-) > > I am using the patch, it works fine, the screen output is attractive. :-) From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 14:08:41 2005 Return-Path: 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 6DACA16A4CE; Wed, 13 Apr 2005 14:08:41 +0000 (GMT) Received: from renaissance.homeip.net (m197.net81-67-151.noos.fr [81.67.151.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57DB143D46; Wed, 13 Apr 2005 14:08:40 +0000 (GMT) (envelope-from anthony.ginepro@laposte.net) Received: from renaissance.homeip.net (localhost [127.0.0.1]) by renaissance.homeip.net (Postfix) with ESMTP id 3358821F4; Wed, 13 Apr 2005 16:08:39 +0200 (CEST) Received: (from rapiere@localhost) by renaissance.homeip.net (8.13.3/8.13.1/Submit) id j3DE8crq077228; Wed, 13 Apr 2005 16:08:38 +0200 (CEST) (envelope-from anthony.ginepro@laposte.net) X-Authentication-Warning: renaissance.homeip.net: rapiere set sender to anthony.ginepro@laposte.net using -f Date: Wed, 13 Apr 2005 16:08:38 +0200 From: Anthony Ginepro To: David Xu Message-ID: <20050413140838.GA77217@renaissance.homeip.net> References: <425CC7F8.3030803@samsco.org> <425CD009.6040208@freebsd.org> <20050413132603.GA39006@orion.daedalusnetworks.priv> <425D2163.4090603@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <425D2163.4090603@freebsd.org> X-Operating-System: FreeBSD 5.4-STABLE i386 User-Agent: Mutt/1.5.9i cc: freebsd-current@freebsd.org cc: Giorgos Keramidas cc: Jiawei Ye Subject: Re: How does one know how many thread a process owns? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 14:08:41 -0000 On 04/13/05 21:40, David Xu wrote: > Giorgos Keramidas wrote: > > >On 2005-04-13 17:15, Jiawei Ye wrote: > > > > > >>On 4/13/05, David Xu wrote: > >> > >> > >>>I believe he wants to see total threads number in a process. add a column > >>>to top to display total kernel threads in per-process, p_numthreads in > >>>proc > >>>structure is what you need . :) > >>> > >>>David Xu > >>> > >>> > >>Exactly what I want. Is is possible to modify our top? > >> > >> > > > >Can you try the following patch? > > > >I've added a THR column when top displays only one line per process. > >So when the "display each thread separately" mode is off, you should see > >something like this: > > > >% last pid: 39064; load averages: 0.08, 0.05, 0.32 up 0+02:00:58 > >16:22:00 > >% 69 processes: 1 running, 65 sleeping, 3 stopped > >% CPU states: % user, % nice, % system, % interrupt, % > >idle > >% Mem: 117M Active, 211M Inact, 77M Wired, 14M Cache, 54M Buf, 11M Free > >% Swap: 1535M Total, 4K Used, 1535M Free > >% > >% PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU CPU > >COMMAND > >% 662 keramida 1 96 0 84584K 29864K select 1:08 0.00% 0.00% > >Xorg > >% 16554 keramida 4 20 0 50136K 38240K kserel 0:40 0.00% 0.00% > >mozilla-bin > >% 700 keramida 1 96 0 6012K 4440K select 0:25 0.00% 0.00% > >xterm-static > >% 711 root 1 96 0 3368K 2864K select 0:13 0.00% 0.00% > >screen > >% 718 keramida 1 96 0 5348K 3772K select 0:10 0.00% 0.00% > >xterm-static > >% 691 keramida 1 96 0 6896K 4920K select 0:09 0.00% 0.00% > >wmaker > > > >The sprintf() calls near the end of format_next_process() are duplicated, > >which is ugly as hell, but I couldn't find a good way to avoid the code > >duplication. If people don't have a problem with constantly displaying > >this > >column, even when no threads are used, this will be even easier to do > >without > >the extra clutter. Then, we can add a sort function to order by number of > >threads and then I think we're pretty much done :-) > > > > > I am using the patch, it works fine, the screen output is attractive. :-) Except for WCPU it looks like SunOS' top. From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 14:13:28 2005 Return-Path: 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 B5F3416A4CE; Wed, 13 Apr 2005 14:13:28 +0000 (GMT) Received: from rosebud.otenet.gr (rosebud.otenet.gr [195.170.0.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0C7343D3F; Wed, 13 Apr 2005 14:13:27 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from orion.daedalusnetworks.priv (aris.bedc.ondsl.gr [62.103.39.226])j3DECQu4012511; Wed, 13 Apr 2005 17:12:26 +0300 Received: from orion.daedalusnetworks.priv (orion [127.0.0.1]) j3DEDPw7040474; Wed, 13 Apr 2005 17:13:25 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost)j3DEDPPT040473; Wed, 13 Apr 2005 17:13:25 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Wed, 13 Apr 2005 17:13:25 +0300 From: Giorgos Keramidas To: David Xu Message-ID: <20050413141325.GA40387@orion.daedalusnetworks.priv> References: <425CC7F8.3030803@samsco.org> <425CD009.6040208@freebsd.org> <20050413132603.GA39006@orion.daedalusnetworks.priv> <425D2163.4090603@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <425D2163.4090603@freebsd.org> cc: freebsd-current@freebsd.org cc: Jiawei Ye Subject: Re: How does one know how many thread a process owns? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 14:13:28 -0000 On 2005-04-13 21:40, David Xu wrote: >Giorgos Keramidas wrote: >>On 2005-04-13 17:15, Jiawei Ye wrote: >>>On 4/13/05, David Xu wrote: >>>> I believe he wants to see total threads number in a process. add a >>>> column to top to display total kernel threads in per-process, >>>> p_numthreads in proc structure is what you need . :) >>> >>> Exactly what I want. Is is possible to modify our top? >> >>Can you try the following patch? >>[snip] > > I am using the patch, it works fine, the screen output is attractive. :-) Would it be ok if I modified it to constantly display the THR column in process-mode, to avoid duplicating the large sprintf() part of format_next_process? I really dislike having to include virtually the same sprintf() block twice, just to change a single field. Constantly displaying THR, even when there are no multithreaded programs running on a system is not optimal either, but it's better IMO. Ideally, the displayed fields and their width could be dynamically adjustable, with contrib/top code formatting the displayed "screen" in a string buffer and using something like: struct top_field { int tf_enabled; int tf_width; int tf_precision; char *tf_fmt; char *tf_header; }; struct top_field top_fields[] = { { 1, 5, 0, "s", "PID", }, { 1, 8, 0, "s", "USERNAME", }, { 0, 5, 0, "ld", "UID", }, { 1, 3, 0, "ld", "PRI", } ... }; and the field formatting code could iterate through an array of fields, printing or ignoring some fields based on the current flags of top (thread mode, smp mode, etc), but this requires huge changes to the way contrib/top is written and I don't think I have so much time right now. From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 14:20:00 2005 Return-Path: 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 090FA16A4CE; Wed, 13 Apr 2005 14:20:00 +0000 (GMT) Received: from kane.otenet.gr (kane.otenet.gr [195.170.0.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A24C43D31; Wed, 13 Apr 2005 14:19:59 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from orion.daedalusnetworks.priv (aris.bedc.ondsl.gr [62.103.39.226])j3DEIu8B025610; Wed, 13 Apr 2005 17:18:56 +0300 Received: from orion.daedalusnetworks.priv (orion [127.0.0.1]) j3DEJvuw040572; Wed, 13 Apr 2005 17:19:57 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost)j3DEJvUk040571; Wed, 13 Apr 2005 17:19:57 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Wed, 13 Apr 2005 17:19:57 +0300 From: Giorgos Keramidas To: Anthony Ginepro Message-ID: <20050413141957.GA40546@orion.daedalusnetworks.priv> References: <425CC7F8.3030803@samsco.org> <425CD009.6040208@freebsd.org> <20050413132603.GA39006@orion.daedalusnetworks.priv> <425D2163.4090603@freebsd.org> <20050413140838.GA77217@renaissance.homeip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050413140838.GA77217@renaissance.homeip.net> cc: freebsd-current@freebsd.org cc: David Xu cc: Jiawei Ye Subject: Re: How does one know how many thread a process owns? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 14:20:00 -0000 On 2005-04-13 16:08, Anthony Ginepro wrote: >On 04/13/05 21:40, David Xu wrote: >>Giorgos Keramidas wrote: >>> Can you try the following patch? >> >> I am using the patch, it works fine, the screen output is attractive. :-) > > Except for WCPU it looks like SunOS' top. /me thinks (Oops, they caught me!) Yes, I have to admit, I used the output of SunOS top as an inspiration for the ordering and naming of the THR column :-) From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 15:25:18 2005 Return-Path: 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 14BBD16A4CF for ; Wed, 13 Apr 2005 15:25:18 +0000 (GMT) Received: from smtp103.rog.mail.re2.yahoo.com (smtp103.rog.mail.re2.yahoo.com [206.190.36.81]) by mx1.FreeBSD.org (Postfix) with SMTP id 6BC5143D5F for ; Wed, 13 Apr 2005 15:25:17 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from unknown (HELO 172.16.0.1) (mikej@69.193.222.195 with login) by smtp103.rog.mail.re2.yahoo.com with SMTP; 13 Apr 2005 15:25:16 -0000 Received: from 172.16.0.199 (SquirrelMail authenticated user mikej) by 172.16.0.1 with HTTP; Wed, 13 Apr 2005 11:25:11 -0400 (EDT) Message-ID: <2626.172.16.0.199.1113405911.squirrel@172.16.0.1> In-Reply-To: <200504130908.20519.andy@athame.co.uk> References: <20050413032631.53069.qmail@web54006.mail.yahoo.com> <200504130908.20519.andy@athame.co.uk> Date: Wed, 13 Apr 2005 11:25:11 -0400 (EDT) From: "Mike Jakubik" To: "Andy Fawcett" User-Agent: SquirrelMail/1.5.1 [CVS] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit cc: Rob cc: freebsd-current@freebsd.org Subject: Re: xl(4) & polling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 15:25:18 -0000 On Wed, April 13, 2005 2:08 am, Andy Fawcett said: >> xl1: transmission error: 90 >> xl1: tx underrun, increasing tx start threshold >> to 120 bytes > > FWIW, I see these on my firewall box with a pair of xl cards, even > without the polling patch. They've been showing up on and off since about > 5.3-RELEASE, > and usually only during the first day after a reboot. I get these too, on a 3Com 3c905C-TX. I have gotten these for ages, so its nothing new. Either the driver is really screwed up, or these cards come with defaults that are too low. From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 19:16:26 2005 Return-Path: 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 8735A16A4CF for ; Tue, 12 Apr 2005 19:16:26 +0000 (GMT) Received: from email.aon.at (warsl404pip8.highway.telekom.at [195.3.96.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53C4343D54 for ; Tue, 12 Apr 2005 19:16:25 +0000 (GMT) (envelope-from c47g@gmx.at) Received: (qmail 17142 invoked from network); 12 Apr 2005 19:16:22 -0000 Received: from n722p000.adsl.highway.telekom.at (HELO bones) ([62.47.34.32]) (envelope-sender ) by smarthub75.highway.telekom.at (qmail-ldap-1.03) with SMTP for ; 12 Apr 2005 19:16:22 -0000 From: Christian Gusenbauer To: freebsd-multimedia@freebsd.org Date: Tue, 12 Apr 2005 21:15:47 +0200 User-Agent: KMail/1.7.2 References: <425C18A2.8010807@elischer.org> In-Reply-To: <425C18A2.8010807@elischer.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2369540.LkQ6TM7h55"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504122115.58498.c47g@gmx.at> X-Mailman-Approved-At: Wed, 13 Apr 2005 15:55:49 +0000 cc: freebsd-current@freebsd.org cc: julian@elischer.org Subject: Re: Anyone working on V4L2 for BSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 12 Apr 2005 19:16:26 -0000 --nextPart2369540.LkQ6TM7h55 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Julian! I played a bit with it 3 years ago. I managed to get the radio part working= ,=20 but then I had no time left to do the rest :-(. If you want, I can send you= =20 my sources. Ciao, Christian. On Tuesday, 12. April 2005 20:51, Julian Elischer wrote: > I'm considerring it.. It looks quite doable. (assuming we can get > compatible include files > without copyright problems.) > > For compatibility we'd probably want to keep all the V4L prefixes etc. > > Is anyone else playing with this? > > I remember someone said they had implemented > part of the interface for some specific device recently. > > > Julian > > _______________________________________________ > freebsd-multimedia@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-multimedia > To unsubscribe, send any mail to > "freebsd-multimedia-unsubscribe@freebsd.org" --nextPart2369540.LkQ6TM7h55 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCXB5u73Wh/GTgh8wRAuvaAJ93oBoKzhfDJ2eli72g6Fixw4tvYACfeIdl N/VxPqExfr+j3r1GEDX7ooU= =7v5D -----END PGP SIGNATURE----- --nextPart2369540.LkQ6TM7h55-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 19:35:18 2005 Return-Path: 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 751EA16A4CE for ; Tue, 12 Apr 2005 19:35:18 +0000 (GMT) Received: from thor.66h.42h.de (mirsolutions.de [81.169.132.156]) by mx1.FreeBSD.org (Postfix) with ESMTP id 96A7943D4C for ; Tue, 12 Apr 2005 19:35:16 +0000 (GMT) (envelope-from tg@66h.42h.de) Received: from odem.66h.42h.de (root@odem.66h.42h.de [IPv6:2001:6f8:94d:1:2c0:9fff:fe1a:6a01]) by thor.66h.42h.de (8.13.1/8.13.1) with ESMTP id j3CJZBQS006776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Apr 2005 19:35:13 GMT Received: from localhost (tg@localhost [IPv6:::1]) by odem.66h.42h.de (8.13.3/8.13.3) with ESMTP id j3CJZ3LU013866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Apr 2005 19:35:05 GMT Date: Tue, 12 Apr 2005 19:35:03 +0000 (UTC) From: Thorsten Glaser To: freebsd-current@freebsd.org, miros-discuss@mirbsd.org, tech@openbsd.org In-Reply-To: <1113334228.27362.35.camel@localhost.localdomain> Message-ID: References: <1113334228.27362.35.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Wed, 13 Apr 2005 15:55:49 +0000 Subject: Re: strtonum(3) in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 12 Apr 2005 19:35:18 -0000 Dixitur: >> Quick, sort of, question. Is it worth it to bring strtonum(3) from >> OpenBSD into FreeBSD-CURRENT. I have the diffs if that's the case, I >> know that the newer packet filter code from OPENBSD_3_7 that mlaier@ and >> I are working on uses it in a few places (see: pflogd) but I'm not sure >> of the merits of bringing strtonum(3) into lib/libc/stdlib... >> >> In theory, it should be a better implementation of what atoi(3) and >> strtol(3) do, but as tg@(mirbsd.org) pointed out to the OpenBSD fellows >> and myself, it doesn't take hexadecimal values well... >> >> Somebody let me know, i've got diffs ready, sort of ;) >> (or let me know why it's a bad idea) > >The lack of base handling argument does make it less appealing, but now >that OpenBSD has used this name, we're stuck with the API. I would Accepting "0x10" as 16 instead of 0 is no API breakage, it only changes the behaviour. To the good, I might add. I'd suggest to not add octal (010) parsing, because leading zeroes are not totally uncommon in the purely-decimal world. >request that you use intmax_t rather than "long long" for the integers. >Then the API scales cleanly when some future processor adds 128-bit ints. >Since intmax_t is "long long" on all current platforms that wouldn't >cause compatability problems with OpenBSD. I second that. Cc'd to OpenBSD-Tech. Comments? //mirabile From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 19:42:46 2005 Return-Path: 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 D2D4716A4CE for ; Tue, 12 Apr 2005 19:42:46 +0000 (GMT) Received: from cvs.openbsd.org (cvs.openbsd.org [199.185.137.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C58843D5E for ; Tue, 12 Apr 2005 19:42:46 +0000 (GMT) (envelope-from deraadt@cvs.openbsd.org) Received: from cvs.openbsd.org (localhost [127.0.0.1]) by cvs.openbsd.org (8.13.3/8.12.1) with ESMTP id j3CJj3Fr006856; Tue, 12 Apr 2005 13:45:03 -0600 (MDT) Message-Id: <200504121945.j3CJj3Fr006856@cvs.openbsd.org> To: Thorsten Glaser In-reply-to: Your message of "Tue, 12 Apr 2005 19:35:03 -0000." Date: Tue, 12 Apr 2005 13:45:03 -0600 From: Theo de Raadt X-Mailman-Approved-At: Wed, 13 Apr 2005 15:55:49 +0000 cc: miros-discuss@mirbsd.org cc: freebsd-current@freebsd.org cc: tech@openbsd.org Subject: Re: strtonum(3) in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 12 Apr 2005 19:42:46 -0000 > >> Quick, sort of, question. Is it worth it to bring strtonum(3) from > >> OpenBSD into FreeBSD-CURRENT. I have the diffs if that's the case, I > >> know that the newer packet filter code from OPENBSD_3_7 that mlaier@ and > >> I are working on uses it in a few places (see: pflogd) but I'm not sure > >> of the merits of bringing strtonum(3) into lib/libc/stdlib... > >> > >> In theory, it should be a better implementation of what atoi(3) and > >> strtol(3) do, but as tg@(mirbsd.org) pointed out to the OpenBSD fellows > >> and myself, it doesn't take hexadecimal values well... > >> > >> Somebody let me know, i've got diffs ready, sort of ;) > >> (or let me know why it's a bad idea) > > > >The lack of base handling argument does make it less appealing, but now > >that OpenBSD has used this name, we're stuck with the API. I would > > Accepting "0x10" as 16 instead of 0 is no API breakage, > it only changes the behaviour. To the good, I might add. > > I'd suggest to not add octal (010) parsing, because > leading zeroes are not totally uncommon in the > purely-decimal world. > > >request that you use intmax_t rather than "long long" for the integers. > >Then the API scales cleanly when some future processor adds 128-bit ints. > >Since intmax_t is "long long" on all current platforms that wouldn't > >cause compatability problems with OpenBSD. > > I second that. Cc'd to OpenBSD-Tech. Comments? We are not changing it. This API was very carefully chosen so that it is EASY TO USE. People can easily change existing code and use this API to write better code. That is the #1 design decision. If you must deal with octal and hex numbers, do it yourself. This is not the typical case, and we specially avoid handling them to keep this simple. From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 20:08:26 2005 Return-Path: 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 9210816A4CE for ; Tue, 12 Apr 2005 20:08:26 +0000 (GMT) Received: from thor.66h.42h.de (mirsolutions.de [81.169.132.156]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA15F43D5C for ; Tue, 12 Apr 2005 20:08:25 +0000 (GMT) (envelope-from tg@66h.42h.de) Received: from odem.66h.42h.de (root@odem.66h.42h.de [IPv6:2001:6f8:94d:1:2c0:9fff:fe1a:6a01]) by thor.66h.42h.de (8.13.1/8.13.1) with ESMTP id j3CK8LWO015893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 12 Apr 2005 20:08:24 GMT Received: from localhost (tg@localhost [IPv6:::1]) by odem.66h.42h.de (8.13.3/8.13.3) with ESMTP id j3CK8K7U017493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 12 Apr 2005 20:08:20 GMT Date: Tue, 12 Apr 2005 20:08:19 +0000 (UTC) From: Thorsten Glaser To: freebsd-current@freebsd.org In-Reply-To: <1113336183.27362.37.camel@localhost.localdomain> Message-ID: References: <1113336183.27362.37.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Wed, 13 Apr 2005 15:55:49 +0000 Subject: Re: strtonum(3) in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 12 Apr 2005 20:08:26 -0000 Dixitur: >Based on the man page, I see the following deficiencies: >1) No support for bases other than 10 Not having base 16 (sedecimal) support really is why I am still using strtol(l) in my code... >2) No provision to return the end of the converted string >3) No simple way to distinguish errors from a valid zero. The OpenBSD people said (when I proposed to change #1) that they want an uncomplicated interface, and I think #3 is not necessary, and I can live without #2. Just my 0.02 EUR //mirabile From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 20:49:49 2005 Return-Path: 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 77E3816A4CE for ; Tue, 12 Apr 2005 20:49:49 +0000 (GMT) Received: from thor.66h.42h.de (mirsolutions.de [81.169.132.156]) by mx1.FreeBSD.org (Postfix) with ESMTP id 157A043D1F for ; Tue, 12 Apr 2005 20:49:48 +0000 (GMT) (envelope-from tg@66h.42h.de) Received: from odem.66h.42h.de (root@odem.66h.42h.de [IPv6:2001:6f8:94d:1:2c0:9fff:fe1a:6a01]) by thor.66h.42h.de (8.13.1/8.13.1) with ESMTP id j3CKng1n026665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Apr 2005 20:49:45 GMT Received: from localhost (tg@localhost [IPv6:::1]) by odem.66h.42h.de (8.13.3/8.13.3) with ESMTP id j3CKneA1018980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Apr 2005 20:49:41 GMT Date: Tue, 12 Apr 2005 20:49:39 +0000 (UTC) From: Thorsten Glaser In-Reply-To: <200504121945.j3CJj3Fr006856@cvs.openbsd.org> Message-ID: References: <200504121945.j3CJj3Fr006856@cvs.openbsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Wed, 13 Apr 2005 15:55:49 +0000 cc: miros-discuss@mirbsd.org cc: freebsd-current@freebsd.org cc: tech@openbsd.org Subject: Re: strtonum(3) in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 12 Apr 2005 20:49:49 -0000 Theo de Raadt dixit: >> >request that you use intmax_t rather than "long long" for the integers. >> >Then the API scales cleanly when some future processor adds 128-bit ints. >> >Since intmax_t is "long long" on all current platforms that wouldn't >> >cause compatability problems with OpenBSD. >> >> I second that. Cc'd to OpenBSD-Tech. Comments? >If you must deal with octal and hex numbers, do it yourself. This is >not the typical case, and we specially avoid handling them to keep >this simple. You already said that, but what about using intmax_t as return type? //mirabile From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 21:11:56 2005 Return-Path: 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 990AF16A4CE for ; Tue, 12 Apr 2005 21:11:56 +0000 (GMT) Received: from cvs.openbsd.org (cvs.openbsd.org [199.185.137.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B24C43D49 for ; Tue, 12 Apr 2005 21:11:56 +0000 (GMT) (envelope-from deraadt@cvs.openbsd.org) Received: from cvs.openbsd.org (localhost [127.0.0.1]) by cvs.openbsd.org (8.13.3/8.12.1) with ESMTP id j3CLE7Ea013181; Tue, 12 Apr 2005 15:14:07 -0600 (MDT) Message-Id: <200504122114.j3CLE7Ea013181@cvs.openbsd.org> To: Thorsten Glaser In-reply-to: Your message of "Tue, 12 Apr 2005 20:49:39 -0000." Date: Tue, 12 Apr 2005 15:14:07 -0600 From: Theo de Raadt X-Mailman-Approved-At: Wed, 13 Apr 2005 15:55:49 +0000 cc: miros-discuss@mirbsd.org cc: freebsd-current@freebsd.org cc: tech@openbsd.org Subject: Re: strtonum(3) in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 12 Apr 2005 21:11:56 -0000 > >> >request that you use intmax_t rather than "long long" for the integers. > >> >Then the API scales cleanly when some future processor adds 128-bit ints. > >> >Since intmax_t is "long long" on all current platforms that wouldn't > >> >cause compatability problems with OpenBSD. > >> > >> I second that. Cc'd to OpenBSD-Tech. Comments? > > >If you must deal with octal and hex numbers, do it yourself. This is > >not the typical case, and we specially avoid handling them to keep > >this simple. > > You already said that, but what about using intmax_t as return type? No. From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 02:18:28 2005 Return-Path: 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 8DB9716A4CE; Wed, 13 Apr 2005 02:18:28 +0000 (GMT) Received: from feith1.FEITH.COM (feith1.FEITH.COM [192.251.93.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3674643D58; Wed, 13 Apr 2005 02:18:28 +0000 (GMT) (envelope-from john@feith.com) Received: from jwlab.FEITH.COM (jwlab.FEITH.COM [192.251.93.16]) by feith1.FEITH.COM (8.12.10+Sun/8.12.9) with ESMTP id j3D2IKBP014340; Tue, 12 Apr 2005 22:18:20 -0400 (EDT) Received: from jwlab.FEITH.COM (localhost [127.0.0.1]) by jwlab.FEITH.COM (8.12.10+Sun/8.12.10) with ESMTP id j3D2IK52003142; Tue, 12 Apr 2005 22:18:20 -0400 (EDT) Received: (from john@localhost) by jwlab.FEITH.COM (8.12.10+Sun/8.12.10/Submit) id j3D2IGEK003141; Tue, 12 Apr 2005 22:18:16 -0400 (EDT) Date: Tue, 12 Apr 2005 22:18:16 -0400 (EDT) From: John Wehle Message-Id: <200504130218.j3D2IGEK003141@jwlab.FEITH.COM> To: multimedia@freebsd.org Content-Type: text X-Scanned-By: MIMEDefang 2.48 on 192.251.93.1 X-Archived: cashew.FEITH.COM X-Mailman-Approved-At: Wed, 13 Apr 2005 15:55:49 +0000 cc: freebsd-current@freebsd.org cc: julian@elischer.org Subject: Re: Anyone working on V4L2 for BSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 02:18:28 -0000 > Is anyone else playing with this? > > I remember someone said they had implemented > part of the interface for some specific device recently. I believe Stacey Son hacked in some support to my cxm driver for the Hauppauge PVR-250 / PVR-350. I've been lightly debating what to do about adding support ... if there was an official FreeBSD framework, then I'd be happy to update the cxm driver to interfaced with it. -- John ------------------------------------------------------------------------- | Feith Systems | Voice: 1-215-646-8000 | Email: john@feith.com | | John Wehle | Fax: 1-215-540-5495 | | ------------------------------------------------------------------------- From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 03:20:15 2005 Return-Path: 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 23FA016A4D0; Wed, 13 Apr 2005 03:20:15 +0000 (GMT) Received: from tamu-relay.tamu.edu (smtp-relay.tamu.edu [165.91.143.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79D3A43D48; Wed, 13 Apr 2005 03:20:14 +0000 (GMT) (envelope-from tyler@neo.tamu.edu) Received: from xyzzy-4.tamu.edu (xyzzy-4.tamu.edu [165.91.22.28]) by tamu-relay.tamu.edu (8.12.10/8.12.10) with ESMTP id j3D3KAhN000747; Tue, 12 Apr 2005 22:20:11 -0500 (CDT) Received: from neo.tamu.edu (localhost.tamu.edu [127.0.0.1]) by xyzzy-4.tamu.edu (8.12.9/8.12.9) with SMTP id j3D3KAsC013538; Tue, 12 Apr 2005 22:20:10 -0500 (CDT) (envelope-from tyler@neo.tamu.edu) Message-Id: <200504130320.j3D3KAsC013538@xyzzy-4.tamu.edu> Date: Wed, 13 Apr 2005 03:20:10 -0000 To: "David Schultz" From: "Ballance, Robert T" X-Mailer: TWIG 2.6.2 In-Reply-To: <20050413030814.GA21318@VARK.MIT.EDU> X-Client-IP: X-Mailman-Approved-At: Wed, 13 Apr 2005 15:55:49 +0000 cc: FreeBSD Current Subject: Re: strtonum(3) in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: tyler@neo.tamu.edu List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 03:20:15 -0000 > > Based on the man page, I see the following deficiencies: > > 1) No support for bases other than 10 > > 2) No provision to return the end of the converted string > > 3) No simple way to distinguish errors from a valid zero. > > It actually has a sensible way of distinguishing errors (it always > sets errno, even if to 0), but this is unintuitive to anyone who > is used to the broken POSIX way of doing it. It's a nice attempt, > but consistency is important, too. So unless we really need it, I > would vote against it as well. I agree with both of the latter two problems...I am wondering if it'd be possible to talk to Theo about changing strtonum(3) in OpenBSD as well...we (the MirOS Project) asked Theo about the intmax_t idea, and he simply replied "No" (in classic Theo fashion, sans flames) Having no way to distinguish a valid zero is slightly retarded; in general, I think it's a decent idea, but needs some polishing up. I'm not pushing real hard for it though, since some other utilities exist (atoi(), strtol(), etc), but it would be something handy to have around... -R. Tyler Ballance From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 03:28:28 2005 Return-Path: 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 9ED3B16A4CE for ; Wed, 13 Apr 2005 03:28:28 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39AF743D54 for ; Wed, 13 Apr 2005 03:28:28 +0000 (GMT) (envelope-from kabaev@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so44060rng for ; Tue, 12 Apr 2005 20:28:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type:content-transfer-encoding; b=JgSWvRFmt1bRzUoj19V61e0oXpDgSz7beW2KYK6ElbNAU6yZ4hoWU8WacpMcdu3gaakvrrmYFFsxOAIGmFQF8EsPTzCQPvQTdzzokpElOtBWtHbbuBAwNXjYgRvJ+C5LCVb9b+Xwzc680e1CPKuMIO3H/BtzOrBea4fnJ7eG79s= Received: by 10.38.86.53 with SMTP id j53mr184753rnb; Tue, 12 Apr 2005 20:28:27 -0700 (PDT) Received: from kan.dnsalias.net ([151.203.236.228]) by mx.gmail.com with ESMTP id r34sm393906rna.2005.04.12.20.28.27; Tue, 12 Apr 2005 20:28:27 -0700 (PDT) Date: Tue, 12 Apr 2005 23:28:26 -0400 From: Alexander Kabaev To: current@FreeBSD.org Message-ID: <20050412232826.6c73bf0e@kan.dnsalias.net> In-Reply-To: <0842a01b5aa0cfcd84763fff4a30113e@FreeBSD.org> References: <0842a01b5aa0cfcd84763fff4a30113e@FreeBSD.org> X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 13 Apr 2005 15:55:49 +0000 Subject: Re: [PATCH] Allow watching of vnodes that reside on non-UFS filesystems with kqueue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 03:28:28 -0000 On Tue, 12 Apr 2005 23:05:45 -0400 Suleiman Souhlal wrote: > Hello, > > The patch at > http://people.freebsd.org/~ssouhlal/testing/kqueue-hooks-20050412.diff > > allows watching vnodes on non-UFS filesystems with kqueue. > > It moves the VN_KNOTE calls to pre and post VOP_* hooks. These hooks > are currently used for VFS lock debugging only, but I made them > unconditional. I think that they we could eventually move the > mac_check_vnode_* calls into them too, with a bit of work. > > I would like to commit this to HEAD, if there are no objections. I for one am not thrilled by all the hooks being made unconditional and being inserted right into the middle of critical path for the benefit of rarely used feature. -- Alexander Kabaev From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 03:28:44 2005 Return-Path: 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 E1DDE16A4CE for ; Wed, 13 Apr 2005 03:28:44 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7AD7643D1D for ; Wed, 13 Apr 2005 03:28:44 +0000 (GMT) (envelope-from kabaev@gmail.com) Received: by rproxy.gmail.com with SMTP id j1so36035rnf for ; Tue, 12 Apr 2005 20:28:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type:content-transfer-encoding; b=VSBFm7mXqF2fjYs8DRcv5Gd9EEjw0D+ddGd54XcMf7RybTT2dUSCApOT5OGaMgzYNTZF39dFksq2OV52ZAuf4aL7He7gaV33d/7JruyEJV08YrQW2pqBKu+ugfdVVSkAGlGDRU4aEAaKKpBMc6q8J8YE+ZjidPqSKwxXjUgB1aM= Received: by 10.38.82.20 with SMTP id f20mr172068rnb; Tue, 12 Apr 2005 20:28:44 -0700 (PDT) Received: from kan.dnsalias.net ([151.203.236.228]) by mx.gmail.com with ESMTP id 3sm3375rnr.2005.04.12.20.28.43; Tue, 12 Apr 2005 20:28:44 -0700 (PDT) Date: Tue, 12 Apr 2005 23:28:41 -0400 From: Alexander Kabaev To: current@FreeBSD.org Message-ID: <20050412232841.230467c2@kan.dnsalias.net> In-Reply-To: <0842a01b5aa0cfcd84763fff4a30113e@FreeBSD.org> References: <0842a01b5aa0cfcd84763fff4a30113e@FreeBSD.org> X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 13 Apr 2005 15:55:49 +0000 Subject: Re: [PATCH] Allow watching of vnodes that reside on non-UFS filesystems with kqueue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 03:28:45 -0000 On Tue, 12 Apr 2005 23:05:45 -0400 Suleiman Souhlal wrote: > Hello, > > The patch at > http://people.freebsd.org/~ssouhlal/testing/kqueue-hooks-20050412.diff > > allows watching vnodes on non-UFS filesystems with kqueue. > > It moves the VN_KNOTE calls to pre and post VOP_* hooks. These hooks > are currently used for VFS lock debugging only, but I made them > unconditional. I think that they we could eventually move the > mac_check_vnode_* calls into them too, with a bit of work. > > I would like to commit this to HEAD, if there are no objections. I for one am not thrilled by all the hooks being made unconditional and being inserted right into the middle of critical path for the benefit of rarely used feature. -- Alexander Kabaev From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 16:25:18 2005 Return-Path: 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 3E37016A4CE; Wed, 13 Apr 2005 16:25:18 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01C9743D69; Wed, 13 Apr 2005 16:25:16 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id B85107A427; Wed, 13 Apr 2005 09:25:15 -0700 (PDT) Message-ID: <425C7BE2.3060904@elischer.org> Date: Tue, 12 Apr 2005 18:54:42 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en, hu MIME-Version: 1.0 To: John Wehle References: <200504130218.j3D2IGEK003141@jwlab.FEITH.COM> In-Reply-To: <200504130218.j3D2IGEK003141@jwlab.FEITH.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: multimedia@freebsd.org Subject: Re: Anyone working on V4L2 for BSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 16:25:18 -0000 John Wehle wrote: >>Is anyone else playing with this? >> >>I remember someone said they had implemented >>part of the interface for some specific device recently. >> >> > >I believe Stacey Son hacked in some support to >my cxm driver for the Hauppauge PVR-250 / PVR-350. > >I've been lightly debating what to do about adding support ... >if there was an official FreeBSD framework, then I'd be happy to >update the cxm driver to interfaced with it. > > There are two interfaces that we can consider.. The X11R6 Xvideo interface (about which I know very little) and V4L(2). There is however a shim that allows Xvideo to talk to L4V so I think we should look at making hte devices L4V compliant. I just got permission from the original author of the L4V interface to copy the include file verbatim should we like. >-- John >------------------------------------------------------------------------- >| Feith Systems | Voice: 1-215-646-8000 | Email: john@feith.com | >| John Wehle | Fax: 1-215-540-5495 | | >------------------------------------------------------------------------- > > > >------------------------------------------------------------------------ > >_______________________________________________ >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 Wed Apr 13 16:27:15 2005 Return-Path: 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 D34D916A4CE for ; Wed, 13 Apr 2005 16:27:15 +0000 (GMT) Received: from sp.dominia.org (efnet-math.org [69.60.109.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id 341FA43D6B for ; Wed, 13 Apr 2005 16:27:15 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from [198.82.174.233] (hc652aee9.dhcp.vt.edu [198.82.174.233]) (authenticated bits=0) by sp.dominia.org (8.13.1/8.13.1) with ESMTP id j3DGRCu9009246 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 13 Apr 2005 12:27:13 -0400 In-Reply-To: <20050412232841.230467c2@kan.dnsalias.net> References: <0842a01b5aa0cfcd84763fff4a30113e@FreeBSD.org> <20050412232841.230467c2@kan.dnsalias.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Suleiman Souhlal Date: Wed, 13 Apr 2005 12:27:11 -0400 To: Alexander Kabaev X-Mailer: Apple Mail (2.619.2) cc: current@FreeBSD.org Subject: Re: [PATCH] Allow watching of vnodes that reside on non-UFS filesystems with kqueue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 16:27:15 -0000 Hi, On Apr 12, 2005, at 11:28 PM, Alexander Kabaev wrote: > I for one am not thrilled by all the hooks being made unconditional and > being inserted right into the middle of critical path for the benefit > of > rarely used feature. I don't think there is actually any cost. The hooks are only used when they are actually 'declared' in vnode_if.src, and they could very well get inlined by the compiler. -- Suleiman Souhlal | ssouhlal@vt.edu The FreeBSD Project | ssouhlal@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 16:30:14 2005 Return-Path: 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 786F316A4CE; Wed, 13 Apr 2005 16:30:14 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49ECF43D69; Wed, 13 Apr 2005 16:30:14 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 36D3D7A427; Wed, 13 Apr 2005 09:30:14 -0700 (PDT) Message-ID: <425C7D0D.5000302@elischer.org> Date: Tue, 12 Apr 2005 18:59:41 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en, hu MIME-Version: 1.0 To: David Xu References: <425CC7F8.3030803@samsco.org> <425CD009.6040208@freebsd.org> <20050413132603.GA39006@orion.daedalusnetworks.priv> <425D2163.4090603@freebsd.org> In-Reply-To: <425D2163.4090603@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: Giorgos Keramidas cc: Jiawei Ye Subject: Re: How does one know how many thread a process owns? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 16:30:14 -0000 David Xu wrote: > Giorgos Keramidas wrote: > >> > I am using the patch, it works fine, the screen output is attractive. :-) > what happens when you hit "H" ? > > _______________________________________________ > 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 Wed Apr 13 16:12:12 2005 Return-Path: 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 557D516A4CF for ; Wed, 13 Apr 2005 16:12:12 +0000 (GMT) Received: from khavrinen.csail.mit.edu (khavrinen.csail.mit.edu [128.30.28.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id C38FD43D76 for ; Wed, 13 Apr 2005 16:12:11 +0000 (GMT) (envelope-from wollman@khavrinen.csail.mit.edu) Received: from khavrinen.csail.mit.edu (localhost.csail.mit.edu [127.0.0.1]) j3DGBlZ7038871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.lcs.mit.edu issuer=SSL+20Client+20CA); Wed, 13 Apr 2005 12:11:47 -0400 (EDT) (envelope-from wollman@khavrinen.csail.mit.edu) Received: (from wollman@localhost) by khavrinen.csail.mit.edu (8.13.1/8.13.1/Submit) id j3DGBlbh038868; Wed, 13 Apr 2005 12:11:47 -0400 (EDT) (envelope-from wollman) From: Garrett Wollman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16989.17603.295814.247735@khavrinen.csail.mit.edu> Date: Wed, 13 Apr 2005 12:11:47 -0400 To: Theo de Raadt In-Reply-To: <200504122114.j3CLE7Ea013181@cvs.openbsd.org> References: <200504122114.j3CLE7Ea013181@cvs.openbsd.org> X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" XEmacs Lucid X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-1.6 (khavrinen.csail.mit.edu [127.0.0.1]); Wed, 13 Apr 2005 12:11:47 -0400 (EDT) X-Virus-Scanned: ClamAV 0.83/826/Wed Apr 13 07:03:12 2005 on khavrinen.csail.mit.edu X-Virus-Status: Clean X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on khavrinen.csail.mit.edu X-Mailman-Approved-At: Wed, 13 Apr 2005 17:04:10 +0000 cc: Thorsten Glaser cc: freebsd-current@FreeBSD.ORG Subject: Re: strtonum(3) in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 16:12:12 -0000 < said: >> [Attribution deleted by deraadt] >> You already said that, but what about using intmax_t as return type? > No. So I think we are agreed then that this interface is unacceptable. -GAWollman From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 16:53:12 2005 Return-Path: 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 462A616A4CE for ; Wed, 13 Apr 2005 16:53:12 +0000 (GMT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2000C43D2F for ; Wed, 13 Apr 2005 16:53:12 +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.50 (FreeBSD)) id 1DLl71-000386-RB; Wed, 13 Apr 2005 16:53:11 +0000 Received: from [127.0.0.1] (helo=roam.psg.com.psg.com) by roam.psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DLl6y-0000aP-Lj; Wed, 13 Apr 2005 12:53:08 -0400 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16989.20044.34043.537480@roam.psg.com> Date: Wed, 13 Apr 2005 12:52:28 -0400 To: FreeBSD Current Subject: ata and x problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 16:53:12 -0000 this morning's current o kernel will not run Xorg/gnome, comes up with the grey screen and stops. two week old kernel with current world works. o new ata killed suspend/resume on my thinkpad t41 randy From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 17:15:04 2005 Return-Path: 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 EB03A16A4CF for ; Wed, 13 Apr 2005 17:15:04 +0000 (GMT) Received: from mail23.sea5.speakeasy.net (mail23.sea5.speakeasy.net [69.17.117.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6642843D55 for ; Wed, 13 Apr 2005 17:15:04 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 13990 invoked from network); 13 Apr 2005 17:15:03 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail23.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 13 Apr 2005 17:15:03 -0000 Received: from hydrogen.funkthat.com (elopip@localhost.funkthat.com [127.0.0.1])j3DHF2GH021537; Wed, 13 Apr 2005 10:15:02 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id j3DHF177021536; Wed, 13 Apr 2005 10:15:01 -0700 (PDT) Date: Wed, 13 Apr 2005 10:15:01 -0700 From: John-Mark Gurney To: Alexander Leidinger Message-ID: <20050413171500.GN56487@funkthat.com> Mail-Followup-To: Alexander Leidinger , Julian Elischer , FreeBSD Current , multimedia@freebsd.org References: <425C18A2.8010807@elischer.org> <20050413143126.7e0jufn80c0cwow4@netchild.homeip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050413143126.7e0jufn80c0cwow4@netchild.homeip.net> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: FreeBSD Current cc: Julian Elischer cc: multimedia@freebsd.org Subject: Re: Anyone working on V4L2 for BSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 17:15:05 -0000 Alexander Leidinger wrote this message on Wed, Apr 13, 2005 at 14:31 +0200: > Julian Elischer wrote: > > >I'm considerring it.. It looks quite doable. (assuming we can get > >compatible include files > >without copyright problems.) > > > >For compatibility we'd probably want to keep all the V4L prefixes etc. > > > >Is anyone else playing with this? > > There was a discussion about something like this a while ago... a, I see you > participated in it too: > http://lists.freebsd.org/pipermail/freebsd-multimedia/2003-July/000328.html > http://people.freebsd.org/~jmg/videobsd.html Yes, I did... and unless V4L2 managed to change a lot.. It's API is still years behind what we should have... The reason I haven't said anything is that I didn't want to attempt to derail any work that someone might be doing.. Yes, V4L2 is not a very good api, but as others have pointed out, it makes portability easier... Plus, I haven't spent any time on VideoBSD recently, since I've gotten sidetracked by other projects... (Though if I can get ATI to give me specs for their HDTV PCI card, I might spend some more time on it...) So, if you just want Linux compatiblity, go for it... If you want a real usable video API, then send me comments and look at the VideoBSD stuff I have done... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 17:27:07 2005 Return-Path: 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 17E7F16A4CE for ; Wed, 13 Apr 2005 17:27:07 +0000 (GMT) Received: from smtp4.server.rpi.edu (smtp4.server.rpi.edu [128.113.2.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D96343D54 for ; Wed, 13 Apr 2005 17:27:06 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp4.server.rpi.edu (8.13.0/8.13.0) with ESMTP id j3DHR4Yn003323; Wed, 13 Apr 2005 13:27:05 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20050413075956.GO89047@cirb503493.alcatel.com.au> References: <1113332762.27362.29.camel@localhost.localdomain> <20050412195700.GN89047@cirb503493.alcatel.com.au> <20050413030814.GA21318@VARK.MIT.EDU> <20050413075956.GO89047@cirb503493.alcatel.com.au> Date: Wed, 13 Apr 2005 13:27:03 -0500 To: Peter Jeremy , FreeBSD Current From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) on 128.113.2.4 Subject: Re: strtonum(3) in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 17:27:07 -0000 At 5:59 PM +1000 4/13/05, Peter Jeremy wrote: > >> but this is unintuitive to anyone who > >is used to the broken POSIX way of doing it. > >I would dispute the 'broken' adjective. Having errno only affected by >errors means that you can issue a series of system calls and determine >that something failed - which may be enough. Uh, no. This can get you into trouble, if one of those system routines called some other system routine, and that other system routine "failed", but in a way which is not really an error for the routine you called. This happens if a system routine is calling 'stat()' for some *optional* config file, for instance. It is not an error to you at all if that optional config file does not exist, but errno will have been set. Note that I have lost time debugging non-problems because of programmers who used this "time-saving trick" of just checking errno (instead of checking the actual return-code from the routines they called). It is very annoying. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 17:36:54 2005 Return-Path: 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 9DA1016A4CE for ; Wed, 13 Apr 2005 17:36:54 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [83.167.185.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0702143D54 for ; Wed, 13 Apr 2005 17:36:54 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id C4F4765213 for ; Wed, 13 Apr 2005 18:36:32 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 50115-04-23 for ; Wed, 13 Apr 2005 18:36:32 +0100 (BST) Received: from empiric.dek.spc.org (dhcp52.icir.org [192.150.187.52]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id BA20B65371 for ; Wed, 13 Apr 2005 18:36:31 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 0834462DB; Wed, 13 Apr 2005 10:36:45 -0700 (PDT) Date: Wed, 13 Apr 2005 10:36:45 -0700 From: Bruce M Simpson To: freebsd-current@freebsd.org Message-ID: <20050413173645.GA758@empiric.icir.org> Mail-Followup-To: freebsd-current@freebsd.org References: <20050412131535.GA784@empiric.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050412131535.GA784@empiric.icir.org> Subject: Re: [PATCH] Allow pciconf(8) to be used with CardBus devices X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 17:36:54 -0000 On Tue, Apr 12, 2005 at 06:15:35AM -0700, Bruce M Simpson wrote: > The patch is against branch RELENG_5_4. If there are no objections I'd like > to commit it to -HEAD. Committed. There is a patch pending for sysutils/pciutils maintainer. BMS From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 17:40:10 2005 Return-Path: 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 F084316A4E7; Wed, 13 Apr 2005 17:40:10 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1ECE343D6D; Wed, 13 Apr 2005 17:40:10 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.3) id j3DHe88W017382; Wed, 13 Apr 2005 12:40:08 -0500 (CDT) (envelope-from dan) Date: Wed, 13 Apr 2005 12:40:08 -0500 From: Dan Nelson To: David Xu Message-ID: <20050413174008.GD4842@dan.emsphone.com> References: <425CC7F8.3030803@samsco.org> <425CD009.6040208@freebsd.org> <20050413132603.GA39006@orion.daedalusnetworks.priv> <425D2163.4090603@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <425D2163.4090603@freebsd.org> X-OS: FreeBSD 5.4-PRERELEASE X-message-flag: Outlook Error User-Agent: Mutt/1.5.8i cc: freebsd-current@freebsd.org cc: Giorgos Keramidas cc: Jiawei Ye Subject: Re: How does one know how many thread a process owns? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 17:40:11 -0000 In the last episode (Apr 13), David Xu said: > Giorgos Keramidas wrote: > >On 2005-04-13 17:15, Jiawei Ye wrote: > >>On 4/13/05, David Xu wrote: > >>>I believe he wants to see total threads number in a process. add a > >>>column to top to display total kernel threads in per-process, > >>>p_numthreads in proc structure is what you need . :) Still only accurate for libthr, though, right? > >>Exactly what I want. Is is possible to modify our top? > > > >I've added a THR column when top displays only one line per process. > >So when the "display each thread separately" mode is off, you should > >see something like this: I sort of like Solaris' prstat output, where the thread count is after the command: PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP 3120 dnelson 9320K 7256K sleep 0 19 0:00:01 0.3% pike/2 3169 dnelson 4800K 4440K cpu3 59 0 0:00:00 0.2% prstat/1 3144 dnelson 4192K 2936K sleep 59 0 0:00:00 0.1% zsh/1 17037 root 89M 26M sleep 29 10 3:02:52 0.1% java/23 I also find myself asking exactly what our CPU column really represents. Is it any use at all? -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 18:14:36 2005 Return-Path: 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 C1C6A16A4CE; Wed, 13 Apr 2005 18:14:36 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 332A143D4C; Wed, 13 Apr 2005 18:14:34 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id E85507A403; Wed, 13 Apr 2005 11:14:33 -0700 (PDT) Message-ID: <425D5F08.9020702@elischer.org> Date: Wed, 13 Apr 2005 11:03:52 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en, hu MIME-Version: 1.0 To: John-Mark Gurney References: <425C18A2.8010807@elischer.org> <20050413143126.7e0jufn80c0cwow4@netchild.homeip.net> <20050413171500.GN56487@funkthat.com> In-Reply-To: <20050413171500.GN56487@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Alexander Leidinger cc: FreeBSD Current cc: multimedia@freebsd.org Subject: Re: Anyone working on V4L2 for BSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 18:14:36 -0000 John-Mark Gurney wrote: >Alexander Leidinger wrote this message on Wed, Apr 13, 2005 at 14:31 +0200: > > >>Julian Elischer wrote: >> >> >> >>>I'm considerring it.. It looks quite doable. (assuming we can get >>>compatible include files >>>without copyright problems.) >>> >>>For compatibility we'd probably want to keep all the V4L prefixes etc. >>> >>>Is anyone else playing with this? >>> >>> >>There was a discussion about something like this a while ago... a, I see you >>participated in it too: >>http://lists.freebsd.org/pipermail/freebsd-multimedia/2003-July/000328.html >>http://people.freebsd.org/~jmg/videobsd.html >> >> > >Yes, I did... and unless V4L2 managed to change a lot.. It's API is >still years behind what we should have... The reason I haven't said >anything is that I didn't want to attempt to derail any work that someone >might be doing.. Yes, V4L2 is not a very good api, but as others have >pointed out, it makes portability easier... Plus, I haven't spent any >time on VideoBSD recently, since I've gotten sidetracked by other >projects... (Though if I can get ATI to give me specs for their HDTV >PCI card, I might spend some more time on it...) > > My sugestion is that we make V4L2 an alternative interface to a videoBSD framework. Think "netgraph for video" with a V4L2 frontend for apps and a v4l2 backend for drivers. The difference is that the framework would interpret all the ioctls etc instead of the drivers themselves. The drivers MAY attach using a V4L2 interface, but the requersts they get MAY or MAY NOT have come from the clients. In the middle we have support for modules that do simple format conversion, resynching, snipping, and the ability to pass the stream out to a userlandeditor and get it back again, for really compilcated editing. Some requests fromt the clients may be passed through to the drivers. Some may not. >So, if you just want Linux compatiblity, go for it... If you want a >real usable video API, then send me comments and look at the VideoBSD >stuff I have done... > > > From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 18:35:32 2005 Return-Path: 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 85FA716A4CE for ; Wed, 13 Apr 2005 18:35:32 +0000 (GMT) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA42E43D2D for ; Wed, 13 Apr 2005 18:35:31 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j3DIZPuf011449 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 14 Apr 2005 04:35:26 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j3DIZP7l001784; Thu, 14 Apr 2005 04:35:25 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j3DIZO5H001783; Thu, 14 Apr 2005 04:35:24 +1000 (EST) (envelope-from pjeremy) Date: Thu, 14 Apr 2005 04:35:24 +1000 From: Peter Jeremy To: Thorsten Glaser Message-ID: <20050413183523.GQ89047@cirb503493.alcatel.com.au> References: <1113336183.27362.37.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i cc: freebsd-current@freebsd.org Subject: Re: strtonum(3) in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 18:35:32 -0000 On Tue, 2005-Apr-12 20:08:19 +0000, Thorsten Glaser wrote: >>2) No provision to return the end of the converted string >>3) No simple way to distinguish errors from a valid zero. > >The OpenBSD people said (when I proposed to change #1) that >they want an uncomplicated interface, and I think #3 is not >necessary, and I can live without #2. #3 is the only real justification for creating strtonum(3) - if you don't care about determining whether the conversion failed then you might as well use atoi(). I think the intent is that strtonum() should provide an easy to use mechanism for distinguishing between valid and invalid inputs (this is implied by the digs at atoi() and strtol() in the man page). The actual implementation does provide an easy way to identify invalid inputs but it isn't documented. And as others have mentioned, the return type is wrong and the OpenBSD project isn't interested in correcting it. -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 21:59:47 2005 Return-Path: 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 4061616A4CE for ; Wed, 13 Apr 2005 21:59:47 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C49343D53 for ; Wed, 13 Apr 2005 21:59:46 +0000 (GMT) (envelope-from avleeuwen@gmail.com) Received: by rproxy.gmail.com with SMTP id j1so250760rnf for ; Wed, 13 Apr 2005 14:59:46 -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=D0lJdbngMM3+XUdfcz/AK1uFMEHughAWXSIVC33ckc0hw8Vbsb3J8PXDa5MHor6rolb/vW7z/kyOaLsboknDTm0sGWgnTu1zA3AZOB5IyC+jo5FQb24zIYPp9dr2s3jmNm+99TdxByGBwsa+0IyFhLLzVJD4EM4SVer0c64Cnuc= Received: by 10.38.150.20 with SMTP id x20mr1086315rnd; Wed, 13 Apr 2005 14:59:45 -0700 (PDT) Received: by 10.38.88.56 with HTTP; Wed, 13 Apr 2005 14:59:45 -0700 (PDT) Message-ID: Date: Wed, 13 Apr 2005 23:59:45 +0200 From: Arjan Van Leeuwen To: =?ISO-8859-1?Q?Eirik_=D8verby?= In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: cc: "current@freebsd.org" Subject: Re: Panic after "in_cksum_skip: out of data by 260" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Arjan Van Leeuwen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 21:59:47 -0000 On 4/13/05, Eirik =D8verby wrote: > Hi, >=20 > Today I received this message on my serial console: >=20 > in_cksum_skip: out of data by 260 > Fatal trap 12: page fault while in kernel mode (...) >=20 > This server has been very stable for a very long time. This crash surpris= es > me somewhat. > Uname output: > FreeBSD carnen.net 5.3-STABLE FreeBSD 5.3-STABLE #0: Wed Feb 2 21:02:44 = CET > 2005 root@carnen.net:/usr/obj/usr/src/sys/CARNEN i386 I had exactly the same problem today, on a 5.3-RELEASE machine that also had been very stable until now. I hope it's a coincidence :). Unfortunately, I'm not able to get dumps (or even a debug kernel) on that machine, as space is very limited (CompactFlash). Do you also have Realtek cards? Arjan From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 23:06:03 2005 Return-Path: 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 570FE16A4CE for ; Wed, 13 Apr 2005 23:06:03 +0000 (GMT) Received: from april.chuckr.org (april.chuckr.org [66.92.151.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1723D43D46 for ; Wed, 13 Apr 2005 23:06:03 +0000 (GMT) (envelope-from chuckr@chuckr.org) Received: from [66.92.151.195] (july.chuckr.org [66.92.151.195]) by april.chuckr.org (Postfix) with ESMTP id EB5AA11FDD for ; Wed, 13 Apr 2005 18:59:15 -0400 (EDT) Message-ID: <425DA5D9.6070805@chuckr.org> Date: Wed, 13 Apr 2005 23:06:01 +0000 From: Chuck Robey User-Agent: Mozilla Thunderbird 1.0 (X11/20050316) 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: sound question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 23:06:03 -0000 Just one simple question: I have a SoundBlaster Audigy, it's got analog and digital outputs. I know that both work, I had them both working in the same layout with Linux. I just want to know if the fact that I can't get any sound out of the digital outputs is a) because the driver doesn't know about the digital output, or b) because I have it misconfigured c) because I'm doing something horribly stupid. I'm willing to do more investigation, but I want to start off in the correct direction, so a word to start me off the way would help out. BTW, I have a amd64 on this machine, but I could also try the i386 machine. From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 23:18:43 2005 Return-Path: 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 BFF8E16A4CF; Wed, 13 Apr 2005 23:18:43 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id A509743D3F; Wed, 13 Apr 2005 23:18:43 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j3DNIfgx029477; Wed, 13 Apr 2005 23:18:42 GMT (envelope-from davidxu@freebsd.org) Message-ID: <425DA8D5.7070402@freebsd.org> Date: Thu, 14 Apr 2005 07:18:45 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.5) Gecko/20050402 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Giorgos Keramidas References: <425CC7F8.3030803@samsco.org> <425CD009.6040208@freebsd.org> <20050413132603.GA39006@orion.daedalusnetworks.priv> <425D2163.4090603@freebsd.org> <20050413140838.GA77217@renaissance.homeip.net> <20050413141957.GA40546@orion.daedalusnetworks.priv> In-Reply-To: <20050413141957.GA40546@orion.daedalusnetworks.priv> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: Anthony Ginepro cc: Jiawei Ye Subject: Re: How does one know how many thread a process owns? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 23:18:43 -0000 Giorgos Keramidas wrote: >On 2005-04-13 16:08, Anthony Ginepro wrote: > > >>On 04/13/05 21:40, David Xu wrote: >> >> >>>Giorgos Keramidas wrote: >>> >>> >>>>Can you try the following patch? >>>> >>>> >>>I am using the patch, it works fine, the screen output is attractive. :-) >>> >>> >>Except for WCPU it looks like SunOS' top. >> >> > >/me thinks (Oops, they caught me!) > >Yes, I have to admit, I used the output of SunOS top as an inspiration >for the ordering and naming of the THR column :-) > > > > When will you commit it ? the world is walking towards to threaded, especially with multi-cores CPU will be out in few monthes. :-) From owner-freebsd-current@FreeBSD.ORG Wed Apr 13 23:22:10 2005 Return-Path: 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 8724116A4CE; Wed, 13 Apr 2005 23:22:10 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FEA443D39; Wed, 13 Apr 2005 23:22:07 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [10.0.0.20] ([151.196.164.10]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j3DNPBaZ048017; Wed, 13 Apr 2005 17:25:11 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <425DA8D3.3020505@samsco.org> Date: Wed, 13 Apr 2005 17:18:43 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hackers@freebsd.org, current@freebsd.org References: <20050413061639.GK84649@wantadilla.lemis.com> In-Reply-To: <20050413061639.GK84649@wantadilla.lemis.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.9 required=3.8 tests=PLING_QUERY autolearn=no version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Subject: Help Wanted! [Re: Does anybody use gdb for kernel debugging any more?] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 13 Apr 2005 23:22:10 -0000 [Resending to get wider coverage] All, While there are ways to work around some of the problems that Greg describes, the simple fact is that kernel debugging has gone downhill quite badly in the past year. Much of this decay appears to be due to the rush to get GDB 6.x imported in time for FreeBSD 5.3. I thank Marcel profusely for working on this, but more work is needed. I'm looking for volunteers to spend a few evenings digging into GDB, KDB, and DDB and working out as many issues as possible. Greg's email should serve as a good starting point for these tasks. Thanks, Scott Greg 'groggy' Lehey wrote: > In the last 10 months, I've had continual problems trying to use gdb > for kernel debugging. I'm currently revising my notes for the BSDCan > tutorial, and I can't work out how to get it to work any more. Since > about June of last year I've discovered: > > - I can no longer get a dump out of ddb with the 'panic' command. I > need to 'call doadump' > > - 'panic' doesn't only not do a dump, it doesn't reset the system > either. I need to press 'reset'. > > - The invocation to do kernel debugging with gdb keeps changing. A > year ago, it was simple: 'gdb -k kernel dump'. Now the -k command > is gone, and on what I believe to be a valid kernel dump, kgdb gives > me: > > # kgdb kernel.debug /var/crash/vmcore.1 > kgdb: cannot read PTD > > - It's possible that the dump isn't valid after all, of course. But I > can't debug the local system via /dev/mem either: > > # kgdb kernel.debug /dev/mem > [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] > > (kgdb) bt > #0 0x00000000 in ?? () > > - Firewire debugging no longer works if you haven't compiled firewire > into the kernel. Given the bugs I've seen above, I can't be > bothered to try building a kernel with firewire, since I don't have > much expectation that it will work either way. > > So what gives? Has the gdb interface withered away due to lack of > love? Do *you* use it? If so, how do you address the issues above? > > Greg > -- > See complete headers for address and phone numbers. From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 01:04:59 2005 Return-Path: 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 53E3016A4CE; Thu, 14 Apr 2005 01:04:59 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 247AF43D2F; Thu, 14 Apr 2005 01:04:59 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j3E14t8a040191; Thu, 14 Apr 2005 01:04:57 GMT (envelope-from davidxu@freebsd.org) Message-ID: <425DC1DB.4090106@freebsd.org> Date: Thu, 14 Apr 2005 09:05:31 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050319 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <425CC7F8.3030803@samsco.org> <425CD009.6040208@freebsd.org> <20050413132603.GA39006@orion.daedalusnetworks.priv> <425D2163.4090603@freebsd.org> <425C7D0D.5000302@elischer.org> In-Reply-To: <425C7D0D.5000302@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: Giorgos Keramidas cc: Jiawei Ye Subject: Re: How does one know how many thread a process owns? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 14 Apr 2005 01:04:59 -0000 Julian Elischer wrote: > > > David Xu wrote: > >> Giorgos Keramidas wrote: >> >>> >> I am using the patch, it works fine, the screen output is attractive. >> :-) >> > what happens when you hit "H" ? > It can only show individual threads in process, but the guy only wants to see the threads count. David Xu From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 01:45:26 2005 Return-Path: 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 0467316A4D1 for ; Thu, 14 Apr 2005 01:45:26 +0000 (GMT) Received: from sp.dominia.org (efnet-math.org [69.60.109.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E6F243D53 for ; Thu, 14 Apr 2005 01:45:25 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from [192.168.1.12] (63-170-138-118.cst-sg.blacksburg.ntc-com.net [63.170.138.118]) (authenticated bits=0) by sp.dominia.org (8.13.1/8.13.1) with ESMTP id j3E1jLRp011805 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 13 Apr 2005 21:45:22 -0400 In-Reply-To: <20050413054020.GL56487@funkthat.com> References: <0842a01b5aa0cfcd84763fff4a30113e@FreeBSD.org> <20050413054020.GL56487@funkthat.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7924a1be6ee3f91af6ce6a6cc003edaa@FreeBSD.org> Content-Transfer-Encoding: 7bit From: Suleiman Souhlal Date: Wed, 13 Apr 2005 21:45:17 -0400 To: John-Mark Gurney X-Mailer: Apple Mail (2.619.2) cc: current@FreeBSD.org Subject: Re: [PATCH] Allow watching of vnodes that reside on non-UFS filesystems with kqueue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 14 Apr 2005 01:45:26 -0000 Hello, On Apr 13, 2005, at 1:40 AM, John-Mark Gurney wrote: > I would prefer to move the vfs_kqfilter and filt_vfs* functions either > be moved to a vfs specific file, or be moved to their own file.. also, > it appears that we lost support for extending of files... though I > can't > confirm that... Have you verified that extending still gets notified? The patch at http://people.freebsd.org/~ssouhlal/testing/kqueue-hooks-20050413.diff addresses the things you mentioned and introduces a MNTK_NOKNOTE flag to mount->mnt_kern_flag so that a filesystem can override the sending of knotes from the VOP hooks, in case it needs to do something filesystem-specific. I will also send this patch to jeff@ so that he can review the VFS changes. -- Suleiman Souhlal | ssouhlal@vt.edu The FreeBSD Project | ssouhlal@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 02:21:54 2005 Return-Path: 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 C8DA416A4CE for ; Thu, 14 Apr 2005 02:21:54 +0000 (GMT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 900FB43D39 for ; Thu, 14 Apr 2005 02:21:54 +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.50 (FreeBSD)) id 1DLtzO-000D26-5W for freebsd-current@freebsd.org; Thu, 14 Apr 2005 02:21:54 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com) by roam.psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DLtzK-0003w6-99 for freebsd-current@freebsd.org; Wed, 13 Apr 2005 22:21:50 -0400 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16989.54125.658850.960128@roam.psg.com> Date: Wed, 13 Apr 2005 22:20:29 -0400 To: FreeBSD Current Subject: /machine/pcb.h:70: error: field `pcb_fsd' has incomplete type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 14 Apr 2005 02:21:54 -0000 cvsup ending at 2005.04.14 03:20 gmt 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 -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -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 -ffreestanding -Werror /usr/src/sys/ddb/db_print.c In file included from /usr/src/sys/ddb/db_print.c:42: ./machine/pcb.h:70: error: field `pcb_fsd' has incomplete type ./machine/pcb.h:71: error: field `pcb_gsd' has incomplete type *** Error code 1 From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 02:37:12 2005 Return-Path: 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 39CE916A4D0 for ; Thu, 14 Apr 2005 02:37:12 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8212243D53 for ; Thu, 14 Apr 2005 02:37:11 +0000 (GMT) (envelope-from leafy7382@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so297766rng for ; Wed, 13 Apr 2005 19:37:11 -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=EwhOfNJhjwLS8ogWhQVv9hn5vuszsDyFCVyoImx3Osat9J3HVpYyJQm4M/ogmWGr4SF8oxdBxyTK5+y9rP3D1H6nfRyTAOfKYYwiWyLTeLnoST5IbA6wrdL47EjNEemDLnSQxapDaropXiieLtx/FBGWUYY0h7FcczaGD7c79Zo= Received: by 10.38.155.3 with SMTP id c3mr1300170rne; Wed, 13 Apr 2005 19:37:11 -0700 (PDT) Received: by 10.38.22.48 with HTTP; Wed, 13 Apr 2005 19:37:10 -0700 (PDT) Message-ID: Date: Thu, 14 Apr 2005 10:37:10 +0800 From: Jiawei Ye To: David Xu In-Reply-To: <425DC1DB.4090106@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <425CC7F8.3030803@samsco.org> <425CD009.6040208@freebsd.org> <20050413132603.GA39006@orion.daedalusnetworks.priv> <425D2163.4090603@freebsd.org> <425C7D0D.5000302@elischer.org> <425DC1DB.4090106@freebsd.org> cc: freebsd-current@freebsd.org cc: Julian Elischer cc: Giorgos Keramidas Subject: Re: How does one know how many thread a process owns? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Jiawei Ye List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2005 02:37:12 -0000 On 4/14/05, David Xu wrote: > It can only show individual threads in process, but the guy only wants > to see > the threads count. >=20 > David Xu Seems that I ought to explain why I need this. I do Java programming on FreeBSD (well, porting some of our server side components over). It is not realistic to view over 2000 threads in top. I just need to know the thread count in the parent process to get a grip on how our process is doing. Say that the thread count >1000 is normal, and if it drops to 500 then I have to fire up a debugger or something like that. Jiawei Ye --=20 "Without the userland, the kernel is useless." --inspired by The Tao of Programming From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 03:18:36 2005 Return-Path: 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 3C28E16A4CE; Thu, 14 Apr 2005 03:18:36 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A75543D2D; Thu, 14 Apr 2005 03:18:35 +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 j3E3IZuI095580; Wed, 13 Apr 2005 23:18:35 -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 j3E3IZ60021876; Wed, 13 Apr 2005 23:18:35 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id CC7C07306E; Wed, 13 Apr 2005 23:18:34 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050414031834.CC7C07306E@freebsd-current.sentex.ca> Date: Wed, 13 Apr 2005 23:18:34 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on clamscanner4 X-Virus-Status: Clean Subject: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2005 03:18:36 -0000 TB --- 2005-04-14 02:03:10 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-14 02:03:10 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2005-04-14 02:03:10 - checking out the source tree TB --- 2005-04-14 02:03:10 - cd /home/tinderbox/CURRENT/amd64/amd64 TB --- 2005-04-14 02:03:10 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-14 02:10:02 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-14 02:10:02 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-04-14 02:10:02 - /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 [...] ln -fs libbsdxml.so.1 /home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/lib32/usr/lib32/libbsdxml.so sh /tinderbox/CURRENT/amd64/amd64/src/tools/install.sh -C -o root -g wheel -m 444 bsdxml.h /home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/lib32/usr/include ===> lib/libkvm (depend,all,install) cc -m32 -march=athlon-xp -msse2 -mfancy-math-387 -DCOMPAT_32BIT -I/home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/lib32/usr/include -L/home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/lib32/usr/lib32 -B/home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/lib32/usr/lib32 -O2 -pipe -DLIBC_SCCS -I/tinderbox/CURRENT/amd64/amd64/src/lib/libkvm -c /tinderbox/CURRENT/amd64/amd64/src/lib/libkvm/kvm.c In file included from /home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/lib32/usr/include/sys/user.h:36, from /tinderbox/CURRENT/amd64/amd64/src/lib/libkvm/kvm.c:48: /home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/lib32/usr/include/machine/pcb.h:70: error: field `pcb_fsd' has incomplete type /home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/lib32/usr/include/machine/pcb.h:71: error: field `pcb_gsd' has incomplete type *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src/lib/libkvm. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. TB --- 2005-04-14 03:18:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-14 03:18:34 - ERROR: failed to build world TB --- 2005-04-14 03:18:34 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 03:38:08 2005 Return-Path: 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 61ABB16A4CE; Thu, 14 Apr 2005 03:38:08 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id C662243D49; Thu, 14 Apr 2005 03:38:07 +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 j3E3c7cA096047; Wed, 13 Apr 2005 23:38:07 -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 j3E3c77b009667; Wed, 13 Apr 2005 23:38:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 316F87306E; Wed, 13 Apr 2005 23:38:07 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050414033807.316F87306E@freebsd-current.sentex.ca> Date: Wed, 13 Apr 2005 23:38:07 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on clamscanner4 X-Virus-Status: Clean Subject: [current tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2005 03:38:08 -0000 TB --- 2005-04-14 03:18:35 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-14 03:18:35 - starting CURRENT tinderbox run for i386/i386 TB --- 2005-04-14 03:18:35 - checking out the source tree TB --- 2005-04-14 03:18:35 - cd /home/tinderbox/CURRENT/i386/i386 TB --- 2005-04-14 03:18:35 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-14 03:25:21 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-14 03:25:21 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-04-14 03:25:21 - /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 [...] ===> lib/libkvm (depend,all,install) rm -f .depend mkdep -f .depend -a -DLIBC_SCCS -I/tinderbox/CURRENT/i386/i386/src/lib/libkvm /tinderbox/CURRENT/i386/i386/src/lib/libkvm/kvm.c /tinderbox/CURRENT/i386/i386/src/lib/libkvm/kvm_i386.c /tinderbox/CURRENT/i386/i386/src/lib/libkvm/kvm_file.c /tinderbox/CURRENT/i386/i386/src/lib/libkvm/kvm_getloadavg.c /tinderbox/CURRENT/i386/i386/src/lib/libkvm/kvm_getswapinfo.c /tinderbox/CURRENT/i386/i386/src/lib/libkvm/kvm_proc.c cc -O2 -pipe -DLIBC_SCCS -I/tinderbox/CURRENT/i386/i386/src/lib/libkvm -c /tinderbox/CURRENT/i386/i386/src/lib/libkvm/kvm.c In file included from /home/tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/tmp/usr/include/sys/user.h:36, from /tinderbox/CURRENT/i386/i386/src/lib/libkvm/kvm.c:48: /home/tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/tmp/usr/include/machine/pcb.h:70: error: field `pcb_fsd' has incomplete type /home/tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/tmp/usr/include/machine/pcb.h:71: error: field `pcb_gsd' has incomplete type *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src/lib/libkvm. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. TB --- 2005-04-14 03:38:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-14 03:38:07 - ERROR: failed to build world TB --- 2005-04-14 03:38:07 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 03:57:46 2005 Return-Path: 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 3548716A4CE; Thu, 14 Apr 2005 03:57:46 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9011F43D54; Thu, 14 Apr 2005 03:57:43 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.3/8.13.3) with ESMTP id j3E3vh6f084425; Wed, 13 Apr 2005 23:57:43 -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 j3E3vhmM097543; Wed, 13 Apr 2005 23:57:43 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id DE31B7306E; Wed, 13 Apr 2005 23:57:42 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050414035742.DE31B7306E@freebsd-current.sentex.ca> Date: Wed, 13 Apr 2005 23:57:42 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on clamscanner4 X-Virus-Status: Clean Subject: [current tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2005 03:57:46 -0000 TB --- 2005-04-14 03:38:07 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-14 03:38:07 - starting CURRENT tinderbox run for i386/pc98 TB --- 2005-04-14 03:38:07 - checking out the source tree TB --- 2005-04-14 03:38:07 - cd /home/tinderbox/CURRENT/i386/pc98 TB --- 2005-04-14 03:38:07 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-14 03:44:34 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-14 03:44:34 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2005-04-14 03:44:34 - /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 [...] rm -f .depend mkdep -f .depend -a -DLIBC_SCCS -I/tinderbox/CURRENT/i386/pc98/src/lib/libkvm /tinderbox/CURRENT/i386/pc98/src/lib/libkvm/kvm.c /tinderbox/CURRENT/i386/pc98/src/lib/libkvm/kvm_i386.c /tinderbox/CURRENT/i386/pc98/src/lib/libkvm/kvm_file.c /tinderbox/CURRENT/i386/pc98/src/lib/libkvm/kvm_getloadavg.c /tinderbox/CURRENT/i386/pc98/src/lib/libkvm/kvm_getswapinfo.c /tinderbox/CURRENT/i386/pc98/src/lib/libkvm/kvm_proc.c cc -O2 -pipe -DLIBC_SCCS -I/tinderbox/CURRENT/i386/pc98/src/lib/libkvm -c /tinderbox/CURRENT/i386/pc98/src/lib/libkvm/kvm.c In file included from /home/tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/tmp/usr/include/machine/pcb.h:6, from /home/tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/tmp/usr/include/sys/user.h:36, from /tinderbox/CURRENT/i386/pc98/src/lib/libkvm/kvm.c:48: /home/tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/tmp/usr/include/i386/pcb.h:70: error: field `pcb_fsd' has incomplete type /home/tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/tmp/usr/include/i386/pcb.h:71: error: field `pcb_gsd' has incomplete type *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src/lib/libkvm. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. TB --- 2005-04-14 03:57:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-14 03:57:42 - ERROR: failed to build world TB --- 2005-04-14 03:57:42 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 06:30:07 2005 Return-Path: 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 B635016A4CF; Thu, 14 Apr 2005 06:30:07 +0000 (GMT) Received: from smtp-1.dlr.de (smtp-1.dlr.de [195.37.61.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6252843D4C; Thu, 14 Apr 2005 06:30:06 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-1.dlr.de over TLS secured channel with Microsoft SMTPSVC(5.0.2195.6713); Thu, 14 Apr 2005 08:30:04 +0200 Date: Thu, 14 Apr 2005 08:30:41 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Julian Elischer In-Reply-To: <425D5F08.9020702@elischer.org> Message-ID: <20050414082551.N38610@beagle.kn.op.dlr.de> References: <425C18A2.8010807@elischer.org> <20050413143126.7e0jufn80c0cwow4@netchild.homeip.net> <20050413171500.GN56487@funkthat.com> <425D5F08.9020702@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 14 Apr 2005 06:30:04.0528 (UTC) FILETIME=[64DE4F00:01C540BB] cc: Alexander Leidinger cc: John-Mark Gurney cc: FreeBSD Current cc: multimedia@freebsd.org Subject: Re: Anyone working on V4L2 for BSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Harti Brandt List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2005 06:30:07 -0000 On Wed, 13 Apr 2005, Julian Elischer wrote: JE>John-Mark Gurney wrote: JE> JE>> Alexander Leidinger wrote this message on Wed, Apr 13, 2005 at 14:31 +0200: JE>> JE>> > Julian Elischer wrote: JE>> > JE>> > JE>> > > I'm considerring it.. It looks quite doable. (assuming we can get JE>> > > compatible include files JE>> > > without copyright problems.) JE>> > > JE>> > > For compatibility we'd probably want to keep all the V4L prefixes etc. JE>> > > JE>> > > Is anyone else playing with this? JE>> > > JE>> > There was a discussion about something like this a while ago... a, I see JE>> > you JE>> > participated in it too: JE>> > http://lists.freebsd.org/pipermail/freebsd-multimedia/2003-July/000328.html JE>> > http://people.freebsd.org/~jmg/videobsd.html JE>> > JE>> JE>> Yes, I did... and unless V4L2 managed to change a lot.. It's API is JE>> still years behind what we should have... The reason I haven't said JE>> anything is that I didn't want to attempt to derail any work that someone JE>> might be doing.. Yes, V4L2 is not a very good api, but as others have JE>> pointed out, it makes portability easier... Plus, I haven't spent any JE>> time on VideoBSD recently, since I've gotten sidetracked by other JE>> projects... (Though if I can get ATI to give me specs for their HDTV JE>> PCI card, I might spend some more time on it...) JE>> JE> JE>My sugestion is that we make V4L2 an alternative interface to a videoBSD JE>framework. JE>Think "netgraph for video" with a V4L2 frontend for apps and a v4l2 backend JE>for drivers. If you take this without the quotes this is something I wanted to do for years (started even once to try it on streams under Solaris). There is often no need to funnel all the video and audio traffic through user space just to pull it out of one device and put it into another one. This requires some thought though for memory mapped devices. harti JE>The difference is that the framework would interpret all the ioctls etc JE>instead of the drivers themselves. The drivers MAY attach using a V4L2 JE>interface, but the requersts they get MAY or MAY NOT have come from the JE>clients. In the middle we have support for modules that do simple JE>format conversion, resynching, snipping, and the ability to pass the JE>stream out to a userlandeditor and get it back again, for really JE>compilcated editing. Some requests fromt the clients may be passed JE>through to the drivers. Some may not. JE> JE> JE>> So, if you just want Linux compatiblity, go for it... If you want a JE>> real usable video API, then send me comments and look at the VideoBSD JE>> stuff I have done... JE>> JE>> JE>_______________________________________________ JE>freebsd-current@freebsd.org mailing list JE>http://lists.freebsd.org/mailman/listinfo/freebsd-current JE>To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" JE> JE> JE> From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 06:34:33 2005 Return-Path: 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 CE20616A4CE for ; Thu, 14 Apr 2005 06:34:33 +0000 (GMT) Received: from smtp2.jp.viruscheck.net (smtp2.jp.viruscheck.net [154.33.69.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8102E43D41 for ; Thu, 14 Apr 2005 06:34:33 +0000 (GMT) (envelope-from bland@FreeBSD.org) Received: from scan4.jp.viruscheck.net ([154.33.69.39] helo=mail1.jp.viruscheck.net) by smtp2.jp.viruscheck.net with esmtp (Exim 3.36 #1) id 1DLxvk-0002pn-00 for freebsd-current@freebsd.org; Thu, 14 Apr 2005 15:34:24 +0900 Received: from [60.42.121.222] (helo=noc.orchid) by mail1.jp.viruscheck.net with esmtp (Exim 3.36 #3) id 1DLxvk-0004nn-00 for freebsd-current@FreeBSD.org; Thu, 14 Apr 2005 15:34:24 +0900 Received: from [89.60.10.11] (horse.orchid [89.60.10.11]) by noc.orchid (8.12.11/8.12.11) with ESMTP id j3E6YNGv032253 for ; Thu, 14 Apr 2005 15:34:23 +0900 (JST) (envelope-from bland@FreeBSD.org) Message-ID: <425E0EEF.5020100@FreeBSD.org> Date: Thu, 14 Apr 2005 15:34:23 +0900 From: Alexander Nedotsukov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Subject: unmount /dev error on shutdown X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 14 Apr 2005 06:34:33 -0000 Hi, Anyone besides me see message bellow every time at the end of system shutdown process? unmount of /dev error (EBUSY) Is it ok? Thanks, Alexander. From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 06:35:23 2005 Return-Path: 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 5FCBE16A4CE; Thu, 14 Apr 2005 06:35:23 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6605343D45; Thu, 14 Apr 2005 06:35:22 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.3/8.13.1) with ESMTP id j3E6ZKep025675; Thu, 14 Apr 2005 08:35:20 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Alexander Nedotsukov From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 14 Apr 2005 15:34:23 +0900." <425E0EEF.5020100@FreeBSD.org> Date: Thu, 14 Apr 2005 08:35:20 +0200 Message-ID: <25674.1113460520@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: freebsd-current@freebsd.org Subject: Re: unmount /dev error on shutdown X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 14 Apr 2005 06:35:23 -0000 In message <425E0EEF.5020100@FreeBSD.org>, Alexander Nedotsukov writes: >Hi, > >Anyone besides me see message bellow every time at the end of system >shutdown process? > >unmount of /dev error (EBUSY) > >Is it ok? No it's not ok, but it is harmless. it's on my list. -- 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 Thu Apr 14 06:42:17 2005 Return-Path: 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 AAD0B16A4CE for ; Thu, 14 Apr 2005 06:42:17 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id D6EF343D5E for ; Thu, 14 Apr 2005 06:42:16 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.3/8.13.1) with ESMTP id j3E6gGkk025701 for ; Thu, 14 Apr 2005 08:42:16 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: current@freebsd.org From: Poul-Henning Kamp Date: Thu, 14 Apr 2005 08:42:16 +0200 Message-ID: <25700.1113460936@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Subject: -current diskless panic on boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 14 Apr 2005 06:42:17 -0000 sis3: link state changed to UP sysctl: unknown oid 'kern.bootp_cookie' Interface fxp0 IP-Address 192.168.68.29 Broadcast 192.168.68.255 Loading configuration files. Entropy harvesting: interrupts ethernet point_to_point kickstart. Starting file system checks: lock order reversal 1st 0xc0944ac0 vm page queue mutex (vm page queue mutex) @ kern/vfs_bio.c:1485 2nd 0xc1e4e808 vnode interlock (vnode interlock) @ kern/vfs_subr.c:1993 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c08fe468,c08fce10,c088a5a8) at 0xc063de8d = kdb_backtrace+0x29 witness_checkorder(c1e4e808,9,c08314aa,7c9) at 0xc0647e48 = witness_checkorder+0x550 _mtx_lock_flags(c1e4e808,0,c08314a1,7c9,c1d9cdec) at 0xc061e363 = _mtx_lock_flags+0x5b vdrop(c1e4e78c) at 0xc06794f1 = vdrop+0x1d vm_page_remove(c1756f90,c1756f90) at 0xc07624e0 = vm_page_remove+0xd4 vm_page_free_toq(c1756f90,c1756f90,40,c1756f90,d9982a30) at 0xc0762b7c = vm_page_free_toq+0x90 vm_page_free(c1756f90,c1756f90) at 0xc07620ed = vm_page_free+0x15 vfs_vmio_release(cbf0b080) at 0xc066b113 = vfs_vmio_release+0x9b brelse(cbf0b080,cbf0b080) at 0xc066a9a9 = brelse+0x485 flushbuflist(c1e4e854,1,c1e4e850,0,0) at 0xc0677ca2 = flushbuflist+0x1c6 bufobj_invalbuf(c1e4e850,1,c1b5daf0,0,0) at 0xc06778cd = bufobj_invalbuf+0x10d vinvalbuf(c1e4e78c,1,c1b5daf0,0,0) at 0xc0677ad6 = vinvalbuf+0x2a nfs_vinvalbuf(c1e4e78c,1,c1b5daf0,1,a) at 0xc06d33a0 = nfs_vinvalbuf+0xd0 nfs_close(d9982b74,a,c1e4e78c,d9982ba0,c0683413) at 0xc06da24a = nfs_close+0xca VOP_CLOSE_APV(c0898780,d9982b74) at 0xc07d067f = VOP_CLOSE_APV+0x9b vn_close(c1e4e78c,a,c1984d80,c1b5daf0,d9982bd8) at 0xc0683413 = vn_close+0x8b vn_closefile(c1d670d8,c1b5daf0) at 0xc06841c6 = vn_closefile+0xca fdrop_locked(c1d670d8,c1b5daf0,c196ba54,0,c0825433) at 0xc060b620 = fdrop_locked+0x88 fdrop(c1d670d8,c1b5daf0,6ab,c08f4a40,0) at 0xc060b590 = fdrop+0x24 closef(c1d670d8,c1b5daf0,0,0,4) at 0xc060a0d3 = closef+0x35f close(c1b5daf0,d9982d04,1,7,216) at 0xc0607b5b = close+0x1a3 syscall(3b,3b,3b,0,2814c060) at 0xc07bd077 = syscall+0x243 Xint0x80_syscall() at 0xc07aa59f = Xint0x80_syscall+0x1f --- syscall (6, FreeBSD ELF32, close), eip = 0x280b903b, esp = 0xbfbfe8cc, ebp = 0xbfbfe8e8 --- Expensive timeout(9) function: 0xc078dafc(0xc094f7e0) 2.508722197 s panic: lockmgr: locking against myself cpuid = 0 KDB: enter: panic [thread pid 110 tid 100059 ] Stopped at 0xc063df0f = kdb_enter+0x2b: nop db> -- 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 Thu Apr 14 06:44:23 2005 Return-Path: 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 585A116A4CE for ; Thu, 14 Apr 2005 06:44:23 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id E06EC43D5A for ; Thu, 14 Apr 2005 06:44:19 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.3/8.13.1) with ESMTP id j3E6iJkI025739 for ; Thu, 14 Apr 2005 08:44:19 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 14 Apr 2005 08:42:16 +0200." <25700.1113460936@critter.freebsd.dk> Date: Thu, 14 Apr 2005 08:44:19 +0200 Message-ID: <25738.1113461059@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: current@freebsd.org Subject: Re: -current diskless panic on boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 14 Apr 2005 06:44:23 -0000 Oops forgot the backtrace: db> trace Tracing pid 110 tid 100059 td 0xc1b5d7d0 kdb_enter(c082857d) at 0xc063df0f = kdb_enter+0x2b panic(c082693a,c1b5d7d0,0,c08922e0,d997c9b0) at 0xc0626117 = panic+0x127 lockmgr(c1e4e5bc,3002,c1e4e5e0,c1b5d7d0,d997c990) at 0xc061b782 = lockmgr+0x3d6 vop_stdlock(d997c9b0,1002,c1e4e564,d997c9cc,c06840bd) at 0xc067171e = vop_stdlock+0x1e VOP_LOCK_APV(c0898780,d997c9b0) at 0xc07d1e17 = VOP_LOCK_APV+0x87 vn_lock(c1e4e564,1002,c1b5d7d0) at 0xc06840bd = vn_lock+0x101 nfs_lookup(d997cb14,c1e4e564,c1d58408,d997cb30,c0673452) at 0xc06daadb = nfs_lookup+0x1f7 VOP_LOOKUP_APV(c0898780,d997cb14) at 0xc07d0027 = VOP_LOOKUP_APV+0x87 lookup(d997cc00,0,1,c1b5d7d0,c0637228) at 0xc0673452 = lookup+0x3da namei(d997cc00,c093b0a4,d997cbc4,c064833a,c093b0a0) at 0xc0672dfa = namei+0x372 kern_stat(c1b5d7d0,bfbfe8a0,0,d997cc74) at 0xc067ea45 = kern_stat+0x35 stat(c1b5d7d0,d997cd04,2,4,206) at 0xc067e9f3 = stat+0x1b syscall(3b,3b,3b,0,bfbfe6c0) at 0xc07bd077 = syscall+0x243 Xint0x80_syscall() at 0xc07aa59f = Xint0x80_syscall+0x1f --- syscall (188, FreeBSD ELF32, stat), eip = 0x280b73bb, esp = 0xbfbfe63c, ebp = 0xbfbfecb8 --- db> In message <25700.1113460936@critter.freebsd.dk>, Poul-Henning Kamp writes: > >sis3: link state changed to UP >sysctl: unknown oid 'kern.bootp_cookie' >Interface fxp0 IP-Address 192.168.68.29 Broadcast 192.168.68.255 >Loading configuration files. >Entropy harvesting: interrupts ethernet point_to_point kickstart. >Starting file system checks: >lock order reversal > 1st 0xc0944ac0 vm page queue mutex (vm page queue mutex) @ kern/vfs_bio.c:1485 > 2nd 0xc1e4e808 vnode interlock (vnode interlock) @ kern/vfs_subr.c:1993 >KDB: stack backtrace: >kdb_backtrace(0,ffffffff,c08fe468,c08fce10,c088a5a8) at 0xc063de8d = kdb_backtrace+0x29 >witness_checkorder(c1e4e808,9,c08314aa,7c9) at 0xc0647e48 = witness_checkorder+0x550 >_mtx_lock_flags(c1e4e808,0,c08314a1,7c9,c1d9cdec) at 0xc061e363 = _mtx_lock_flags+0x5b >vdrop(c1e4e78c) at 0xc06794f1 = vdrop+0x1d >vm_page_remove(c1756f90,c1756f90) at 0xc07624e0 = vm_page_remove+0xd4 >vm_page_free_toq(c1756f90,c1756f90,40,c1756f90,d9982a30) at 0xc0762b7c = vm_page_free_toq+0x90 >vm_page_free(c1756f90,c1756f90) at 0xc07620ed = vm_page_free+0x15 >vfs_vmio_release(cbf0b080) at 0xc066b113 = vfs_vmio_release+0x9b >brelse(cbf0b080,cbf0b080) at 0xc066a9a9 = brelse+0x485 >flushbuflist(c1e4e854,1,c1e4e850,0,0) at 0xc0677ca2 = flushbuflist+0x1c6 >bufobj_invalbuf(c1e4e850,1,c1b5daf0,0,0) at 0xc06778cd = bufobj_invalbuf+0x10d >vinvalbuf(c1e4e78c,1,c1b5daf0,0,0) at 0xc0677ad6 = vinvalbuf+0x2a >nfs_vinvalbuf(c1e4e78c,1,c1b5daf0,1,a) at 0xc06d33a0 = nfs_vinvalbuf+0xd0 >nfs_close(d9982b74,a,c1e4e78c,d9982ba0,c0683413) at 0xc06da24a = nfs_close+0xca >VOP_CLOSE_APV(c0898780,d9982b74) at 0xc07d067f = VOP_CLOSE_APV+0x9b >vn_close(c1e4e78c,a,c1984d80,c1b5daf0,d9982bd8) at 0xc0683413 = vn_close+0x8b >vn_closefile(c1d670d8,c1b5daf0) at 0xc06841c6 = vn_closefile+0xca >fdrop_locked(c1d670d8,c1b5daf0,c196ba54,0,c0825433) at 0xc060b620 = fdrop_locked+0x88 >fdrop(c1d670d8,c1b5daf0,6ab,c08f4a40,0) at 0xc060b590 = fdrop+0x24 >closef(c1d670d8,c1b5daf0,0,0,4) at 0xc060a0d3 = closef+0x35f >close(c1b5daf0,d9982d04,1,7,216) at 0xc0607b5b = close+0x1a3 >syscall(3b,3b,3b,0,2814c060) at 0xc07bd077 = syscall+0x243 >Xint0x80_syscall() at 0xc07aa59f = Xint0x80_syscall+0x1f >--- syscall (6, FreeBSD ELF32, close), eip = 0x280b903b, esp = 0xbfbfe8cc, ebp = 0xbfbfe8e8 --- >Expensive timeout(9) function: 0xc078dafc(0xc094f7e0) 2.508722197 s >panic: lockmgr: locking against myself >cpuid = 0 >KDB: enter: panic >[thread pid 110 tid 100059 ] >Stopped at 0xc063df0f = kdb_enter+0x2b: nop >db> >-- >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. >_______________________________________________ >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" > -- 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 Thu Apr 14 06:46:51 2005 Return-Path: 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 120FE16A4CE for ; Thu, 14 Apr 2005 06:46:50 +0000 (GMT) Received: from mail.chesapeake.net (chesapeake.net [208.142.252.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2731D43D2D for ; Thu, 14 Apr 2005 06:46:50 +0000 (GMT) (envelope-from jroberson@chesapeake.net) Received: from mail.chesapeake.net (localhost [127.0.0.1]) by mail.chesapeake.net (8.12.10/8.12.10) with ESMTP id j3E6kmen072437; Thu, 14 Apr 2005 02:46:48 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost)j3E6kmsG072434; Thu, 14 Apr 2005 02:46:48 -0400 (EDT) (envelope-from jroberson@chesapeake.net) X-Authentication-Warning: mail.chesapeake.net: jroberson owned process doing -bs Date: Thu, 14 Apr 2005 02:46:48 -0400 (EDT) From: Jeff Roberson To: Poul-Henning Kamp In-Reply-To: <25738.1113461059@critter.freebsd.dk> Message-ID: <20050414024639.S93349@mail.chesapeake.net> References: <25738.1113461059@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: -current diskless panic on boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 14 Apr 2005 06:46:51 -0000 Please try this: Index: nfs_vnops.c =================================================================== RCS file: /home/ncvs/src/sys/nfsclient/nfs_vnops.c,v retrieving revision 1.257 diff -u -r1.257 nfs_vnops.c --- nfs_vnops.c 13 Apr 2005 10:59:09 -0000 1.257 +++ nfs_vnops.c 14 Apr 2005 06:44:40 -0000 @@ -809,8 +809,6 @@ vput(newvp); else vrele(newvp); - if (flags & ISDOTDOT) - vn_lock(dvp, LK_EXCLUSIVE|LK_RETRY, td); *vpp = NULLVP; } error = 0; On Thu, 14 Apr 2005, Poul-Henning Kamp wrote: > > Oops > > forgot the backtrace: > > db> trace > Tracing pid 110 tid 100059 td 0xc1b5d7d0 > kdb_enter(c082857d) at 0xc063df0f = kdb_enter+0x2b > panic(c082693a,c1b5d7d0,0,c08922e0,d997c9b0) at 0xc0626117 = panic+0x127 > lockmgr(c1e4e5bc,3002,c1e4e5e0,c1b5d7d0,d997c990) at 0xc061b782 = lockmgr+0x3d6 > vop_stdlock(d997c9b0,1002,c1e4e564,d997c9cc,c06840bd) at 0xc067171e = vop_stdlock+0x1e > VOP_LOCK_APV(c0898780,d997c9b0) at 0xc07d1e17 = VOP_LOCK_APV+0x87 > vn_lock(c1e4e564,1002,c1b5d7d0) at 0xc06840bd = vn_lock+0x101 > nfs_lookup(d997cb14,c1e4e564,c1d58408,d997cb30,c0673452) at 0xc06daadb = nfs_lookup+0x1f7 > VOP_LOOKUP_APV(c0898780,d997cb14) at 0xc07d0027 = VOP_LOOKUP_APV+0x87 > lookup(d997cc00,0,1,c1b5d7d0,c0637228) at 0xc0673452 = lookup+0x3da > namei(d997cc00,c093b0a4,d997cbc4,c064833a,c093b0a0) at 0xc0672dfa = namei+0x372 > kern_stat(c1b5d7d0,bfbfe8a0,0,d997cc74) at 0xc067ea45 = kern_stat+0x35 > stat(c1b5d7d0,d997cd04,2,4,206) at 0xc067e9f3 = stat+0x1b > syscall(3b,3b,3b,0,bfbfe6c0) at 0xc07bd077 = syscall+0x243 > Xint0x80_syscall() at 0xc07aa59f = Xint0x80_syscall+0x1f > --- syscall (188, FreeBSD ELF32, stat), eip = 0x280b73bb, esp = 0xbfbfe63c, ebp = 0xbfbfecb8 --- > db> > > In message <25700.1113460936@critter.freebsd.dk>, Poul-Henning Kamp writes: > > > >sis3: link state changed to UP > >sysctl: unknown oid 'kern.bootp_cookie' > >Interface fxp0 IP-Address 192.168.68.29 Broadcast 192.168.68.255 > >Loading configuration files. > >Entropy harvesting: interrupts ethernet point_to_point kickstart. > >Starting file system checks: > >lock order reversal > > 1st 0xc0944ac0 vm page queue mutex (vm page queue mutex) @ kern/vfs_bio.c:1485 > > 2nd 0xc1e4e808 vnode interlock (vnode interlock) @ kern/vfs_subr.c:1993 > >KDB: stack backtrace: > >kdb_backtrace(0,ffffffff,c08fe468,c08fce10,c088a5a8) at 0xc063de8d = kdb_backtrace+0x29 > >witness_checkorder(c1e4e808,9,c08314aa,7c9) at 0xc0647e48 = witness_checkorder+0x550 > >_mtx_lock_flags(c1e4e808,0,c08314a1,7c9,c1d9cdec) at 0xc061e363 = _mtx_lock_flags+0x5b > >vdrop(c1e4e78c) at 0xc06794f1 = vdrop+0x1d > >vm_page_remove(c1756f90,c1756f90) at 0xc07624e0 = vm_page_remove+0xd4 > >vm_page_free_toq(c1756f90,c1756f90,40,c1756f90,d9982a30) at 0xc0762b7c = vm_page_free_toq+0x90 > >vm_page_free(c1756f90,c1756f90) at 0xc07620ed = vm_page_free+0x15 > >vfs_vmio_release(cbf0b080) at 0xc066b113 = vfs_vmio_release+0x9b > >brelse(cbf0b080,cbf0b080) at 0xc066a9a9 = brelse+0x485 > >flushbuflist(c1e4e854,1,c1e4e850,0,0) at 0xc0677ca2 = flushbuflist+0x1c6 > >bufobj_invalbuf(c1e4e850,1,c1b5daf0,0,0) at 0xc06778cd = bufobj_invalbuf+0x10d > >vinvalbuf(c1e4e78c,1,c1b5daf0,0,0) at 0xc0677ad6 = vinvalbuf+0x2a > >nfs_vinvalbuf(c1e4e78c,1,c1b5daf0,1,a) at 0xc06d33a0 = nfs_vinvalbuf+0xd0 > >nfs_close(d9982b74,a,c1e4e78c,d9982ba0,c0683413) at 0xc06da24a = nfs_close+0xca > >VOP_CLOSE_APV(c0898780,d9982b74) at 0xc07d067f = VOP_CLOSE_APV+0x9b > >vn_close(c1e4e78c,a,c1984d80,c1b5daf0,d9982bd8) at 0xc0683413 = vn_close+0x8b > >vn_closefile(c1d670d8,c1b5daf0) at 0xc06841c6 = vn_closefile+0xca > >fdrop_locked(c1d670d8,c1b5daf0,c196ba54,0,c0825433) at 0xc060b620 = fdrop_locked+0x88 > >fdrop(c1d670d8,c1b5daf0,6ab,c08f4a40,0) at 0xc060b590 = fdrop+0x24 > >closef(c1d670d8,c1b5daf0,0,0,4) at 0xc060a0d3 = closef+0x35f > >close(c1b5daf0,d9982d04,1,7,216) at 0xc0607b5b = close+0x1a3 > >syscall(3b,3b,3b,0,2814c060) at 0xc07bd077 = syscall+0x243 > >Xint0x80_syscall() at 0xc07aa59f = Xint0x80_syscall+0x1f > >--- syscall (6, FreeBSD ELF32, close), eip = 0x280b903b, esp = 0xbfbfe8cc, ebp = 0xbfbfe8e8 --- > >Expensive timeout(9) function: 0xc078dafc(0xc094f7e0) 2.508722197 s > >panic: lockmgr: locking against myself > >cpuid = 0 > >KDB: enter: panic > >[thread pid 110 tid 100059 ] > >Stopped at 0xc063df0f = kdb_enter+0x2b: nop > >db> > >-- > >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. > >_______________________________________________ > >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" > > > > -- > 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. > _______________________________________________ > 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 Thu Apr 14 08:23:30 2005 Return-Path: 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 A8E9F16A4CE for ; Thu, 14 Apr 2005 08:23:30 +0000 (GMT) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CF6E43D4C for ; Thu, 14 Apr 2005 08:23:30 +0000 (GMT) (envelope-from des@des.no) Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IEX00L1WGDK5HC0@bgo1smout1.broadpark.no> for freebsd-current@freebsd.org; Thu, 14 Apr 2005 10:17:44 +0200 (CEST) Received: from dsa.des.no ([80.203.228.37]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IEX002FUGP1U7A0@bgo1sminn1.broadpark.no> for freebsd-current@freebsd.org; Thu, 14 Apr 2005 10:24:37 +0200 (CEST) Received: by dsa.des.no (Pony Express, from userid 666) id 4571EEBCB4; Thu, 14 Apr 2005 10:23:22 +0200 (CEST) Received: from xps.des.no (xps.des.no [10.0.0.12]) by dsa.des.no (Pony Express) with ESMTP id A2A46EBC06; Thu, 14 Apr 2005 10:23:16 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id 952A233C5A; Thu, 14 Apr 2005 10:23:16 +0200 (CEST) Date: Thu, 14 Apr 2005 10:23:16 +0200 From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) In-reply-to: <6.2.1.2.0.20050412220212.055c5d48@64.7.153.2> To: Mike Tancsa Message-id: <867jj5wyvf.fsf@xps.des.no> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on dsa.des.no References: <6.2.1.2.0.20050412220212.055c5d48@64.7.153.2> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL autolearn=disabled version=3.0.2 X-Spam-Level: cc: freebsd-current@freebsd.org Subject: Re: ichwd fixes / patches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 14 Apr 2005 08:23:30 -0000 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. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 09:19:06 2005 Return-Path: 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 91BEA16A4CE; Thu, 14 Apr 2005 09:19:06 +0000 (GMT) Received: from aiolos.otenet.gr (aiolos.otenet.gr [195.170.0.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 85EB843D5A; Thu, 14 Apr 2005 09:19:05 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from orion.daedalusnetworks.priv (aris.bedc.ondsl.gr [62.103.39.226])j3E9HwqZ025293; Thu, 14 Apr 2005 12:17:59 +0300 Received: from orion.daedalusnetworks.priv (orion [127.0.0.1]) j3E9J6L4023505; Thu, 14 Apr 2005 12:19:06 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost)j3E9J62v023461; Thu, 14 Apr 2005 12:19:06 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Thu, 14 Apr 2005 12:19:05 +0300 From: Giorgos Keramidas To: Jiawei Ye Message-ID: <20050414091905.GC2540@orion.daedalusnetworks.priv> References: <425CC7F8.3030803@samsco.org> <425CD009.6040208@freebsd.org> <20050413132603.GA39006@orion.daedalusnetworks.priv> <425D2163.4090603@freebsd.org> <425C7D0D.5000302@elischer.org> <425DC1DB.4090106@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: cc: freebsd-current@freebsd.org cc: David Xu cc: Julian Elischer Subject: Re: How does one know how many thread a process owns? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 14 Apr 2005 09:19:06 -0000 On 2005-04-14 10:37, Jiawei Ye wrote: >On 4/14/05, David Xu wrote: >> It can only show individual threads in process, but the guy only >> wants to see the threads count. > > Seems that I ought to explain why I need this. I do Java programming > on FreeBSD (well, porting some of our server side components over). It > is not realistic to view over 2000 threads in top. I just need to know > the thread count in the parent process to get a grip on how our > process is doing. Say that the thread count >1000 is normal, and if it > drops to 500 then I have to fire up a debugger or something like that. I've only reserved 3 characters for the thread field column, so this could still be a bit of a problem. Would a 4 or 5-column width be more realistic? From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 10:04:12 2005 Return-Path: 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 94D7516A4CE; Thu, 14 Apr 2005 10:04:12 +0000 (GMT) Received: from rosebud.otenet.gr (rosebud.otenet.gr [195.170.0.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id AEC2B43D60; Thu, 14 Apr 2005 10:04:11 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from orion.daedalusnetworks.priv (aris.bedc.ondsl.gr [62.103.39.226])j3EA3AGo006203; Thu, 14 Apr 2005 13:03:10 +0300 Received: from orion.daedalusnetworks.priv (orion [127.0.0.1]) j3EA4IZv027669; Thu, 14 Apr 2005 13:04:18 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost)j3EA4Gg4027668; Thu, 14 Apr 2005 13:04:16 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Thu, 14 Apr 2005 13:04:16 +0300 From: Giorgos Keramidas To: David Xu Message-ID: <20050414100416.GA27629@orion.daedalusnetworks.priv> References: <425CC7F8.3030803@samsco.org> <425CD009.6040208@freebsd.org> <20050413132603.GA39006@orion.daedalusnetworks.priv> <425D2163.4090603@freebsd.org> <20050413140838.GA77217@renaissance.homeip.net> <20050413141957.GA40546@orion.daedalusnetworks.priv> <425DA8D5.7070402@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <425DA8D5.7070402@freebsd.org> cc: freebsd-current@freebsd.org cc: Anthony Ginepro cc: Jiawei Ye Subject: Re: How does one know how many thread a process owns? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 14 Apr 2005 10:04:12 -0000 On 2005-04-14 07:18, David Xu wrote: > When will you commit it ? the world is walking towards to threaded, > especially with multi-cores CPU will be out in few monthes. :-) Ok, I have a version that doesn't need to duplicate the sprintf() part of format_next_proc() and uses a wider column width for the THR count, since people have reported using a few thousand threads. Can you give this one a try too? Both patches are available at http://people.freebsd.org/~keramida/diff/top-threads.diff http://people.freebsd.org/~keramida/diff/top-threads2.diff From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 10:31:58 2005 Return-Path: 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 8A10716A4CE; Thu, 14 Apr 2005 10:31:58 +0000 (GMT) Received: from postman.ripe.net (postman.ripe.net [193.0.0.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A33443D4C; Thu, 14 Apr 2005 10:31:58 +0000 (GMT) (envelope-from marks@ripe.net) Received: by postman.ripe.net (Postfix, from userid 8) id 6BE9025F19; Thu, 14 Apr 2005 12:31:57 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 7FBAE2491C; Thu, 14 Apr 2005 12:31:56 +0200 (CEST) Received: from laptop.santcroos.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id j3EAVtet004337; Thu, 14 Apr 2005 12:31:56 +0200 Received: (nullmailer pid 11377 invoked by uid 1001); Thu, 14 Apr 2005 10:31:55 -0000 Date: Thu, 14 Apr 2005 12:31:54 +0200 From: Mark Santcroos To: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org Message-ID: <20050414103154.GA11341@laptop.santcroos.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-RIPE-Spam-Level: X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00,SUBJ_HAS_UNIQ_ID X-RIPE-Spam-Status: N 0.063423 / -4.6 X-RIPE-Signature: 0eda13457ee6274db72a74871e22c3e2 Subject: Please test: ACPI-CA import 20050408 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 14 Apr 2005 10:31:58 -0000 Dear all, Please give this a go on a fresh -current and let me know the results. It has plenty of changes which are listed in the included CHANGES.txt. http://www.santcroos.net/mark/freebsd/files/acpi_import_20050408.diff.gz Thanks Mark -- RIPE NCC - Delft University of Technology - The FreeBSD Project marks@ripe.net - m.a.santcroos@ewi.tudelft.nl - marks@freebsd.org From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 12:06:02 2005 Return-Path: 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 DA64416A4CE for ; Thu, 14 Apr 2005 12:06:02 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE80443D1F for ; Thu, 14 Apr 2005 12:06:01 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.3/8.13.1) with ESMTP id j3EC60mP027363 for ; Thu, 14 Apr 2005 14:06:00 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: current@freebsd.org From: Poul-Henning Kamp Date: Thu, 14 Apr 2005 14:06:00 +0200 Message-ID: <27362.1113480360@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Subject: [HEADSUP] End of life for if_mn and musycc G.703 drivers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 14 Apr 2005 12:06:03 -0000 I am not aware of any active use of the if_mn and musycc G.703 drivers anymore so unless active users contact me in the next couple of weeks I will remove them from the source tree to get them out of the way before RELENG_6. -- 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 Thu Apr 14 02:20:59 2005 Return-Path: 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 ADCB616A4CE for ; Thu, 14 Apr 2005 02:20:59 +0000 (GMT) Received: from mail.codefusionis.com (ns.codefusionis.com [208.33.29.188]) by mx1.FreeBSD.org (Postfix) with SMTP id C9C2143D49 for ; Thu, 14 Apr 2005 02:20:56 +0000 (GMT) (envelope-from tedu@zeitbombe.org) Received: (qmail 32649 invoked by uid 1049); 14 Apr 2005 02:23:42 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 14 Apr 2005 02:23:42 -0000 Date: Wed, 13 Apr 2005 22:23:42 -0400 (EDT) From: Ted Unangst X-X-Sender: tedu@ns.codefusionis.com To: tech@openbsd.org, freebsd-current@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Thu, 14 Apr 2005 12:07:06 +0000 Subject: Re: strtonum(3) in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 14 Apr 2005 02:20:59 -0000 > Based on the man page, I see the following deficiencies: > 1) No support for bases other than 10 it's meant for converting numbers, not addresses. if you want strtoaddr, or strtomode_t, there's still strtol. the idea was to keep it simple. most people think about sending 10 packets, not 0xa packets. > 2) No provision to return the end of the converted string exactly, there's no need for it. strtonum is used to convert a "string containing a number" not a "string containing a number optionally followed by some other things which are not the number". if strlen() won't give you want you want, it means the input is not appropriate for strtonum. > 3) No simple way to distinguish errors from a valid zero. check errstr. i updated the man page to clearly reflect the fact it will be NULL on sucess, that was the original intention. the whole errno dance is there precisely because it's the only way to tell if strtol failed and is so completely unnatural we want to insulate the user from it. i think you guys are missing the point of why strtonum exists. if it did exactly what strtol does, why bother? strtol - #1 - #2 - #3 = strtonum. strtonum came about because ping had a whole variety of issues with numerical arguments. i created a strtonum function for it that was pretty much special case. it doesn't take long to realize that there's also ping6. and another thing. so the interface was widened up some. but not too big. there was a lot of discussion about exactly what strtonum would do, what it wouldn't do, and how one would use it. you don't have to agree with our decisions, but it sounds like you're descending in on "strtol but not called strtol". -- someone's writing down your mistakes someone's documenting your downfall From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 02:39:28 2005 Return-Path: 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 4971316A4CE for ; Thu, 14 Apr 2005 02:39:28 +0000 (GMT) Received: from cvs.openbsd.org (cvs.openbsd.org [199.185.137.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id D577143D49 for ; Thu, 14 Apr 2005 02:39:27 +0000 (GMT) (envelope-from deraadt@cvs.openbsd.org) Received: from cvs.openbsd.org (localhost [127.0.0.1]) by cvs.openbsd.org (8.13.3/8.12.1) with ESMTP id j3E2dRkG018431; Wed, 13 Apr 2005 20:39:27 -0600 (MDT) Message-Id: <200504140239.j3E2dRkG018431@cvs.openbsd.org> To: Ted Unangst In-reply-to: Your message of "Wed, 13 Apr 2005 22:23:42 EDT." Date: Wed, 13 Apr 2005 20:39:27 -0600 From: Theo de Raadt X-Mailman-Approved-At: Thu, 14 Apr 2005 12:07:06 +0000 cc: tech@openbsd.org cc: freebsd-current@freebsd.org Subject: Re: strtonum(3) in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 14 Apr 2005 02:39:28 -0000 > strtonum came about because ping had a whole variety of issues with > numerical arguments. i created a strtonum function for it that was pretty > much special case. it doesn't take long to realize that there's also > ping6. and another thing. so the interface was widened up some. but not > too big. there was a lot of discussion about exactly what strtonum would > do, what it wouldn't do, and how one would use it. you don't have to > agree with our decisions, but it sounds like you're descending in on > "strtol but not called strtol". As Tedu explains, strtonum() was designed to resolve the way that atoi() and strtol() are misused. And not just in a few places, but everywhere. Hundreds and thousands of places will take "57b" and say that is the number 57, because they use atoi(). So people are told to use strtol(). People are saying that strtonum() is a poor interface. Here's how you have to use strtol() correctly to handle all the cases: char *ep; int ival; long lval; ... errno = 0; lval = strtol(buf, &ep, 10); if (buf[0] == '\0' || *ep != '\0') goto not_a_number; if ((errno == ERANGE && (lval == LONG_MAX || lval == LONG_MIN)) || (lval > INT_MAX || lval < INT_MIN)) goto out_of_range; ival = lval; [This is a quote from our manual page, please read it for more details about how hard these interfaces are difficult to use perfectly] This is why strtol() is not an atoi() replacement. strtonum() is designed to be that replacement. It is easy to use, and it is easy to take existing code using atoi() or strtol() [incorrectly used most of the time, too] and convert them to use it. That is the number 1 goal. If you don't understand what strtonum()'s reasons for existance are, of course you will judge it wrong. If correcting all the atoi() and strtol() or strtoul() bugs in your source tree doesn't matter to you, then please feel free to ignore strtonum(). We just got really sick of copying that blob of code above all over the place. From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 08:25:51 2005 Return-Path: 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 C38C916A4CE for ; Thu, 14 Apr 2005 08:25:51 +0000 (GMT) Received: from post.00t.org (feynman.00t.org [217.160.135.158]) by mx1.FreeBSD.org (Postfix) with ESMTP id 359FC43D1F for ; Thu, 14 Apr 2005 08:25:51 +0000 (GMT) (envelope-from ulrik@00t.org) Received: from [172.24.0.14] (pD9E1FE1F.dip.t-dialin.net [217.225.254.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by post.00t.org (Postfix) with ESMTP id 20BCC192BD; Thu, 14 Apr 2005 10:25:49 +0200 (CEST) Message-ID: <425E2914.3070404@00t.org> Date: Thu, 14 Apr 2005 10:25:56 +0200 From: Ulrik Guenther User-Agent: Mozilla Thunderbird 1.0 (X11/20050309) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chuck Robey References: <425DA5D9.6070805@chuckr.org> In-Reply-To: <425DA5D9.6070805@chuckr.org> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 14 Apr 2005 12:07:06 +0000 cc: FreeBSD-current@FreeBSD.org Subject: Re: sound question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 14 Apr 2005 08:25:51 -0000 Hi Chuck, as I know so far, the driver does not really know *anything* about digital output. If you are using your SoundBlaster not commercially, could could give the OpenSoundSystem (www.opensound.com) a try which is free for non-commercial use. With this, your Audigy should work like a charm. Have fun, Ulrik Chuck Robey wrote: > Just one simple question: > > I have a SoundBlaster Audigy, it's got analog and digital outputs. I > know that both work, I had them both working in the same layout with > Linux. I just want to know if the fact that I can't get any sound out > of the digital outputs is > > a) because the driver doesn't know about the digital output, or > b) because I have it misconfigured > c) because I'm doing something horribly stupid. > > I'm willing to do more investigation, but I want to start off in the > correct direction, so a word to start me off the way would help out. > > BTW, I have a amd64 on this machine, but I could also try the i386 machine. > _______________________________________________ > 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 Thu Apr 14 10:08:41 2005 Return-Path: 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 A85F016A4CE; Thu, 14 Apr 2005 10:08:41 +0000 (GMT) Received: from gddsn.org.cn (gddsn.org.cn [218.19.164.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02FAE43D4C; Thu, 14 Apr 2005 10:08:41 +0000 (GMT) (envelope-from wsk@gddsn.org.cn) Received: from [192.168.168.138] (unknown [192.168.168.138]) by gddsn.org.cn (Postfix) with ESMTP id F385538CB49; Thu, 14 Apr 2005 18:08:36 +0800 (CST) Message-ID: <425E40DB.6030204@gddsn.org.cn> Date: Thu, 14 Apr 2005 18:07:23 +0800 From: wsk User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; zh-CN; rv:1.7.6) Gecko/20050326 X-Accept-Language: zh-cn,zh MIME-Version: 1.0 To: current@freebsd.org, stable@freebsd.org Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 14 Apr 2005 12:07:06 +0000 Subject: Can isp driver support Qlogic 2340 on FreeBSD5.x or later? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 14 Apr 2005 10:08:41 -0000 folks: Can the Qlogic 2340 Fibre Channel card works on FreeBSD now? DELL released a newest Server PE6850 with this card.thx From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 12:08:40 2005 Return-Path: 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 E466C16A4CE for ; Thu, 14 Apr 2005 12:08:39 +0000 (GMT) Received: from sgiso3.bbl.be (sgiso3.bbl.be [193.178.209.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id E88BB43D1D for ; Thu, 14 Apr 2005 12:08:38 +0000 (GMT) (envelope-from Stephane.Bosman@ing.be) Received: from smlfe3.bbl.be (10.66.9.161) by sgiso3.bbl.be (NPlex 5.5.015) id 425B68FF000227D6 for freebsd-current@freebsd.org; Thu, 14 Apr 2005 14:11:05 +0200 Received: from SPBEMTA00001VSSMTP3.europe.intranet ([10.66.121.18]) by smlfe3.bbl.be with InterScan Messaging Security Suite; Thu, 14 Apr 2005 13:53:42 +0200 Received: from SPBECMS00006.europe.intranet ([10.66.123.5]) by SPBEMTA00001VSSMTP3.europe.intranet with Microsoft SMTPSVC(5.0.2195.6713); Thu, 14 Apr 2005 13:54:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 14 Apr 2005 13:54:06 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: GEOM Gate committed! Thread-Index: AcVA6KkePeelXeO2QsyxmAL/ac7S0g== From: To: X-OriginalArrivalTime: 14 Apr 2005 11:54:06.0859 (UTC) FILETIME=[A96695B0:01C540E8] X-Mailman-Approved-At: Thu, 14 Apr 2005 12:09:52 +0000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: GEOM Gate committed! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 14 Apr 2005 12:08:40 -0000 Hi I have to choose between nbd on Linux, nbd on FreeBSD and Geom-Gate for a= production lvel, critical application. What would you choose ? Thanks St=E9phane Bosman=0D __________ Disclaimer: This e-mail is intended for the exclusive use by the=0D person(s) mentioned as recipient(s). This e-mail and its attachments, if any, contain confidential information and/or information protected by intellectual property rights or other rights. This e-mail does not constitute any commitment for ING or its subsidiaries except when expressly otherwise agreed in a written agreement between the=0D intended recipient and the originating subsidiaries of ING, sender of the mail. If you receive this message by mistake, please, notify the sender=0D with the "reply" option and delete immediately this e-mail from your system, and destroy all copies of it. You may not, directly or indirectly, use, disclose, distribute, print or copy, this e-mail or any part of it if you are not the intended recipient. You have to take at any time all necessary measures against viruses. From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 12:17:55 2005 Return-Path: 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 1E27216A4CE for ; Thu, 14 Apr 2005 12:17:55 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF0A943D5E for ; Thu, 14 Apr 2005 12:17:54 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by rproxy.gmail.com with SMTP id j1so353372rnf for ; Thu, 14 Apr 2005 05:17:45 -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:content-transfer-encoding:content-disposition; b=oZRrsCnKgizuWddFTZMucaxeXAZA/E3/5HDQGd2y6O3qa5uK6W6ehahh2zcrS7XyAdA51is5L37oLxSe5NUk8m+mJVFgcwOxQ5fhOQgLLoLOVSfBK7vEU+3O5EKnHmOBjDk7+UAWjk9VaZQoeu9rQdPk9ED0+DL5/6pIZWiac/E= Received: by 10.38.96.65 with SMTP id t65mr1776293rnb; Thu, 14 Apr 2005 05:17:45 -0700 (PDT) Received: by 10.38.209.22 with HTTP; Thu, 14 Apr 2005 05:17:45 -0700 (PDT) Message-ID: <84dead7205041405175d707d1a@mail.gmail.com> Date: Thu, 14 Apr 2005 12:17:45 +0000 From: Joseph Koshy To: FreeBSD Current Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Hard lockups at boot [/dev/random] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Joseph Koshy List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2005 12:17:55 -0000 This affects only HTT-enabled P4 machines. Recent -CURRENT builds (~from about 1--2 weeks ago) lock up at boot time, inside /etc/rc.d/initrandom at this point: 57 ( ps -fauxww; sysctl -a; date; df -ib; dmesg; ps -fauxww; ) \ 58 | dd of=3D/dev/random bs=3D8k 2>/dev/null This is a hard lockup and requires a reset. The subsequent boot tends to complete without a lockup, and then the behaviour of the box is normal. Has anyone else seen this behaviour? --=20 FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 13:03:19 2005 Return-Path: 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 036AE16A4CE for ; Thu, 14 Apr 2005 13:03:19 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54AF743D58 for ; Thu, 14 Apr 2005 13:03:18 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 1605 invoked from network); 14 Apr 2005 13:06:26 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 14 Apr 2005 13:06:26 -0000 Message-ID: <425E6A15.8010100@freebsd.org> Date: Thu, 14 Apr 2005 15:03:17 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: Poul-Henning Kamp References: <27362.1113480360@critter.freebsd.dk> In-Reply-To: <27362.1113480360@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: [HEADSUP] End of life for if_mn and musycc G.703 drivers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 14 Apr 2005 13:03:19 -0000 Poul-Henning Kamp wrote: > I am not aware of any active use of the if_mn and musycc G.703 > drivers anymore so unless active users contact me in the next couple > of weeks I will remove them from the source tree to get them out > of the way before RELENG_6. You can kill this driver for good. We have written a new much more featured driver for this chip for our upcoming single/dual T1/E1 card doing unchannelized/channelized/ fractional/G.703/G.704/PRI and whatnot including Asterisk support. -- Andre From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 13:04:23 2005 Return-Path: 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 2377716A4CE; Thu, 14 Apr 2005 13:04:23 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D3BC43D45; Thu, 14 Apr 2005 13:04:22 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.3/8.13.1) with ESMTP id j3ED4I1Y027817; Thu, 14 Apr 2005 15:04:18 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Andre Oppermann From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 14 Apr 2005 15:03:17 +0200." <425E6A15.8010100@freebsd.org> Date: Thu, 14 Apr 2005 15:04:18 +0200 Message-ID: <27816.1113483858@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: current@freebsd.org Subject: Re: [HEADSUP] End of life for if_mn and musycc G.703 drivers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 14 Apr 2005 13:04:23 -0000 In message <425E6A15.8010100@freebsd.org>, Andre Oppermann writes: >Poul-Henning Kamp wrote: >> I am not aware of any active use of the if_mn and musycc G.703 >> drivers anymore so unless active users contact me in the next couple >> of weeks I will remove them from the source tree to get them out >> of the way before RELENG_6. > >You can kill this driver for good. > >We have written a new much more featured driver for this chip for >our upcoming single/dual T1/E1 card doing unchannelized/channelized/ >fractional/G.703/G.704/PRI and whatnot including Asterisk support. Sounds cool! -- 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 Thu Apr 14 13:08:01 2005 Return-Path: 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 38DE216A4CE for ; Thu, 14 Apr 2005 13:08:01 +0000 (GMT) Received: from bsd.dino.sk (bsd.dino.sk [213.215.72.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id D454E43D3F for ; Thu, 14 Apr 2005 13:07:59 +0000 (GMT) (envelope-from bsd@dino.sk) Received: from [213.215.74.194] ([213.215.74.194]) (AUTH: LOGIN milan) by bsd.dino.sk with esmtp; Thu, 14 Apr 2005 15:08:39 +0200 id 000000C9.425E6B57.00001635 From: Milan Obuch To: freebsd-current@freebsd.org Date: Thu, 14 Apr 2005 15:07:55 +0200 User-Agent: KMail/1.6.2 References: <27362.1113480360@critter.freebsd.dk> <425E6A15.8010100@freebsd.org> In-Reply-To: <425E6A15.8010100@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200504141507.55423.bsd@dino.sk> Subject: Re: [HEADSUP] End of life for if_mn and musycc G.703 drivers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 14 Apr 2005 13:08:01 -0000 On Thursday 14 April 2005 15:03, Andre Oppermann wrote: > Poul-Henning Kamp wrote: > > I am not aware of any active use of the if_mn and musycc G.703 > > drivers anymore so unless active users contact me in the next couple > > of weeks I will remove them from the source tree to get them out > > of the way before RELENG_6. > > You can kill this driver for good. > > We have written a new much more featured driver for this chip for > our upcoming single/dual T1/E1 card doing unchannelized/channelized/ > fractional/G.703/G.704/PRI and whatnot including Asterisk support. Where can we get info about it? As long as we do not have anything better, we need if_mn. And what does exactly 'upcoming' mean? How long do we need wait? Milan From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 13:08:15 2005 Return-Path: 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 047BF16A4CE for ; Thu, 14 Apr 2005 13:08:15 +0000 (GMT) Received: from smtp-vbr5.xs4all.nl (smtp-vbr5.xs4all.nl [194.109.24.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35EFE43D45 for ; Thu, 14 Apr 2005 13:08:14 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp-vbr5.xs4all.nl (8.12.11/8.12.11) with ESMTP id j3ED8C67090285; Thu, 14 Apr 2005 15:08:12 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.13.3/8.12.9) with ESMTP id j3ED8Cft012987; Thu, 14 Apr 2005 15:08:12 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.13.3/8.13.1/Submit) id j3ED8C6C012986; Thu, 14 Apr 2005 15:08:12 +0200 (CEST) (envelope-from wb) Date: Thu, 14 Apr 2005 15:08:12 +0200 From: Wilko Bulte To: Stephane.Bosman@ing.be Message-ID: <20050414130812.GA12965@freebie.xs4all.nl> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 4.11-STABLE User-Agent: Mutt/1.5.6i X-Virus-Scanned: by XS4ALL Virus Scanner cc: freebsd-current@freebsd.org Subject: Re: GEOM Gate committed! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 14 Apr 2005 13:08:15 -0000 On Thu, Apr 14, 2005 at 01:54:06PM +0200, Stephane.Bosman@ing.be wrote.. > > Hi > > I have to choose between nbd on Linux, nbd on FreeBSD and Geom-Gate for a production lvel, critical application. What would you choose ? Trying to get an unbiased opinion from the FreeBSD community is probably similar to asking the Pope what he thinks of becoming a Budhist ;) -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 13:50:11 2005 Return-Path: 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 2227816A4CE; Thu, 14 Apr 2005 13:50:11 +0000 (GMT) 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 665C343D31; Thu, 14 Apr 2005 13:50:10 +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 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0IEX00KUGVRK4J@ms-dienst.rz.rwth-aachen.de>; Thu, 14 Apr 2005 15:50:09 +0200 (MEST) Received: from relay.rwth-aachen.de ([134.130.3.1]) by r220-1 (MailMonitor for SMTP v1.2.2 ) ; Thu, 14 Apr 2005 15:50:06 +0200 (MEST) Received: from haakonia.hitnet.rwth-aachen.de (haakonia.hitnet.RWTH-Aachen.DE [137.226.181.92])j3EDo6QX001471; Thu, 14 Apr 2005 15:50:06 +0200 (MEST) Received: by haakonia.hitnet.rwth-aachen.de (Postfix, from userid 1001) id A30D928452; Thu, 14 Apr 2005 15:50:05 +0200 (CEST) Date: Thu, 14 Apr 2005 15:50:05 +0200 From: Christian Brueffer In-reply-to: <20050414103154.GA11341@laptop.santcroos.net> To: Mark Santcroos Message-id: <20050414135004.GB75334@unixpages.org> MIME-version: 1.0 Content-type: multipart/signed; boundary="lEGEL1/lMxI0MVQ2"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-disposition: inline User-Agent: Mutt/1.5.6i X-Operating-System: FreeBSD 5.4-STABLE 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: <20050414103154.GA11341@laptop.santcroos.net> cc: freebsd-acpi@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: Please test: ACPI-CA import 20050408 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 14 Apr 2005 13:50:11 -0000 --lEGEL1/lMxI0MVQ2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 14, 2005 at 12:31:54PM +0200, Mark Santcroos wrote: > Dear all, >=20 > Please give this a go on a fresh -current and let me know the results. > It has plenty of changes which are listed in the included CHANGES.txt. >=20 > http://www.santcroos.net/mark/freebsd/files/acpi_import_20050408.diff.gz >=20 Hi, looks like acopcode.h and acnames.h are not included in the patch. - 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 --lEGEL1/lMxI0MVQ2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFCXnUMbHYXjKDtmC0RAnDbAKCgCYdlLdflaG2EcIE6L3TxV7Nn9wCg4IJy 4XH9D9wH6V4OGhrQ5gno4vI= =PSfy -----END PGP SIGNATURE----- --lEGEL1/lMxI0MVQ2-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 14:01:38 2005 Return-Path: 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 2D26C16A4CE for ; Thu, 14 Apr 2005 14:01:38 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E9F143D46 for ; Thu, 14 Apr 2005 14:01:37 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 2134 invoked from network); 14 Apr 2005 14:04:44 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 14 Apr 2005 14:04:44 -0000 Message-ID: <425E77C0.7050801@freebsd.org> Date: Thu, 14 Apr 2005 16:01:36 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: Milan Obuch References: <27362.1113480360@critter.freebsd.dk> <425E6A15.8010100@freebsd.org> <200504141507.55423.bsd@dino.sk> In-Reply-To: <200504141507.55423.bsd@dino.sk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: [HEADSUP] End of life for if_mn and musycc G.703 drivers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 14 Apr 2005 14:01:38 -0000 Milan Obuch wrote: > On Thursday 14 April 2005 15:03, Andre Oppermann wrote: > >>Poul-Henning Kamp wrote: >> >>>I am not aware of any active use of the if_mn and musycc G.703 >>>drivers anymore so unless active users contact me in the next couple >>>of weeks I will remove them from the source tree to get them out >>>of the way before RELENG_6. >> >>You can kill this driver for good. >> >>We have written a new much more featured driver for this chip for >>our upcoming single/dual T1/E1 card doing unchannelized/channelized/ >>fractional/G.703/G.704/PRI and whatnot including Asterisk support. > > Where can we get info about it? As long as we do not have anything better, we > need if_mn. And what does exactly 'upcoming' mean? How long do we need wait? Do you actually use the current driver? And PHK only wants to yank it from -current, not from 5.x. -- Andre From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 15:12:31 2005 Return-Path: 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 D08E516A4CE for ; Thu, 14 Apr 2005 15:12:31 +0000 (GMT) Received: from bsd.dino.sk (bsd.dino.sk [213.215.72.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6CAF943D4C for ; Thu, 14 Apr 2005 15:12:30 +0000 (GMT) (envelope-from bsd@dino.sk) Received: from [213.215.74.194] ([213.215.74.194]) (AUTH: LOGIN milan) by bsd.dino.sk with esmtp; Thu, 14 Apr 2005 17:13:10 +0200 id 000000DE.425E8886.000029A7 From: Milan Obuch To: freebsd-current@freebsd.org Date: Thu, 14 Apr 2005 17:12:25 +0200 User-Agent: KMail/1.6.2 References: <27362.1113480360@critter.freebsd.dk> <200504141507.55423.bsd@dino.sk> <425E77C0.7050801@freebsd.org> In-Reply-To: <425E77C0.7050801@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200504141712.25659.bsd@dino.sk> Subject: Re: [HEADSUP] End of life for if_mn and musycc G.703 drivers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 14 Apr 2005 15:12:31 -0000 On Thursday 14 April 2005 16:01, Andre Oppermann wrote: > Milan Obuch wrote: > > On Thursday 14 April 2005 15:03, Andre Oppermann wrote: > >>Poul-Henning Kamp wrote: > >>>I am not aware of any active use of the if_mn and musycc G.703 > >>>drivers anymore so unless active users contact me in the next couple > >>>of weeks I will remove them from the source tree to get them out > >>>of the way before RELENG_6. > >> > >>You can kill this driver for good. > >> > >>We have written a new much more featured driver for this chip for > >>our upcoming single/dual T1/E1 card doing unchannelized/channelized/ > >>fractional/G.703/G.704/PRI and whatnot including Asterisk support. > > > > Where can we get info about it? As long as we do not have anything > > better, we need if_mn. And what does exactly 'upcoming' mean? How long do > > we need wait? > > Do you actually use the current driver? And PHK only wants to yank it from > -current, not from 5.x. Actually our production use is still 4.10-RELEASE, we are preparing to move to 5.4-RELEASE as soon as it will be available and we could port our system. So I have no troubles with removing if_mn in favor for something better/more featurefull in current. I just want to know about new driver, new cards and their possibilities. My original response was just to rise awareness of production use of the feature, which we consider important for our bussiness. If better replacement is ready, then everything is OK. Or even better. Regards, Milan From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 15:58:18 2005 Return-Path: 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 050EC16A4CE for ; Thu, 14 Apr 2005 15:58:18 +0000 (GMT) Received: from april.chuckr.org (april.chuckr.org [66.92.151.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8ACE843D2D for ; Thu, 14 Apr 2005 15:58:17 +0000 (GMT) (envelope-from chuckr@chuckr.org) Received: from [66.92.151.195] (july.chuckr.org [66.92.151.195]) by april.chuckr.org (Postfix) with ESMTP id 54E64114FC; Thu, 14 Apr 2005 11:51:18 -0400 (EDT) Message-ID: <425E9306.8030702@chuckr.org> Date: Thu, 14 Apr 2005 15:57:58 +0000 From: Chuck Robey User-Agent: Mozilla Thunderbird 1.0 (X11/20050316) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ulrik Guenther References: <425DA5D9.6070805@chuckr.org> <425E2914.3070404@00t.org> In-Reply-To: <425E2914.3070404@00t.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: FreeBSD-current@FreeBSD.org Subject: Re: sound question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 14 Apr 2005 15:58:18 -0000 Ulrik Guenther wrote: > Hi Chuck, > > as I know so far, the driver does not really know *anything* about > digital output. If you are using your SoundBlaster not commercially, > could could give the OpenSoundSystem (www.opensound.com) a try which is > free for non-commercial use. With this, your Audigy should work like a > charm. Well, I would really, really rather that our driver handled it. Understand, having the digital work needs two things> our driver, the section that talks to the mixer, must be able to turn on the correct channels. There are a LOT of channels, more than you might suspect. This feeds into the other part: the mixer application (the thing that's probably gui'ed, that you turn on levels with) must turn o nthe right set of values. At least so far, all of the mixer applications haven't had enough channels to brighten my day. Well, maybe I can use the info from ALSA, the Linux sound (which does work on digital output, does turn on the right set) to id things. If I can keep on with this, I would surely love to get this working. > > Have fun, > > Ulrik > > Chuck Robey wrote: > >> Just one simple question: >> >> I have a SoundBlaster Audigy, it's got analog and digital outputs. I >> know that both work, I had them both working in the same layout with >> Linux. I just want to know if the fact that I can't get any sound out >> of the digital outputs is >> >> a) because the driver doesn't know about the digital output, or >> b) because I have it misconfigured >> c) because I'm doing something horribly stupid. >> >> I'm willing to do more investigation, but I want to start off in the >> correct direction, so a word to start me off the way would help out. >> >> BTW, I have a amd64 on this machine, but I could also try the i386 >> machine. >> _______________________________________________ >> 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 Thu Apr 14 17:20:55 2005 Return-Path: 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 AEEDB16A4CE; Thu, 14 Apr 2005 17:20:55 +0000 (GMT) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F77343D3F; Thu, 14 Apr 2005 17:20:53 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id IBA74465; Thu, 14 Apr 2005 10:20:53 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 14E685D07; Thu, 14 Apr 2005 10:20:52 -0700 (PDT) To: Alexander Leidinger In-reply-to: Your message of "Wed, 13 Apr 2005 14:31:26 +0200." <20050413143126.7e0jufn80c0cwow4@netchild.homeip.net> Date: Thu, 14 Apr 2005 10:20:51 -0700 From: "Kevin Oberman" Message-Id: <20050414172052.14E685D07@ptavv.es.net> cc: jmg@freebsd.org cc: FreeBSD Current cc: Julian Elischer cc: multimedia@freebsd.org Subject: Re: Anyone working on V4L2 for BSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 14 Apr 2005 17:20:55 -0000 > Date: Wed, 13 Apr 2005 14:31:26 +0200 > From: Alexander Leidinger > Sender: owner-freebsd-current@freebsd.org > > Julian Elischer wrote: > > > > > I'm considerring it.. It looks quite doable. (assuming we can get > > compatible include files > > without copyright problems.) > > > > For compatibility we'd probably want to keep all the V4L prefixes etc. > > > > Is anyone else playing with this? > > There was a discussion about something like this a while ago... a, I see you > participated in it too: > http://lists.freebsd.org/pipermail/freebsd-multimedia/2003-July/000328.html > http://people.freebsd.org/~jmg/videobsd.html This is something I would love to see. FreeBSD being limited to various forms of Brooktree video chips is a serious limitation in this day and age. I routinely have to tell people who want to use our H.323 conferencing system from a laptop that they are OOL. :-( And even desktop users are annoyed that they can't use their (already purchased) USB cameras and that they have to get a camera with video output and a WinTV card. Of course, I am still fighting a battle with getting recent GnomeMeeting to work on V5, but I do make a bit of progress on this from time to time when I have a chance to work on it. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 17:21:55 2005 Return-Path: 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 27CEB16A4CE; Thu, 14 Apr 2005 17:21:55 +0000 (GMT) Received: from postman.ripe.net (postman.ripe.net [193.0.0.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7072B43D45; Thu, 14 Apr 2005 17:21:54 +0000 (GMT) (envelope-from marks@ripe.net) Received: by postman.ripe.net (Postfix, from userid 8) id AB5C326D6D; Thu, 14 Apr 2005 19:21:53 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id AF5D626D5E; Thu, 14 Apr 2005 19:21:49 +0200 (CEST) Received: from laptop.santcroos.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id j3EHLmet008311; Thu, 14 Apr 2005 19:21:48 +0200 Received: (nullmailer pid 801 invoked by uid 1001); Thu, 14 Apr 2005 17:21:47 -0000 Date: Thu, 14 Apr 2005 19:21:47 +0200 From: Mark Santcroos To: Christian Brueffer Message-ID: <20050414172147.GA772@laptop.santcroos.net> References: <20050414103154.GA11341@laptop.santcroos.net> <20050414135004.GB75334@unixpages.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050414135004.GB75334@unixpages.org> User-Agent: Mutt/1.4.2.1i X-RIPE-Spam-Level: X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00,SUBJ_HAS_UNIQ_ID X-RIPE-Spam-Status: N 0.092531 / -4.6 X-RIPE-Signature: 2b17d9cd3b34f164010f74f48dcc5e1f cc: freebsd-acpi@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: Please test: ACPI-CA import 20050408 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 14 Apr 2005 17:21:55 -0000 On Thu, Apr 14, 2005 at 03:50:05PM +0200, Christian Brueffer wrote: > looks like acopcode.h and acnames.h are not included in the patch. Oops, rusty cvs skills :) The following files have been added to the diff: abcompare.c abmain.c acnames.h acopcode.h acpibin.h aecommon.h aeexec.c aemain.c osunixdir.c Same location, more fun: http://www.santcroos.net/mark/freebsd/files/acpi_import_20050408.diff.gz Mark -- RIPE NCC - Delft University of Technology - The FreeBSD Project marks@ripe.net - m.a.santcroos@ewi.tudelft.nl - marks@freebsd.org From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 17:49:12 2005 Return-Path: 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 09A1F16A4CE for ; Thu, 14 Apr 2005 17:49:12 +0000 (GMT) Received: from postal3.es.net (postal3.es.net [198.128.3.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id B494343D5D for ; Thu, 14 Apr 2005 17:49:07 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal3.es.net (Postal Node 3) with ESMTP (SSL) id IBA74465; Thu, 14 Apr 2005 10:49:07 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id D9DDA5D07; Thu, 14 Apr 2005 10:49:06 -0700 (PDT) To: Randy Bush In-reply-to: Your message of "Wed, 13 Apr 2005 12:52:28 EDT." <16989.20044.34043.537480@roam.psg.com> Date: Thu, 14 Apr 2005 10:49:06 -0700 From: "Kevin Oberman" Message-Id: <20050414174906.D9DDA5D07@ptavv.es.net> cc: FreeBSD Current Subject: Re: ata and x problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 14 Apr 2005 17:49:12 -0000 > From: Randy Bush > Date: Wed, 13 Apr 2005 12:52:28 -0400 > Sender: owner-freebsd-current@freebsd.org > > this morning's current > > o kernel will not run Xorg/gnome, comes up with the grey > screen and stops. two week old kernel with current > world works. Can you switch to a vty and do a "ps -ax" on the system? See if you have something that is starting up with the new session in a permanent Rs state. Even though it's always "runnable", it uses no CPU and can't be killed in any way that I can find. I have been having problems since I updated on Monday. Last Friday was fine. FWIW, I only see this with gkrellm, but the only thing changed between Monday morning when it worked and when it didn't was a new kernel. (I have since updated both kernel and world, but it made no difference.) > o new ata killed suspend/resume on my thinkpad t41 Ack! Not again! Do you have ata-pci.c 1.96 or newer? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 18:31:39 2005 Return-Path: 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 D130E16A4CE for ; Thu, 14 Apr 2005 18:31:39 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 497AA43D49 for ; Thu, 14 Apr 2005 18:31:39 +0000 (GMT) (envelope-from lydianconcepts@gmail.com) Received: by rproxy.gmail.com with SMTP id j1so434968rnf for ; Thu, 14 Apr 2005 11:31:38 -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=MNbLkG+EOja/HrJin5eTfLvTnIXLNEQwpXGkfu0e88T5QSLuVQMKvknJOb0Y6pcrXIu7tkr8LsDFmyfrepCVKLKykSom6vrQ9dai51ltRO1TGY0jnHKeokj7D0+wqeWgW0OnDBifRKmpbEGYdAxbkxy3HYos4ITQcmym/y0Absw= Received: by 10.38.65.55 with SMTP id n55mr2085529rna; Thu, 14 Apr 2005 11:31:38 -0700 (PDT) Received: by 10.38.104.23 with HTTP; Thu, 14 Apr 2005 11:31:37 -0700 (PDT) Message-ID: <7579f7fb050414113147698bbf@mail.gmail.com> Date: Thu, 14 Apr 2005 11:31:37 -0700 From: Matthew Jacob To: wsk In-Reply-To: <425E40DB.6030204@gddsn.org.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <425E40DB.6030204@gddsn.org.cn> cc: stable@freebsd.org cc: current@freebsd.org Subject: Re: Can isp driver support Qlogic 2340 on FreeBSD5.x or later? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Matthew Jacob List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2005 18:31:40 -0000 Yes, the 234X cards have been supported for quite a while. DELL has a clone card which up until recently wasn't supported. The 236X/63XX cards are not yet supported. On 4/14/05, wsk wrote: > folks: > Can the Qlogic 2340 Fibre Channel card works on FreeBSD now? > DELL released a newest Server PE6850 with this card.thx > _______________________________________________ > 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 Thu Apr 14 18:59:15 2005 Return-Path: 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 313E516A4CE for ; Thu, 14 Apr 2005 18:59:15 +0000 (GMT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3A4143D53 for ; Thu, 14 Apr 2005 18:59:14 +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.50 (FreeBSD)) id 1DM9YY-000BRB-BA; Thu, 14 Apr 2005 18:59:14 +0000 Received: from [127.0.0.1] (helo=roam.psg.com.psg.com) by roam.psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DM9YU-0000K6-Aj; Thu, 14 Apr 2005 14:59:10 -0400 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16990.48509.162056.672938@roam.psg.com> Date: Thu, 14 Apr 2005 14:59:09 -0400 To: "Kevin Oberman" References: <16989.20044.34043.537480@roam.psg.com> <20050414174906.D9DDA5D07@ptavv.es.net> cc: FreeBSD Current Subject: Re: ata and x problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 14 Apr 2005 18:59:15 -0000 __FBSDID("$FreeBSD: src/sys/dev/ata/ata-pci.c,v 1.98 2005/04/11 20:28:15 sos Exp $"); From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 19:04:37 2005 Return-Path: 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 7E92616A4CE; Thu, 14 Apr 2005 19:04:37 +0000 (GMT) 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 E5EA743D54; Thu, 14 Apr 2005 19:04:36 +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 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0IEY0028AABNWJ@ms-dienst.rz.rwth-aachen.de>; Thu, 14 Apr 2005 21:04:36 +0200 (MEST) Received: from relay.rwth-aachen.de ([134.130.3.1]) by r220-1 (MailMonitor for SMTP v1.2.2 ) ; Thu, 14 Apr 2005 21:04:35 +0200 (MEST) Received: from haakonia.hitnet.rwth-aachen.de (haakonia.hitnet.RWTH-Aachen.DE [137.226.181.92])j3EJ4YGd023378; Thu, 14 Apr 2005 21:04:34 +0200 (MEST) Received: by haakonia.hitnet.rwth-aachen.de (Postfix, from userid 1001) id 6530828456; Thu, 14 Apr 2005 21:04:34 +0200 (CEST) Date: Thu, 14 Apr 2005 21:04:34 +0200 From: Christian Brueffer In-reply-to: <20050414172147.GA772@laptop.santcroos.net> To: Mark Santcroos Message-id: <20050414190433.GA77312@unixpages.org> MIME-version: 1.0 Content-type: multipart/signed; boundary=PNTmBPCT7hxwcZjr; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-disposition: inline User-Agent: Mutt/1.5.6i X-Operating-System: FreeBSD 5.4-STABLE 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: <20050414103154.GA11341@laptop.santcroos.net> <20050414135004.GB75334@unixpages.org> <20050414172147.GA772@laptop.santcroos.net> cc: freebsd-acpi@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: Please test: ACPI-CA import 20050408 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 14 Apr 2005 19:04:37 -0000 --PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 14, 2005 at 07:21:47PM +0200, Mark Santcroos wrote: > On Thu, Apr 14, 2005 at 03:50:05PM +0200, Christian Brueffer wrote: > > looks like acopcode.h and acnames.h are not included in the patch. >=20 > Oops, rusty cvs skills :) >=20 > The following files have been added to the diff: > abcompare.c abmain.c acnames.h acopcode.h acpibin.h aecommon.h aeexec.c > aemain.c osunixdir.c >=20 > Same location, more fun: > http://www.santcroos.net/mark/freebsd/files/acpi_import_20050408.diff.gz >=20 Works as advertized on my T41p (more fun indeed ;-). - 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 --PNTmBPCT7hxwcZjr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFCXr7BbHYXjKDtmC0RAkZeAJ9FsXkAKTFI4jKn3NIAaIlOyEwEHgCgnL8j 3FX5ZaN73uj/IG8modwNJaA= =9hfK -----END PGP SIGNATURE----- --PNTmBPCT7hxwcZjr-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 19:18:29 2005 Return-Path: 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 8DA9616A4CE for ; Thu, 14 Apr 2005 19:18:29 +0000 (GMT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7A4343D5A for ; Thu, 14 Apr 2005 19:18:28 +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.50 (FreeBSD)) id 1DM9r9-000Bm0-Ut; Thu, 14 Apr 2005 19:18:28 +0000 Received: from [127.0.0.1] (helo=roam.psg.com.psg.com) by roam.psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DM9r6-0000Hj-4X; Thu, 14 Apr 2005 15:18:24 -0400 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16990.49663.376307.329731@roam.psg.com> Date: Thu, 14 Apr 2005 15:18:23 -0400 To: "Kevin Oberman" References: <16989.20044.34043.537480@roam.psg.com> <20050414174906.D9DDA5D07@ptavv.es.net> cc: FreeBSD Current Subject: Re: ata and x problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 14 Apr 2005 19:18:29 -0000 >> o kernel will not run Xorg/gnome, comes up with the grey >> screen and stops. two week old kernel with current >> world works. > Can you switch to a vty and do a "ps -ax" on the system? See if you have > something that is starting up with the new session in a permanent Rs > state. Even though it's always "runnable", it uses no CPU and can't be > killed in any way that I can find. USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 11 92.1 0.0 0 8 ?? RL 3:02PM 7:21.94 [idle] root 27 1.1 0.0 0 8 ?? WL 3:02PM 0:03.76 [swi4: clock sio] root 22 0.0 0.0 0 8 ?? WL 3:02PM 0:04.92 [irq11: cbb0 cbb1+++] root 41 0.0 0.0 0 8 ?? DL 3:02PM 0:00.56 [acpi_thermal] root 0 0.0 0.0 0 0 ?? DLs 3:02PM 0:00.00 [swapper] root 1 0.0 0.0 784 408 ?? ILs 3:02PM 0:00.01 /sbin/init -- root 2 0.0 0.0 0 8 ?? DL 3:02PM 0:00.15 [g_event] root 3 0.0 0.0 0 8 ?? DL 3:02PM 0:00.34 [g_up] root 4 0.0 0.0 0 8 ?? DL 3:02PM 0:00.39 [g_down] root 5 0.0 0.0 0 8 ?? DL 3:02PM 0:00.00 [kqueue taskq] root 6 0.0 0.0 0 8 ?? DL 3:02PM 0:00.00 [thread taskq] root 7 0.0 0.0 0 8 ?? SL 3:02PM 0:00.12 [acpi_task0] root 8 0.0 0.0 0 8 ?? DL 3:02PM 0:00.00 [cbb0] root 9 0.0 0.0 0 8 ?? DL 3:02PM 0:00.00 [cbb1] root 10 0.0 0.0 0 8 ?? DL 3:02PM 0:00.00 [ktrace] root 12 0.0 0.0 0 8 ?? WL 3:02PM 0:00.00 [irq0: clk] root 13 0.0 0.0 0 8 ?? WL 3:02PM 0:00.04 [irq1: atkbd0] root 14 0.0 0.0 0 8 ?? WL 3:02PM 0:00.00 [irq3:] root 15 0.0 0.0 0 8 ?? WL 3:02PM 0:00.00 [irq4: sio0] root 16 0.0 0.0 0 8 ?? WL 3:02PM 0:00.00 [irq5:] root 17 0.0 0.0 0 8 ?? WL 3:02PM 0:00.00 [irq6:] root 18 0.0 0.0 0 8 ?? WL 3:02PM 0:00.00 [irq7: ppc0] root 19 0.0 0.0 0 8 ?? WL 3:02PM 0:00.00 [irq8: rtc] root 20 0.0 0.0 0 8 ?? WL 3:02PM 0:00.20 [irq9: acpi0] root 21 0.0 0.0 0 8 ?? WL 3:02PM 0:00.00 [irq10:] root 23 0.0 0.0 0 8 ?? WL 3:02PM 0:00.01 [irq12: psm0] root 24 0.0 0.0 0 8 ?? WL 3:02PM 0:00.00 [irq13:] root 25 0.0 0.0 0 8 ?? WL 3:02PM 0:00.08 [irq14: ata0] root 26 0.0 0.0 0 8 ?? WL 3:02PM 0:00.00 [irq15: ata1] root 28 0.0 0.0 0 8 ?? WL 3:02PM 0:00.00 [swi3: vm] root 29 0.0 0.0 0 8 ?? WL 3:02PM 0:00.02 [swi1: net] root 30 0.0 0.0 0 8 ?? DL 3:02PM 0:00.17 [yarrow] root 31 0.0 0.0 0 8 ?? WL 3:02PM 0:00.12 [swi6: acpitaskq] root 32 0.0 0.0 0 8 ?? WL 3:02PM 0:00.00 [swi2: cambio] root 33 0.0 0.0 0 8 ?? WL 3:02PM 0:02.23 [swi6: task queue] root 34 0.0 0.0 0 8 ?? WL 3:02PM 0:00.00 [swi6:+] root 35 0.0 0.0 0 8 ?? WL 3:02PM 0:00.00 [swi5:+] root 36 0.0 0.0 0 8 ?? DL 3:02PM 0:00.00 [usb0] root 37 0.0 0.0 0 8 ?? DL 3:02PM 0:00.00 [usbtask] root 38 0.0 0.0 0 8 ?? DL 3:02PM 0:00.00 [usb1] root 39 0.0 0.0 0 8 ?? DL 3:02PM 0:00.00 [usb2] root 40 0.0 0.0 0 8 ?? DL 3:02PM 0:00.00 [usb3] root 42 0.0 0.0 0 8 ?? WL 3:02PM 0:00.00 [swi0: sio] root 43 0.0 0.0 0 8 ?? DL 3:02PM 0:00.00 [pagedaemon] root 44 0.0 0.0 0 8 ?? DL 3:02PM 0:00.00 [vmdaemon] root 45 0.0 0.0 0 8 ?? DL 3:02PM 0:00.61 [pagezero] root 46 0.0 0.0 0 8 ?? DL 3:02PM 0:00.01 [bufdaemon] root 47 0.0 0.0 0 8 ?? DL 3:02PM 0:00.01 [vnlru] root 48 0.0 0.0 0 8 ?? DL 3:02PM 0:00.18 [syncer] root 49 0.0 0.0 0 8 ?? DL 3:02PM 0:00.15 [schedcpu] root 241 0.0 0.1 1932 1308 ?? Is 3:02PM 0:00.03 /sbin/dhclient em0 ath0 root 293 0.0 0.0 536 380 ?? Is 3:02PM 0:00.00 /sbin/devd root 325 0.0 0.1 1452 936 ?? Ss 3:02PM 0:00.04 /usr/sbin/syslogd -s root 339 0.0 0.1 1492 1064 ?? Ss 3:02PM 0:00.00 /usr/sbin/rpcbind root 356 0.0 0.0 0 8 ?? DL 3:02PM 0:00.01 [md0] root 417 0.0 0.1 1348 836 ?? Ss 3:02PM 0:00.01 /usr/sbin/usbd root 439 0.0 0.1 1404 952 ?? Is 3:02PM 0:00.00 /usr/sbin/lpd root 467 0.0 0.1 1324 824 ?? Ss 3:02PM 0:03.04 /usr/sbin/powerd root 486 0.0 0.2 3160 2384 ?? Is 3:02PM 0:00.00 /usr/sbin/sshd root 506 0.0 0.1 1472 1096 ?? Ss 3:02PM 0:00.02 /usr/sbin/cron -s bind 525 0.0 0.3 4368 3272 ?? Ss 3:02PM 0:00.05 /usr/local/sbin/named -u bind -c /etc/named.conf mailnull 536 0.0 0.2 5880 3052 ?? Is 3:02PM 0:00.05 /usr/local/sbin/exim -bd -q1m (exim-4.50-1) root 576 0.0 0.1 3772 1940 ?? Ss 3:02PM 0:00.24 /usr/local/sbin/nmbd -D -s /usr/local/etc/smb.conf root 578 0.0 0.1 3724 1700 ?? I 3:02PM 0:00.00 /usr/local/sbin/nmbd -D -s /usr/local/etc/smb.conf root 581 0.0 0.2 5588 3020 ?? Is 3:02PM 0:00.00 /usr/local/sbin/smbd -D -s /usr/local/etc/smb.conf root 608 0.0 0.1 1348 744 ?? Ss 3:02PM 0:02.09 /usr/sbin/moused -3 -p /dev/psm0 -t auto root 611 0.0 0.2 5588 3020 ?? I 3:02PM 0:00.00 /usr/local/sbin/smbd -D -s /usr/local/etc/smb.conf randy 679 0.0 0.1 2856 1824 ?? Is 3:02PM 0:00.00 ssh-agent -s randy 688 0.0 0.1 1676 1084 ?? Is 3:03PM 0:00.01 esd -terminate -nobeeps -as 2 -spawnfd 18 root 634 0.0 0.1 1408 976 v2 Is+ 3:02PM 0:00.00 /usr/libexec/getty Pc ttyv2 root 635 0.0 0.1 1408 976 v3 Is+ 3:02PM 0:00.00 /usr/libexec/getty Pc ttyv3 root 636 0.0 0.1 1408 976 v4 Is+ 3:02PM 0:00.00 /usr/libexec/getty Pc ttyv4 root 637 0.0 0.1 1408 976 v5 Is+ 3:02PM 0:00.00 /usr/libexec/getty Pc ttyv5 root 632 0.0 0.1 1772 1392 v0 Is 3:02PM 0:00.24 login [pam] (login) randy 640 0.0 0.2 2416 2020 v0 I 3:02PM 0:00.14 -bash (bash) randy 653 0.0 0.1 1796 1264 v0 I+ 3:02PM 0:00.07 /bin/sh /usr/X11R6/bin/startx randy 663 0.0 0.1 2192 1336 v0 I+ 3:02PM 0:00.00 xinit /usr/home/randy/.xinitrc -- -nolisten tcp root 664 0.0 1.0 46612 12608 v0 I 3:02PM 0:01.40 X :0 -nolisten tcp (Xorg) randy 667 0.0 0.1 1796 1232 v0 I 3:02PM 0:00.00 sh /usr/home/randy/.xinitrc randy 680 0.0 0.7 17096 9728 v0 I 3:02PM 0:00.38 gnome-session randy 682 0.0 0.3 4748 3424 v0 S 3:02PM 0:00.54 /usr/X11R6/libexec/gconfd-2 5 randy 685 0.0 0.1 2984 1632 v0 I 3:02PM 0:00.01 /usr/X11R6/bin/gnome-keyring-daemon root 710 0.0 0.1 1772 1392 v1 Is 3:04PM 0:00.31 login [pam] (login) randy 711 0.0 0.2 2416 2032 v1 S 3:04PM 0:00.28 -bash (bash) randy 739 0.0 0.1 1556 980 v1 R+ 3:10PM 0:00.04 ps -auxw root 638 0.0 0.1 1408 976 v6 Is+ 3:02PM 0:00.00 /usr/libexec/getty Pc ttyv6 root 639 0.0 0.1 1408 976 v7 Is+ 3:02PM 0:00.00 /usr/libexec/getty Pc ttyv7 From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 21:04:12 2005 Return-Path: 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 EAE2116A4CE for ; Thu, 14 Apr 2005 21:04:12 +0000 (GMT) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9737E43D5C for ; Thu, 14 Apr 2005 21:04:12 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id 04F361F33F; Thu, 14 Apr 2005 23:04:12 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id E53E86271; Thu, 14 Apr 2005 23:04:11 +0200 (CEST) Date: Thu, 14 Apr 2005 23:04:11 +0200 From: Marc Olzheim To: freebsd-current@FreeBSD.org Message-ID: <20050414210411.GA7363@stack.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline User-Agent: Mutt/1.5.9i cc: Marc Olzheim Subject: LOR X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 14 Apr 2005 21:04:13 -0000 --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Today's CURRENT, during boot: boot ... Starting syslogd. Apr 14 17:26:22 office-install1 syslogd: kernel boot file is /boot/kernel/kernel NFS access cache time=2 lock order reversal 1st 0xc076cbc0 vm page queue mutex (vm page queue mutex) @ /usr/src/sys/kern/vfs_bio.c:1485 2nd 0xc1cabc58 vnode interlock (vnode interlock) @ /usr/src/sys/kern/vfs_subr.c:1993 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c0722088,c0720ad0,c06e75e8) at kdb_backtrace+0x29 witness_checkorder(c1cabc58,9,c06b564a,7c9) at witness_checkorder+0x550 _mtx_lock_flags(c1cabc58,0,c06b564a,7c9,c1c7c18c) at _mtx_lock_flags+0x5b vdrop(c1cabbdc) at vdrop+0x1d vm_page_remove(c173f1a0,c173f1a0) at vm_page_remove+0xd4 vm_page_free_toq(c173f1a0,c173f1a0,40,c173f1a0,dab40860) at vm_page_free_toq+0x90 vm_page_free(c173f1a0,c173f1a0) at vm_page_free+0x15 vfs_vmio_release(cbec8ae8) at vfs_vmio_release+0x9b brelse(cbec8ae8,2,0,25a,2) at brelse+0x485 softdep_setup_freeblocks(c1c6c108,0,0,800,c075ec88) at softdep_setup_freeblocks+0x7e4 ffs_truncate(c1cabbdc,0,0,800,c199c780,c1c13d80) at ffs_truncate+0x54e ufs_setattr(dab40b7c) at ufs_setattr+0x25d VOP_SETATTR_APV(c06f93a0,dab40b7c) at VOP_SETATTR_APV+0x7e kern_open(c1c13d80,8049756,0,402,1b6) at kern_open+0x662 open(c1c13d80,dab40d04,3,4,202) at open+0x1a syscall(3b,3b,3b,8,28149880) at syscall+0x213 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (5, FreeBSD ELF32, open), eip = 0x280b7953, esp = 0xbfbfed3c, ebp = 0xbfbfed68 --- ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/X11R6/lib /usr/local/lib /usr/local/lib/compat/pkg a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout /usr/X11R6/lib/aout Looks a bit like the counterpart of 081 (triggered by close()) to me. Marc --YiEDa0DAkWCtVeE4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCXtrLezjnobFOgrERAvdpAKC0AcFKk1qCowPM+zadjKbVuotDzACghqxb WQwpXFzVTZtsYIsoiVxyOg0= =cjBj -----END PGP SIGNATURE----- --YiEDa0DAkWCtVeE4-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 21:08:50 2005 Return-Path: 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 6589816A4CF for ; Thu, 14 Apr 2005 21:08:50 +0000 (GMT) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D3E743D39 for ; Thu, 14 Apr 2005 21:08:49 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j3EL8fEA011747 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 15 Apr 2005 07:08:47 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j3EL8f7l003678; Fri, 15 Apr 2005 07:08:41 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j3EL8eMZ003677; Fri, 15 Apr 2005 07:08:40 +1000 (EST) (envelope-from pjeremy) Date: Fri, 15 Apr 2005 07:08:40 +1000 From: Peter Jeremy To: Ted Unangst Message-ID: <20050414210840.GT89047@cirb503493.alcatel.com.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i cc: tech@openbsd.org cc: freebsd-current@freebsd.org Subject: Re: strtonum(3) in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 14 Apr 2005 21:08:50 -0000 On Wed, 2005-Apr-13 22:23:42 -0400, Ted Unangst wrote: >> Based on the man page, I see the following deficiencies: >> 1) No support for bases other than 10 > >it's meant for converting numbers, not addresses. if you want strtoaddr, >or strtomode_t, there's still strtol. the idea was to keep it simple. >most people think about sending 10 packets, not 0xa packets. The manpage states: "The strtonum function was designed to facilitate safe, robust programming and overcome the shortcomings of the atoi(3) and strtol(3) family of interfaces." This implies (to me anyway) that it is a replacement for strtol(), though it only implements a subset of strtol() functionality. >> 2) No provision to return the end of the converted string > >exactly, there's no need for it. strtonum is used to convert a "string >containing a number" not a "string containing a number optionally followed >by some other things which are not the number". if strlen() won't give >you want you want, it means the input is not appropriate for strtonum. This means you can't use it in a simple parser to handle the user entering "10k" to mean 10000 or "128m" to mean 128000000. dd(1) needs this and I've used it on occasion. Again, it's being sold as a replacement for strtol() but isn't. >> 3) No simple way to distinguish errors from a valid zero. > >check errstr. i updated the man page to clearly reflect the fact it will >be NULL on sucess, that was the original intention. I suspected so but that needs to be clearly documented. >do, what it wouldn't do, and how one would use it. you don't have to >agree with our decisions, but it sounds like you're descending in on >"strtol but not called strtol". I think strtonum() is a good atoi() family replacement. It's not a general replacement for strtol() but the man page doesn't distinguish between atoi() and strtol(). If the manpage stated that it was an atoi() replacement and only referenced strtol() as a side-note then my first two objections would vanish. Note that there are cases in the tree (I've found one in apmd(8)) where atoi() is passed a string that is known to have trailing non-numeric characters that should be ignored. Removing the trailing characters would make the lexer more complex. -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Thu Apr 14 22:30:34 2005 Return-Path: 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 74EAE16A4CE; Thu, 14 Apr 2005 22:30:34 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A577543D64; Thu, 14 Apr 2005 22:30:33 +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 j3EMUWMY047868; Thu, 14 Apr 2005 18:30:33 -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 j3EMUiuc040922; Thu, 14 Apr 2005 18:30:44 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id DA3987306E; Thu, 14 Apr 2005 18:30:32 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050414223032.DA3987306E@freebsd-current.sentex.ca> Date: Thu, 14 Apr 2005 18:30:32 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.82, clamav-milter version 0.82 on clamscanner4 X-Virus-Status: Clean Subject: [current tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2005 22:30:34 -0000 TB --- 2005-04-14 20:57:28 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-14 20:57:28 - starting CURRENT tinderbox run for i386/i386 TB --- 2005-04-14 20:57:28 - checking out the source tree TB --- 2005-04-14 20:57:28 - cd /home/tinderbox/CURRENT/i386/i386 TB --- 2005-04-14 20:57:28 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-14 21:04:10 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-14 21:04:10 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-04-14 21:04:10 - /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-04-14 22:12:54 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-14 22:12:54 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-04-14 22:12:54 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Apr 14 22:12:54 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 Thu Apr 14 22:30:31 UTC 2005 TB --- 2005-04-14 22:30:31 - generating LINT kernel config TB --- 2005-04-14 22:30:31 - cd /home/tinderbox/CURRENT/i386/i386/src/sys/i386/conf TB --- 2005-04-14 22:30:31 - /usr/bin/make -B LINT TB --- 2005-04-14 22:30:31 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-14 22:30:31 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-04-14 22:30:31 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Apr 14 22:30:31 UTC 2005 >>> stage 1: configuring the kernel -------------------------------------------------------------- cd /tinderbox/CURRENT/i386/i386/src/sys/i386/conf; PATH=/home/tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/tmp/legacy/usr/sbin:/home/tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/tmp/legacy/usr/bin:/home/tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/tmp/legacy/usr/games:/home/tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/tmp/usr/sbin:/home/tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/tmp/usr/bin:/home/tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /home/tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/sys/LINT /tinderbox/CURRENT/i386/i386/src/sys/i386/conf/LINT /tinderbox/CURRENT/i386/i386/src/sys/i386/conf/LINT: unknown option "NO_MIXED_MODE" *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. TB --- 2005-04-14 22:30:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-14 22:30:32 - ERROR: failed to build lint kernel TB --- 2005-04-14 22:30:32 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 05:07:37 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 84B0616A4CE; Fri, 15 Apr 2005 05:07:37 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.3/8.13.1) with ESMTP id j3F58LvX099651; Fri, 15 Apr 2005 01:08:21 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.3/8.13.1/Submit) id j3F58Lim099650; Fri, 15 Apr 2005 01:08:21 -0400 (EDT) (envelope-from green) Date: Fri, 15 Apr 2005 01:08:21 -0400 From: Brian Fundakowski Feldman To: hackers@freebsd.org, current@freebsd.org Message-ID: <20050415050821.GO981@green.homeunix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: NFS client/buffer cache deadlock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 05:07:37 -0000 I'll spare a lengthy write-up because I think the patch documents it well enough. It certainly appears to fix things here when doing very large block-sized writes, but it also reduces the throughput with those block sizes. (I don't think there should be any difference when using reasonable block sizes). Would anyone care to take a shot at fixing it in a more elegant manner? Index: sys/buf.h =================================================================== RCS file: /export/ncvs/src/sys/sys/buf.h,v retrieving revision 1.167.2.1 diff -u -r1.167.2.1 buf.h --- sys/buf.h 31 Jan 2005 23:26:55 -0000 1.167.2.1 +++ sys/buf.h 15 Apr 2005 02:00:44 -0000 @@ -469,6 +469,7 @@ extern int maxswzone; /* Max KVA for swap structures */ extern int maxbcache; /* Max KVA for buffer cache */ extern int runningbufspace; +extern int hibufspace; extern int buf_maxio; /* nominal maximum I/O for buffer */ extern struct buf *buf; /* The buffer headers. */ extern char *buffers; /* The buffer contents. */ Index: kern/vfs_bio.c =================================================================== RCS file: /export/ncvs/src/sys/kern/vfs_bio.c,v retrieving revision 1.444.2.2 diff -u -r1.444.2.2 vfs_bio.c --- kern/vfs_bio.c 31 Jan 2005 23:26:18 -0000 1.444.2.2 +++ kern/vfs_bio.c 15 Apr 2005 01:59:38 -0000 @@ -113,7 +113,7 @@ static int lobufspace; SYSCTL_INT(_vfs, OID_AUTO, lobufspace, CTLFLAG_RD, &lobufspace, 0, "Minimum amount of buffers we want to have"); -static int hibufspace; +int hibufspace; SYSCTL_INT(_vfs, OID_AUTO, hibufspace, CTLFLAG_RD, &hibufspace, 0, "Maximum allowed value of bufspace (excluding buf_daemon)"); static int bufreusecnt; Index: nfsclient/nfs_bio.c =================================================================== RCS file: /export/ncvs/src/sys/nfsclient/nfs_bio.c,v retrieving revision 1.133.2.2 diff -u -r1.133.2.2 nfs_bio.c --- nfsclient/nfs_bio.c 31 Jan 2005 23:26:46 -0000 1.133.2.2 +++ nfsclient/nfs_bio.c 15 Apr 2005 04:41:13 -0000 @@ -726,6 +726,7 @@ struct vattr vattr; struct nfsmount *nmp = VFSTONFS(vp->v_mount); daddr_t lbn; + off_t commitleft; int bcount; int n, on, error = 0; int haverslock = 0; @@ -755,6 +756,7 @@ */ if (ioflag & (IO_APPEND | IO_SYNC)) { if (np->n_flag & NMODIFIED) { +flush_and_restart: np->n_attrstamp = 0; error = nfs_vinvalbuf(vp, V_SAVE, cred, td, 1); if (error) @@ -832,12 +834,65 @@ } biosize = vp->v_mount->mnt_stat.f_iosize; + commitleft = 0; + /* + * If there are possible modifications, then there may be some + * B_NEEDCOMMIT buffers. Total those up here and force a flush + * before starting to write if our writes can exceed the local + * maximum per-file write commit size. + * + * If there are no possible pending modifications, we still need + * to limit our write to that size. + */ + if ((ioflag & (IO_SYNC | IO_INVAL)) != (IO_SYNC | IO_INVAL)) { + commitleft = nmp->nm_wcommitsize; + if (np->n_flag & NMODIFIED) { + int wouldcommit = 0; + VI_LOCK(vp); + TAILQ_FOREACH(bp, &vp->v_dirtyblkhd, b_vnbufs) { + if (bp->b_flags & B_NEEDCOMMIT) + wouldcommit += bp->b_bcount; + } + VI_UNLOCK(vp); + /* + * Since we're not operating synchronously and + * bypassing the buffer cache, we are in a commit + * and holding all of these buffers whether + * transmitted or not. If not limited, this + * will lead to the buffer cache deadlocking, + * as no one else can flush our uncommitted buffers. + */ + wouldcommit += uio->uio_resid; + /* + * If we would initially exceed the maximum + * outstanding write commit size, flush and restart. + */ + if (wouldcommit > commitleft) { + if (haverslock) { + nfs_rsunlock(np, td); + haverslock = 0; + } + goto flush_and_restart; + } + } else { + /* + * With no outstanding commits, we are limited only + * by commitleft as to how far we can go. + */ + } + } do { nfsstats.biocache_writes++; lbn = uio->uio_offset / biosize; on = uio->uio_offset & (biosize-1); n = min((unsigned)(biosize - on), uio->uio_resid); + /* Always allow at least one write. */ + if (commitleft > 0) { + commitleft -= n; + if (commitleft == 0) + commitleft = -1; + } again: /* * Handle direct append and file extension cases, calculate @@ -932,12 +987,6 @@ break; } } - if (!bp) { - error = nfs_sigintr(nmp, NULL, td); - if (!error) - error = EINTR; - break; - } if (bp->b_wcred == NOCRED) bp->b_wcred = crhold(cred); np->n_flag |= NMODIFIED; @@ -1036,7 +1085,7 @@ } else { bdwrite(bp); } - } while (uio->uio_resid > 0 && n > 0); + } while (uio->uio_resid > 0 && n > 0 && commitleft >= 0); if (haverslock) nfs_rsunlock(np, td); Index: nfsclient/nfs_vfsops.c =================================================================== RCS file: /export/ncvs/src/sys/nfsclient/nfs_vfsops.c,v retrieving revision 1.158.2.3 diff -u -r1.158.2.3 nfs_vfsops.c --- nfsclient/nfs_vfsops.c 31 Jan 2005 23:26:46 -0000 1.158.2.3 +++ nfsclient/nfs_vfsops.c 15 Apr 2005 02:03:05 -0000 @@ -41,6 +41,8 @@ #include #include #include +#include +#include #include #include #include @@ -625,6 +627,12 @@ else nmp->nm_readahead = NFS_MAXRAHEAD; } + if ((argp->flags & NFSMNT_WCOMMITSIZE) && argp->wcommitsize >= 0) { + if (argp->wcommitsize < nmp->nm_wsize) + nmp->nm_wcommitsize = nmp->nm_wsize; + else + nmp->nm_wcommitsize = argp->wcommitsize; + } if ((argp->flags & NFSMNT_DEADTHRESH) && argp->deadthresh >= 0) { if (argp->deadthresh <= NFS_MAXDEADTHRESH) nmp->nm_deadthresh = argp->deadthresh; @@ -785,6 +793,7 @@ nmp->nm_wsize = NFS_WSIZE; nmp->nm_rsize = NFS_RSIZE; } + nmp->nm_wcommitsize = hibufspace / (desiredvnodes / 1000); nmp->nm_readdirsize = NFS_READDIRSIZE; nmp->nm_numgrps = NFS_MAXGRPS; nmp->nm_readahead = NFS_DEFRAHEAD; Index: nfsclient/nfsargs.h =================================================================== RCS file: /export/ncvs/src/sys/nfsclient/nfsargs.h,v retrieving revision 1.66.2.1 diff -u -r1.66.2.1 nfsargs.h --- nfsclient/nfsargs.h 31 Jan 2005 23:26:46 -0000 1.66.2.1 +++ nfsclient/nfsargs.h 15 Apr 2005 01:33:08 -0000 @@ -56,7 +56,7 @@ int retrans; /* times to retry send */ int maxgrouplist; /* Max. size of group list */ int readahead; /* # of blocks to readahead */ - int __pad1; /* was "leaseterm" */ + int wcommitsize; /* Max. write commit size in bytes */ int deadthresh; /* Retrans threshold */ char *hostname; /* server's name */ int acregmin; /* cache attrs for reg files min time */ @@ -80,7 +80,7 @@ #define NFSMNT_NFSV3 0x00000200 /* Use NFS Version 3 protocol */ /* 0x400 free, was NFSMNT_KERB */ #define NFSMNT_DUMBTIMR 0x00000800 /* Don't estimate rtt dynamically */ -/* 0x1000 free, was NFSMNT_LEASETERM */ +#define NFSMNT_WCOMMITSIZE 0x00001000 /* set max write commit size */ #define NFSMNT_READAHEAD 0x00002000 /* set read ahead */ #define NFSMNT_DEADTHRESH 0x00004000 /* set dead server retry thresh */ #define NFSMNT_RESVPORT 0x00008000 /* Allocate a reserved port */ Index: nfsclient/nfsmount.h =================================================================== RCS file: /export/ncvs/src/sys/nfsclient/nfsmount.h,v retrieving revision 1.27.2.1 diff -u -r1.27.2.1 nfsmount.h --- nfsclient/nfsmount.h 31 Jan 2005 23:26:46 -0000 1.27.2.1 +++ nfsclient/nfsmount.h 15 Apr 2005 01:21:57 -0000 @@ -66,6 +66,7 @@ int nm_wsize; /* Max size of write rpc */ int nm_readdirsize; /* Size of a readdir rpc */ int nm_readahead; /* Num. of blocks to readahead */ + int nm_wcommitsize; /* Max size of commit for write */ int nm_acdirmin; /* Directory attr cache min lifetime */ int nm_acdirmax; /* Directory attr cache max lifetime */ int nm_acregmin; /* Reg file attr cache min lifetime */ -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 09:28:20 2005 Return-Path: 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 2EDD416A4CE; Fri, 15 Apr 2005 09:28:20 +0000 (GMT) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE8C843D41; Fri, 15 Apr 2005 09:28:19 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (localhost [127.0.0.1]) j3F9SGik089682; Fri, 15 Apr 2005 05:28:16 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)j3F9SFp5089679; Fri, 15 Apr 2005 05:28:16 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Fri, 15 Apr 2005 05:28:15 -0400 (EDT) From: Andre Guibert de Bruet To: Pawel Jakub Dawidek In-Reply-To: <20050409132401.GZ837@darkness.comp.waw.pl> Message-ID: <20050415052644.H93987@lexi.siliconlandmark.com> References: <20050409132401.GZ837@darkness.comp.waw.pl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Information: Please contact the ISP for more information X-SL-MailScanner: Found to be clean X-SL-SpamCheck: not spam, SpamAssassin (score=-2.515, required 6, autolearn=not spam, AWL 0.08, BAYES_00 -2.60) X-MailScanner-From: andy@siliconlandmark.com cc: freebsd-current@freebsd.org Subject: Re: LOR: vm page queue mutex -> vnode interlock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 09:28:20 -0000 On Sat, 9 Apr 2005, Pawel Jakub Dawidek wrote: > I get this LOR on boot (this is diskless machine): > > 1st 0xc068f940 vm page queue mutex (vm page queue mutex) @ /usr/src/HEAD/src/sys/kern/vfs_bio.c:1485 > 2nd 0xc127da30 vnode interlock (vnode interlock) @ /usr/src/HEAD/src/sys/kern/vfs_subr.c:1989 "Me too", with today's sources. Cheers, Andy | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 10:03:20 2005 Return-Path: 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 7CD2116A4CE; Fri, 15 Apr 2005 10:03:20 +0000 (GMT) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id E07C043D2D; Fri, 15 Apr 2005 10:03:19 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (localhost [127.0.0.1]) j3FA3AJf089902; Fri, 15 Apr 2005 06:03:10 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)j3FA2w64089899; Fri, 15 Apr 2005 06:02:58 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Fri, 15 Apr 2005 06:02:58 -0400 (EDT) From: Andre Guibert de Bruet To: Giorgos Keramidas In-Reply-To: <20050413141957.GA40546@orion.daedalusnetworks.priv> Message-ID: <20050415055604.N93987@lexi.siliconlandmark.com> References: <425CC7F8.3030803@samsco.org> <425D2163.4090603@freebsd.org> <20050413141957.GA40546@orion.daedalusnetworks.priv> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Information: Please contact the ISP for more information X-SL-MailScanner: Found to be clean X-SL-SpamCheck: not spam, SpamAssassin (score=-2.515, required 6, autolearn=not spam, AWL 0.08, BAYES_00 -2.60) X-MailScanner-From: andy@siliconlandmark.com cc: freebsd-current@freebsd.org cc: Anthony Ginepro cc: Jiawei Ye cc: David Xu Subject: Re: How does one know how many thread a process owns? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 10:03:20 -0000 On Wed, 13 Apr 2005, Giorgos Keramidas wrote: > On 2005-04-13 16:08, Anthony Ginepro wrote: >> On 04/13/05 21:40, David Xu wrote: >>> Giorgos Keramidas wrote: >>>> Can you try the following patch? >>> >>> I am using the patch, it works fine, the screen output is attractive. :-) >> >> Except for WCPU it looks like SunOS' top. > > /me thinks (Oops, they caught me!) > > Yes, I have to admit, I used the output of SunOS top as an inspiration > for the ordering and naming of the THR column :-) Please commit the following patch which unbreaks the display problems which appear on 80-column terminals with the THR column (The D would wrap and cause weird behavior): Index: machine.c =================================================================== RCS file: /home/ncvs/src/usr.bin/top/machine.c,v retrieving revision 1.70 diff -r1.70 machine.c 106c106 < " PID %-*.*s THR PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND"; --- > " PID %-*.*s THR PRI NICE SIZE RES STATE C TIME WCPU CPU CMD"; 114c114 < " PID %-*.*s THR PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND"; --- > " PID %-*.*s THR PRI NICE SIZE RES STATE TIME WCPU CPU CMD"; It is available online, for your convenience (Due to possible line-wrap issues with your MUA), at: http://bling.properkernel.com/freebsd/top.machine.c.patch Cheers, Andy | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 10:24:26 2005 Return-Path: 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 DC2DB16A4CE for ; Fri, 15 Apr 2005 10:24:26 +0000 (GMT) Received: from hydra.crashmail.de (hydra.crashmail.de [217.146.142.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DBB843D1D for ; Fri, 15 Apr 2005 10:24:26 +0000 (GMT) (envelope-from steve.tell@crashmail.de) Received: from zeus.crashmail.de (pD958B0C1.dip.t-dialin.net [217.88.176.193]) by hydra.crashmail.de (Postfix) with ESMTP id 65A582EE30 for ; Fri, 15 Apr 2005 12:24:04 +0200 (CEST) Received: from pandora.crashmail.de (pandora.crashmail.de [192.168.1.20]) by zeus.crashmail.de (Postfix) with ESMTP id 6BD8B7FF5 for ; Fri, 15 Apr 2005 12:24:17 +0200 (CEST) To: freebsd-current@freebsd.org X-Face: .KSo,m`RE@]&5>cJ8vw<`1x?R(?,Q]b@qeq;P\.fK\}i>U^v9f; /~+rKfXKOJ$jD@Foy7MtnIpnk+6]/](%q@*/|+M<4.q@SO3+)u X-PGP-Key: 0x9B6C7E15 X-PGP-Fingerprint: 0A21 6C88 552E 54AE 3FB5 4732 25EE 6ABE 9B6C 7E15 Organization: The Third Place X-Linux-Version: Linux pandora 2.6.11.5 #1 Mon Apr 4 16:33:07 CEST 2005 i686 GNU/Linux X-Gentoo-Release: Gentoo Base System version 1.4.16 From: Stefan 'Steve' Tell Date: Fri, 15 Apr 2005 12:24:36 +0200 Message-ID: <87d5sw5od7.fsf@zeus.crashmail.de> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Palm Tungsten T via USB-Cradle X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 10:24:27 -0000 Hi, I tried to hotsync my Palm Tungsten T with a freebsd box, but I only got ,---- | Apr 7 18:40:25 pandora kernel: ucom0: Palm, Inc. Palm-Handheld, rev 1.10/1.00, addr 3 | Apr 7 18:40:25 pandora kernel: ucom0: Palm, Inc. Palm-Handheld, rev 1.10/1.00, addr 3 | Apr 7 18:40:30 pandora kernel: ucom0: init failed, TIMEOUT | Apr 7 18:40:30 pandora kernel: device_attach: ucom0 attach returned 6 | Apr 7 18:40:30 pandora kernel: uhub1: port 1, set config at addr 3 failed | Apr 7 18:40:30 pandora kernel: uhub1: device problem (STALLED), disabling port 1 `---- Searching at google found pr kern/66547[1]. I have this problem with a Freebsd 4.10, with a FreeBSD 5.4-BETA1 and with my 6.0-CURRENT (checked out on 15.04.2005, 06:oo), too. uvisor(4) and ucom(4) are compiled into the kernels. The Palm Tungsten T should be working on FreeBSD-Current[2]. But I think it does not. Footnotes: ---------- [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=66547 [2] http://www.freebsd.org/relnotes/CURRENT/hardware/i386/article.html#USB -- By(t)e, Steve /\ http://www.crashmail.de GnuPG/PGP: 0X9B6C7E15, encrypted mail prefered, see header From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 10:48:24 2005 Return-Path: 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 F40F116A4CE; Fri, 15 Apr 2005 10:48:23 +0000 (GMT) Received: from kane.otenet.gr (kane.otenet.gr [195.170.0.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id E410843D49; Fri, 15 Apr 2005 10:48:20 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from orion.daedalusnetworks.priv (aris.bedc.ondsl.gr [62.103.39.226])j3FAlEdv025563; Fri, 15 Apr 2005 13:47:17 +0300 Received: from orion.daedalusnetworks.priv (orion [127.0.0.1]) j3FAmGid005321; Fri, 15 Apr 2005 13:48:16 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost)j3FAmEjt005320; Fri, 15 Apr 2005 13:48:14 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Fri, 15 Apr 2005 13:48:14 +0300 From: Giorgos Keramidas To: Andre Guibert de Bruet Message-ID: <20050415104814.GA5278@orion.daedalusnetworks.priv> References: <425CC7F8.3030803@samsco.org> <425CD009.6040208@freebsd.org> <20050413132603.GA39006@orion.daedalusnetworks.priv> <425D2163.4090603@freebsd.org> <20050413140838.GA77217@renaissance.homeip.net> <20050413141957.GA40546@orion.daedalusnetworks.priv> <20050415055604.N93987@lexi.siliconlandmark.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050415055604.N93987@lexi.siliconlandmark.com> cc: freebsd-current@freebsd.org cc: Anthony Ginepro cc: Jiawei Ye cc: David Xu Subject: Re: How does one know how many thread a process owns? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 10:48:24 -0000 On 2005-04-15 06:02, Andre Guibert de Bruet wrote: > Please commit the following patch which unbreaks the display problems > which appear on 80-column terminals with the THR column (The D would wrap > and cause weird behavior): > > http://bling.properkernel.com/freebsd/top.machine.c.patch This seems reasonable. I only have UP machines, which don't need the change from COMMAND to CMD, but Andrey Chernov has already brought to my attention that adding the THR column broke the listing in SMP machines. David, do you think it's ok to change s/COMMAND/CMD/ or is that too silly to do to fit THR in there? I can probably reduce the columns of THR to 4 too, since I noticed that after 1500 threads the value of THR doesn't increase anymore here; so, being able to display up to 9999 threads is ok I guess. From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 11:17:05 2005 Return-Path: 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 54C6116A4CE; Fri, 15 Apr 2005 11:17:05 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3290943D49; Fri, 15 Apr 2005 11:17:05 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j3FBGxWj072892; Fri, 15 Apr 2005 11:17:01 GMT (envelope-from davidxu@freebsd.org) Message-ID: <425FA2AB.4070905@freebsd.org> Date: Fri, 15 Apr 2005 19:16:59 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050306 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Giorgos Keramidas References: <425CC7F8.3030803@samsco.org> <425CD009.6040208@freebsd.org> <20050413132603.GA39006@orion.daedalusnetworks.priv> <425D2163.4090603@freebsd.org> <20050413140838.GA77217@renaissance.homeip.net> <20050413141957.GA40546@orion.daedalusnetworks.priv> <20050415055604.N93987@lexi.siliconlandmark.com> <20050415104814.GA5278@orion.daedalusnetworks.priv> In-Reply-To: <20050415104814.GA5278@orion.daedalusnetworks.priv> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: Anthony Ginepro cc: Jiawei Ye Subject: Re: How does one know how many thread a process owns? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 11:17:05 -0000 Giorgos Keramidas wrote: >On 2005-04-15 06:02, Andre Guibert de Bruet wrote: > > >>Please commit the following patch which unbreaks the display problems >>which appear on 80-column terminals with the THR column (The D would wrap >>and cause weird behavior): >> >>http://bling.properkernel.com/freebsd/top.machine.c.patch >> >> > >This seems reasonable. I only have UP machines, which don't need the change >from COMMAND to CMD, but Andrey Chernov has already brought to my attention >that adding the THR column broke the listing in SMP machines. > >David, do you think it's ok to change s/COMMAND/CMD/ or is that too silly to >do to fit THR in there? I can probably reduce the columns of THR to 4 too, >since I noticed that after 1500 threads the value of THR doesn't increase >anymore here; so, being able to display up to 9999 threads is ok I guess. > > > I think we should change THR columns to 4, 9999 threads is okay for me. From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 11:20:31 2005 Return-Path: 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 1A63616A4CE; Fri, 15 Apr 2005 11:20:31 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F24A43D2F; Fri, 15 Apr 2005 11:20:30 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id 3B3BDACC29; Fri, 15 Apr 2005 13:20:28 +0200 (CEST) Date: Fri, 15 Apr 2005 13:20:28 +0200 From: Pawel Jakub Dawidek To: freebsd-current@FreeBSD.org Message-ID: <20050415112028.GI837@darkness.comp.waw.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+k3B0vOyg/ewl1oH" Content-Disposition: inline User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: jeff@FreeBSD.org Subject: Panic on boot (diskless): locking against myself. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 11:20:31 -0000 --+k3B0vOyg/ewl1oH Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable HEAD from now. The backtrace: Trying to mount root from nfs:10.0.0.2:/usr/diskless/lcfpxe panic: lockmgr: locking against myself KDB: enter: panic [thread pid 1 tid 100007 ] Stopped at kdb_enter+0x2b: nop =20 db> tr Tracing pid 1 tid 100007 td 0xc1e83480 kdb_enter(c059a6ac) at kdb_enter+0x2b panic(c0598a32,c1e83480,0,e95e068c,c2118000) at panic+0xbb lockmgr(c2118058,3002,c211807c,c1e83480,e95e066c) at lockmgr+0x3ba vop_stdlock(e95e068c) at vop_stdlock+0x1e VOP_LOCK_APV(c05ba4a0,e95e068c) at VOP_LOCK_APV+0x7e vn_lock(c2118000,1002,c1e83480) at vn_lock+0x101 lookup(e95e09d4,1000,1,c1e83480,c052f934) at lookup+0xce namei(e95e09d4,0,0,c1e83480,0) at namei+0x356 vn_open_cred(e95e09d4,e95e08b0,0,c1e80c80,ffffffff) at vn_open_cred+0x278 vn_open(e95e09d4,e95e08b0,0,ffffffff) at vn_open+0x1e linker_hints_lookup(c05bde60,c,c20f31b0,3,0) at linker_hints_lookup+0x109 linker_search_module(c20f31b0,3,0,c047afba,c20f31b0) at linker_search_modul= e+0x43 linker_load_module(0,c20f31b0,0,0,e95e0a98) at linker_load_module+0x80 vfs_byname_kld(c20f31b0,c1e83480,e95e0ad0,0,0) at vfs_byname_kld+0x64 vfs_domount(c1e83480,c20f31b0,c20f31c0,4001,c1f93470) at vfs_domount+0x421 vfs_donmount(c1e83480,4001,e95e0c28,c20f2200,6) at vfs_donmount+0xce kernel_mount(c1f938b0,4001,e95e0c90,e95e0cbc,c04c6cc6) at kernel_mount+0x6d kernel_vmount(4001,c05a0c31,c20f3b80,c05a0c38,c05987fb) at kernel_vmount+0x= 37 vfs_mountroot_try(c1f9ee80,c1e82de4,c04586fc,0,e95e0d0c) at vfs_mountroot_t= ry+0xd2 vfs_mountroot(c1e82de4,c1e83480,0,c1e83480,e95e0cf8) at vfs_mountroot+0x153 start_init(0,e95e0d38,0,c04586fc,0) at start_init+0x4b fork_exit(c04586fc,0,e95e0d38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip =3D 0, esp =3D 0xe95e0d6c, ebp =3D 0 --- --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --+k3B0vOyg/ewl1oH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFCX6N8ForvXbEpPzQRApbTAKD0llhkyjvebCNDf/ltRY/++ek5MwCgn8dM n6z08ZyGjGf/qImeA28cRCo= =S6U5 -----END PGP SIGNATURE----- --+k3B0vOyg/ewl1oH-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 11:42:17 2005 Return-Path: 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 50A3A16A4CE; Fri, 15 Apr 2005 11:42:14 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D9D243D2F; Fri, 15 Apr 2005 11:42:13 +0000 (GMT) (envelope-from max@love2party.net) Received: from p54A3E7B8.dip.t-dialin.net[84.163.231.184] (helo=donor.laier.local) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0MKwpI-1DMPD90U9p-0006Bg; Fri, 15 Apr 2005 13:42:11 +0200 From: Max Laier To: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Date: Fri, 15 Apr 2005 13:42:00 +0200 User-Agent: KMail/1.8 References: <200504080220.57899.max@love2party.net> <4256F545.90401@elischer.org> In-Reply-To: <4256F545.90401@elischer.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1332277.2M6x2ijGPT"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504151342.07851.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 cc: monthly@freebsd.org Subject: Re: Call for FreeBSD status reports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 11:42:17 -0000 --nextPart1332277.2M6x2ijGPT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All, as I wrote last week: > Submissions are due on April 15. Thanks a lot, and we are hoping for a > big turn-out. As always this is not final, but please get your reports ready by monday an= d=20 maybe let us know that you are planing to submit. Unfortunately we have a= =20 dramatically lower turn-out so far, I hope to see more reports floating in= =20 over the weekend. Thanks a lot! http://www.FreeBSD.org/news/status/ =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1332277.2M6x2ijGPT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCX6iPXyyEoT62BG0RAv19AJwKSD5FgE/za881kHA8deU358C1PQCfSJ+M BtrsjPBHzW53uyb09Cau96M= =hgZ7 -----END PGP SIGNATURE----- --nextPart1332277.2M6x2ijGPT-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 11:50:10 2005 Return-Path: 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 1AB4316A4CF; Fri, 15 Apr 2005 11:50:10 +0000 (GMT) Received: from aiolos.otenet.gr (aiolos.otenet.gr [195.170.0.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 17C5B43D2F; Fri, 15 Apr 2005 11:50:09 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from orion.daedalusnetworks.priv (aris.bedc.ondsl.gr [62.103.39.226])j3FBn3NO025229; Fri, 15 Apr 2005 14:49:03 +0300 Received: from orion.daedalusnetworks.priv (orion [127.0.0.1]) j3FBo6GD005903; Fri, 15 Apr 2005 14:50:06 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost)j3FBo5sk005902; Fri, 15 Apr 2005 14:50:05 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Fri, 15 Apr 2005 14:50:05 +0300 From: Giorgos Keramidas To: David Xu Message-ID: <20050415115005.GA5866@orion.daedalusnetworks.priv> References: <425CC7F8.3030803@samsco.org> <425CD009.6040208@freebsd.org> <20050413132603.GA39006@orion.daedalusnetworks.priv> <425D2163.4090603@freebsd.org> <20050413140838.GA77217@renaissance.homeip.net> <20050413141957.GA40546@orion.daedalusnetworks.priv> <20050415055604.N93987@lexi.siliconlandmark.com> <20050415104814.GA5278@orion.daedalusnetworks.priv> <425FA2AB.4070905@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <425FA2AB.4070905@freebsd.org> cc: freebsd-current@freebsd.org cc: Anthony Ginepro cc: Jiawei Ye Subject: Re: How does one know how many thread a process owns? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 11:50:10 -0000 On 2005-04-15 19:16, David Xu wrote: >Giorgos Keramidas wrote: >>On 2005-04-15 06:02, Andre Guibert de Bruet wrote: >>>Please commit the following patch which unbreaks the display problems >>>which appear on 80-column terminals with the THR column (The D would >>>wrap and cause weird behavior): >>> >>>http://bling.properkernel.com/freebsd/top.machine.c.patch >> >>David, do you think it's ok to change s/COMMAND/CMD/ or is that too >>silly to do to fit THR in there? I can probably reduce the columns of >>THR to 4 too, since I noticed that after 1500 threads the value of THR >>doesn't increase anymore here; so, being able to display up to 9999 >>threads is ok I guess. > > I think we should change THR columns to 4, > 9999 threads is okay for me. I just checked what top does on SunOS, when a program has more than 999 threads and it seems to clip the number of threads to 999, as if something min(999, numthreads) is what is printed :-) I'll change the width of THR to 4 columns if that's enough to fix the wrapping issue of COMMAND, or even to 3 if that is not enough. Clipping the value of numthreads to something less than or equal to 999 is also a relatively good idea that shouldn't be too hard to implement. From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 12:02:24 2005 Return-Path: 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 A48A316A4CE for ; Fri, 15 Apr 2005 12:02:24 +0000 (GMT) Received: from ns.cygnus.de (ns.cygnus.de [194.221.99.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 500F143D2F for ; Fri, 15 Apr 2005 12:02:23 +0000 (GMT) (envelope-from gth@cmex.de) Received: from [192.168.1.4] (p549978F6.dip.t-dialin.net [84.153.120.246]) j3FCIO802742 for ; Fri, 15 Apr 2005 14:18:24 +0200 X-Authentication-Warning: ns.cygnus.de: Host p549978F6.dip.t-dialin.net [84.153.120.246] claimed to be [192.168.1.4] From: Gunther Thiel To: freebsd-current@freebsd.org Message-Id: <1113566521.25223.41.camel@darthvader> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 15 Apr 2005 14:02:02 +0200 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Stackable Filesystems/deadlock/VI_DOOMED X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 12:02:24 -0000 Had posted this one to freebsd-fs but there is apparently not too much going on. So, am retrying it here. I am working on stackable filesystems using 5.3-STABLE and figured that there are still deadlock problems when using the nullfs template on a busy, stressed machine. >From what I have experienced, apparently the deadlock occurs when trying to get a new node while it's being recycled. What I have seen in the VFS code of the CURRENT branch looks very promising (VI_DOOMED instead of VI_XLOCK!), but as I have no clue when new VFS stuff will be in a solid state, I wanted to ask if the problem is at all solveable with the VFS concept under 5.3 and if so, how. If it is not solveable (which is my personal guess) would someone mind giving me a hint on dependencies when I would only like to use as much stuff from CURRENT to move to new VFS concept (with all the ostentatious risks)? Thanks very much! Gunther From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 00:58:35 2005 Return-Path: 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 C9ADF16A4CE for ; Fri, 15 Apr 2005 00:58:35 +0000 (GMT) Received: from mail.codefusionis.com (ns.codefusionis.com [208.33.29.188]) by mx1.FreeBSD.org (Postfix) with SMTP id 06FBF43D31 for ; Fri, 15 Apr 2005 00:58:35 +0000 (GMT) (envelope-from tedu@zeitbombe.org) Received: (qmail 24059 invoked by uid 1049); 15 Apr 2005 01:01:26 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 15 Apr 2005 01:01:26 -0000 Date: Thu, 14 Apr 2005 21:01:26 -0400 (EDT) From: Ted Unangst X-X-Sender: tedu@ns.codefusionis.com To: Peter Jeremy In-Reply-To: <20050414210840.GT89047@cirb503493.alcatel.com.au> Message-ID: References: <20050414210840.GT89047@cirb503493.alcatel.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Fri, 15 Apr 2005 12:07:22 +0000 cc: tech@openbsd.org cc: freebsd-current@freebsd.org Subject: Re: strtonum(3) in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 00:58:35 -0000 On Fri, 15 Apr 2005, Peter Jeremy wrote: > The manpage states: > "The strtonum function was designed to facilitate safe, robust > programming and overcome the shortcomings of the atoi(3) and > strtol(3) family of interfaces." > This implies (to me anyway) that it is a replacement for strtol(), > though it only implements a subset of strtol() functionality. yes, to make it simpler. > This means you can't use it in a simple parser to handle the user > entering "10k" to mean 10000 or "128m" to mean 128000000. dd(1) needs > this and I've used it on occasion. Again, it's being sold as a > replacement for strtol() but isn't. pop quiz! quick, how big is the file created by running "dd if=/dev/zero of=foo count=0x013b0x013b"? no credit if you have to run the command to find out. :) that's the kind of weirdness strtonum is designed to prevent. of course, if you want the weirdness, strtonum is not for you. -- we don't run washington and no one really does From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 12:27:50 2005 Return-Path: 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 8183516A4CE for ; Fri, 15 Apr 2005 12:27:50 +0000 (GMT) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FEFA43D1F for ; Fri, 15 Apr 2005 12:27:50 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (localhost [127.0.0.1]) j3FCRhZB090766 for ; Fri, 15 Apr 2005 08:27:43 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)j3FCRhti090763 for ; Fri, 15 Apr 2005 08:27:43 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Fri, 15 Apr 2005 08:27:43 -0400 (EDT) From: Andre Guibert de Bruet To: current@freebsd.org Message-ID: <20050415063120.G93987@lexi.siliconlandmark.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Information: Please contact the ISP for more information X-SL-MailScanner: Found to be clean X-SL-SpamCheck: not spam, SpamAssassin (score=-2.516, required 6, autolearn=not spam, AWL 0.08, BAYES_00 -2.60) X-MailScanner-From: andy@siliconlandmark.com Subject: syscons joy: reproduceable panic on resolution change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 12:27:50 -0000 Hi, While attempting to change from 90x60 to VESA_132x60... Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x20:0xc051d257 stack pointer = 0x28:0xe900ca18 frame pointer = 0x28:0xe900ca38 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 85 (swi4: clock sio) [thread pid 85 tid 100076 ] Stopped at _mtx_lock_flags+0x47: cmpl $0xc0708208,0(%ebx) db> tr Tracing pid 85 tid 100076 td 0xc5014d80 _mtx_lock_flags(0,0,c06e611e,127,e900cac4) at _mtx_lock_flags+0x47 vm_fault(c1059000,c0100000,2,0,c5014d80) at vm_fault+0x28e trap_pfault(e900cb9c,0,c0100000,2,c0100000) at trap_pfault+0x166 trap(c5010008,28,c0530028,c0100000,c7084000) at trap+0x350 calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc06919b6, esp = 0xe900cbdc, ebp = 0xe900cc00 --- generic_bcopy(c537c828,0,c537c80c,0,c0000,c06d240e,18a) at generic_bcopy+0x1a vga_txtdraw(c537c800,0,c0000,0,5cbf1d40) at vga_txtdraw+0xee scrn_update(c537c800,1,c0730120,8,c06d4127) at scrn_update+0x2b2 scrn_timer(c50d7000,0,c06d4127,107,c067317d) at scrn_timer+0x239 softclock(0,0,c06d0909,256,c07300e0) at softclock+0x242 ithread_loop(c5018400,e900cd38,c06d06f4,30c,c5018400) at ithread_loop+0x159 fork_exit(c0510b8f,c5018400,e900cd38) at fork_exit+0xc2 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe900cd6c, ebp = 0 --- db> ps -- snip-- 85 c50367f0 0 0 0 000020c [CPU 0] swi4: clock sio -- snip -- I have both the debug kernel and a 3.5GB memory dump on hand, in case there is additional information that I haven't listed in this email that may aid in fixing this issue. The EIP points to: (gdb) l *0xc051d257 0xc051d257 is in _mtx_lock_flags (/usr/src/sys/kern/kern_mutex.c:268). 263 void 264 _mtx_lock_flags(struct mtx *m, int opts, const char *file, int line) 265 { 266 267 MPASS(curthread != NULL); 268 KASSERT(m->mtx_object.lo_class == &lock_class_mtx_sleep, 269 ("mtx_lock() of spin mutex %s @ %s:%d", m->mtx_object.lo_name, 270 file, line)); 271 WITNESS_CHECKORDER(&m->mtx_object, opts | LOP_NEWORDER | LOP_EXCLUSIVE, 272 file, line); (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc0526951 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:397 #2 0xc0526cdd in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:553 #3 0xc045026d in db_fncall (dummy1=1016, dummy2=0, dummy3=3, dummy4=0xe900c820 "\f") at /usr/src/sys/ddb/db_command.c:531 #4 0xc045001c in db_command (last_cmdp=0xc0728064, cmd_table=0x0, aux_cmd_tablep=0xc06f2678, aux_cmd_tablep_end=0xc06f267c) at /usr/src/sys/ddb/db_command.c:349 #5 0xc045010d in db_command_loop () at /usr/src/sys/ddb/db_command.c:455 #6 0xc0451f9d in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:221 #7 0xc05432f5 in kdb_trap (type=0, code=0, tf=0xe900c9d8) at /usr/src/sys/kern/subr_kdb.c:421 #8 0xc0693d09 in trap_fatal (frame=0xe900c9d8, eva=0) at /usr/src/sys/i386/i386/trap.c:801 #9 0xc0693a18 in trap_pfault (frame=0xe900c9d8, usermode=0, eva=0) at /usr/src/sys/i386/i386/trap.c:724 #10 0xc06935f8 in trap (frame= {tf_fs = -1068433400, tf_es = -1056636888, tf_ds = 40, tf_edi = -1066508002, tf_esi = 295, tf_ebp = -385824200, tf_isp = -385824252, tf_ebx = 0, tf_edx = 7, tf_ecx = -385824056, tf_eax = -989770368, tf_trapno = 12, tf_err = 0, tf_eip = -1068379561, tf_cs = 32, tf_eflags = 66178, tf_esp = -1067131464, tf_ss = -1056600064}) at /usr/src/sys/i386/i386/trap.c:414 #11 0xc067f91a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #12 0xc0510008 in idle_setup (dummy=0x0) at /usr/src/sys/kern/kern_idle.c:89 #13 0xc0645d6e in vm_fault (map=0xc1059000, vaddr=3222274048, fault_type=2 '\002', fault_flags=0) at /usr/src/sys/vm/vm_fault.c:295 #14 0xc06939c4 in trap_pfault (frame=0xe900cb9c, usermode=0, eva=3222274048) at /usr/src/sys/i386/i386/trap.c:713 #15 0xc06935f8 in trap (frame= {tf_fs = -989790200, tf_es = 40, tf_ds = -1068302296, tf_edi = -1072693248, tf_esi = -955760640, tf_ebp = -385823744, tf_isp = -385823800, tf_ebx = -1072988160, tf_edx = 1572864, tf_ecx = 319488, tf_eax = -116932608, tf_trapno = 12, tf_err = 3, tf_eip = -1066853962, tf_cs = 32, tf_eflags = 66054, tf_esp = 0, tf_ss = -986200024}) at /usr/src/sys/i386/i386/trap.c:414 #16 0xc067f91a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #17 0xc5010008 in ?? () #18 0x00000028 in ?? () #19 0xc0530028 in ogetkerninfo (td=0xc537c828, uap=0xc0100000) at /usr/src/sys/kern/kern_sysctl.c:1440 #20 0xc066da8c in vga_txtdraw (scp=0xc537c800, from=0, count=786432, flip=0) at /usr/src/sys/dev/syscons/scvgarndr.c:196 #21 0xc0673723 in scrn_update (scp=0xc537c800, show_cursor=1) at /usr/src/sys/dev/syscons/syscons.c:1803 #22 0xc06733b6 in scrn_timer (arg=0x0) at /usr/src/sys/dev/syscons/syscons.c:1708 #23 0xc053449e in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:295 #24 0xc0510ce8 in ithread_loop (arg=0xc5018400) at /usr/src/sys/kern/kern_intr.c:546 #25 0xc050fd7e in fork_exit (callout=0xc0510b8f , arg=0x0, frame=0x0) at /usr/src/sys/kern/kern_fork.c:788 #26 0xc067f97c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:208 It would appear that either frame 17 or 18 is the call to generic_bcopy. All sorts of miscellaneous information about the system, including kernel config file and bzip2-compressed kernel.debug, is available online at: http://bling.properkernel.com/freebsd/ The onboard VGA presents itself as follows: none6@pci8:12:0: class=0x030000 card=0x34398086 chip=0x47521002 rev=0x27 hdr=0x00 vendor = 'ATI Technologies Inc.' device = 'Rage XL PCI' class = display subclass = VGA Any ideas? Cheers, Andy | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 13:21:10 2005 Return-Path: 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 01D6A16A4CE; Fri, 15 Apr 2005 13:21:10 +0000 (GMT) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A1C543D49; Fri, 15 Apr 2005 13:21:09 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id 4A64B1F5AA; Fri, 15 Apr 2005 15:21:08 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id 310BE6347; Fri, 15 Apr 2005 15:21:08 +0200 (CEST) Date: Fri, 15 Apr 2005 15:21:08 +0200 From: Marc Olzheim To: Brian Fundakowski Feldman Message-ID: <20050415132108.GC85922@stack.nl> References: <20050415050821.GO981@green.homeunix.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hYooF8G/hrfVAmum" Content-Disposition: inline In-Reply-To: <20050415050821.GO981@green.homeunix.org> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i cc: hackers@freebsd.org cc: current@freebsd.org Subject: Re: NFS client/buffer cache deadlock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 13:21:10 -0000 --hYooF8G/hrfVAmum Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Apr 15, 2005 at 01:08:21AM -0400, Brian Fundakowski Feldman wrote: > I'll spare a lengthy write-up because I think the patch documents it well > enough. It certainly appears to fix things here when doing very large > block-sized writes, but it also reduces the throughput with those block > sizes. (I don't think there should be any difference when using reasonable > block sizes). Is this supposed to fix kern/79208 ? Marc --hYooF8G/hrfVAmum Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD4DBQFCX7/EezjnobFOgrERAoLmAJii/TuTg1aTOY8nktdo3d8UQM3gAJsHQT7r Ze2w/BMKz6HDJWrNgOT2dg== =moIe -----END PGP SIGNATURE----- --hYooF8G/hrfVAmum-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 14:11:35 2005 Return-Path: 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 11B5A16A4CE; Fri, 15 Apr 2005 14:11:35 +0000 (GMT) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E20643D41; Fri, 15 Apr 2005 14:11:33 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) (8.13.4/8.13.3) with ESMTP id j3FEBUFK063170 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 15 Apr 2005 16:11:30 +0200 (CEST) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.4/8.13.3/Submit) id j3FEBUGc063169; Fri, 15 Apr 2005 16:11:30 +0200 (CEST) Date: Fri, 15 Apr 2005 16:11:30 +0200 From: Divacky Roman To: current@freebsd.org Message-ID: <20050415141130.GA63138@stud.fit.vutbr.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.49 on 147.229.10.14 cc: sos@freebsd.org Subject: current broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 14:11:35 -0000 hi recent current is broken in dev/ata /usr/src/sys/dev/ata/ata-all.c: In function `ata_identify': /usr/src/sys/dev/ata/ata-all.c:635: error: `parent' undeclared (first use in this function) seems like soren forgot to s/parent/dev roman From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 15:06:24 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 6CE9A16A4CE; Fri, 15 Apr 2005 15:06:24 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.3/8.13.1) with ESMTP id j3FF78xA003047; Fri, 15 Apr 2005 11:07:08 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.3/8.13.1/Submit) id j3FF78F9003046; Fri, 15 Apr 2005 11:07:08 -0400 (EDT) (envelope-from green) Date: Fri, 15 Apr 2005 11:07:08 -0400 From: Brian Fundakowski Feldman To: Marc Olzheim Message-ID: <20050415150708.GP981@green.homeunix.org> References: <20050415050821.GO981@green.homeunix.org> <20050415132108.GC85922@stack.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050415132108.GC85922@stack.nl> User-Agent: Mutt/1.5.6i cc: hackers@freebsd.org cc: current@freebsd.org Subject: Re: NFS client/buffer cache deadlock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 15:06:24 -0000 On Fri, Apr 15, 2005 at 03:21:08PM +0200, Marc Olzheim wrote: > On Fri, Apr 15, 2005 at 01:08:21AM -0400, Brian Fundakowski Feldman wrote: > > I'll spare a lengthy write-up because I think the patch documents it well > > enough. It certainly appears to fix things here when doing very large > > block-sized writes, but it also reduces the throughput with those block > > sizes. (I don't think there should be any difference when using reasonable > > block sizes). > > Is this supposed to fix kern/79208 ? Yes, it does; would you like to try a more recent version of the patch? It's actually against -STABLE, but it needs to be tested in -CURRENT if it's going ot try to make it into 5.x (or hopefully 5.4-RELEASE). See: This also implements non-blocking writes for NFS clients and will do the right thing (perform a continuous write, flushing as it goes, and causing no drop in performance) for "non-atomic" I/O, but I don't know of any interface that allows you to do non-atomic writes. Buggy applications can break because of this. The behavior is almost never going to be different until you start trying to use extremely large (say, over a megabyte) writes: if you actually depend on writes being complete and atomic, you check that what you intended to write (a reasonable amount) was exactly what was written in a single system call. If you don't, then you're supposed to correctly handle short writes by completing them yourself. If your application expects to have multiple interleaved appenders do the right thing for these giant writes, I don't expect it will work. The implmentation, but not the manpage, would continue to match the POSIX semantics (with regard to short writes). See: If it expects NFS-level append atomicity of large writes, it will not get that. If it expects local-machine-level append atomicity of large writes, it could get that if we provide an interface for !IO_UNIT. Note that file locking is also an option... I don't believe there is any way to provide unlimited-sized, retryable (in the NFS atomic transaction level), NFS client writes. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 15:10:32 2005 Return-Path: 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 C8B9D16A4CE for ; Fri, 15 Apr 2005 15:10:32 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4478C43D46 for ; Fri, 15 Apr 2005 15:10:32 +0000 (GMT) (envelope-from lydianconcepts@gmail.com) Received: by rproxy.gmail.com with SMTP id j1so606401rnf for ; Fri, 15 Apr 2005 08:10:31 -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=ZAiNeam56g40BOXUAp5/k5UCmDW7ucPDK/rmPZkyF2JWnUS3kwcU3lxVemcJFdYwRRUsrxxeI3MW5YtUlmOby0fndpRPvIMq30zERHP21pi5CvoBg2auf1+7IHt8i0xZvufw9t3hcWXFQ2lpBhJQFfuuEflQaV/Ko9Ef6YCHvrU= Received: by 10.38.96.65 with SMTP id t65mr3217522rnb; Fri, 15 Apr 2005 08:10:31 -0700 (PDT) Received: by 10.38.104.23 with HTTP; Fri, 15 Apr 2005 08:10:31 -0700 (PDT) Message-ID: <7579f7fb0504150810609e6b22@mail.gmail.com> Date: Fri, 15 Apr 2005 08:10:31 -0700 From: Matthew Jacob To: Andre Guibert de Bruet In-Reply-To: <20050415052644.H93987@lexi.siliconlandmark.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050409132401.GZ837@darkness.comp.waw.pl> <20050415052644.H93987@lexi.siliconlandmark.com> cc: freebsd-current@freebsd.org cc: Pawel Jakub Dawidek Subject: Re: LOR: vm page queue mutex -> vnode interlock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Matthew Jacob List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2005 15:10:32 -0000 "me too" for loopback mounting On 4/15/05, Andre Guibert de Bruet wrote: >=20 > On Sat, 9 Apr 2005, Pawel Jakub Dawidek wrote: >=20 > > I get this LOR on boot (this is diskless machine): > > > > 1st 0xc068f940 vm page queue mutex (vm page queue mutex) @ /usr/src/HEA= D/src/sys/kern/vfs_bio.c:1485 > > 2nd 0xc127da30 vnode interlock (vnode interlock) @ /usr/src/HEAD/src/sy= s/kern/vfs_subr.c:1989 >=20 > "Me too", with today's sources. >=20 > Cheers, > Andy >=20 > | Andre Guibert de Bruet | Enterprise Software Consultant > > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > > _______________________________________________ > 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 Apr 15 15:16:00 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id F3E6E16A4CE; Fri, 15 Apr 2005 15:15:59 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.3/8.13.1) with ESMTP id j3FFGiBr003129; Fri, 15 Apr 2005 11:16:44 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.3/8.13.1/Submit) id j3FFGiUY003128; Fri, 15 Apr 2005 11:16:44 -0400 (EDT) (envelope-from green) Date: Fri, 15 Apr 2005 11:16:43 -0400 From: Brian Fundakowski Feldman To: Gunther Thiel Message-ID: <20050415151643.GQ981@green.homeunix.org> References: <1113566521.25223.41.camel@darthvader> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1113566521.25223.41.camel@darthvader> User-Agent: Mutt/1.5.6i cc: freebsd-current@freebsd.org Subject: Re: Stackable Filesystems/deadlock/VI_DOOMED X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 15:16:00 -0000 On Fri, Apr 15, 2005 at 02:02:02PM +0200, Gunther Thiel wrote: > Had posted this one to freebsd-fs but there is apparently not too much going on. > So, am retrying it here. > > I am working on stackable filesystems using 5.3-STABLE and figured that > there are still deadlock problems when using the nullfs template on a > busy, stressed machine. > >From what I have experienced, apparently the deadlock occurs when trying > to get a new node while it's being recycled. > > What I have seen in the VFS code of the CURRENT branch looks very > promising (VI_DOOMED instead of VI_XLOCK!), but as I have no clue when > new VFS stuff will be in a solid state, I wanted to ask if the problem > is at all solveable with the VFS concept under 5.3 and if so, how. > If it is not solveable (which is my personal guess) would someone mind > giving me a hint on dependencies when I would only like to use as much > stuff from CURRENT to move to new VFS concept (with all the ostentatious > risks)? You should probably just start developing on 6.0-CURRENT; it is slated to become -STABLE not too far in the future. Someone else should tell me if I'm wrong, but I don't think these changes are remotely small enough to merge back into 5.x. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 16:13:54 2005 Return-Path: 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 7B90016A4CE for ; Fri, 15 Apr 2005 16:13:54 +0000 (GMT) Received: from april.chuckr.org (april.chuckr.org [66.92.151.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E5AC43D53 for ; Fri, 15 Apr 2005 16:13:54 +0000 (GMT) (envelope-from chuckr@chuckr.org) Received: from [66.92.151.195] (july.chuckr.org [66.92.151.195]) by april.chuckr.org (Postfix) with ESMTP id ADCCD11F46; Fri, 15 Apr 2005 12:06:37 -0400 (EDT) Message-ID: <425FE816.4040306@chuckr.org> Date: Fri, 15 Apr 2005 16:13:10 +0000 From: Chuck Robey User-Agent: Mozilla Thunderbird 1.0 (X11/20050316) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ulrik Guenther References: <425DA5D9.6070805@chuckr.org> <425E2914.3070404@00t.org> In-Reply-To: <425E2914.3070404@00t.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: FreeBSD-current@FreeBSD.org Subject: Re: sound question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 16:13:54 -0000 Ulrik Guenther wrote: > Hi Chuck, > > as I know so far, the driver does not really know *anything* about > digital output. If you are using your SoundBlaster not commercially, > could could give the OpenSoundSystem (www.opensound.com) a try which is > free for non-commercial use. With this, your Audigy should work like a > charm. I'm really not happy with the notion of having to reload the software every 4 months. Better to fix the FreeBSD driver. I'm trying to find out about emu10k1, so I cazn learn what needs to be extended. > > Have fun, > > Ulrik > > Chuck Robey wrote: > >> Just one simple question: >> >> I have a SoundBlaster Audigy, it's got analog and digital outputs. I >> know that both work, I had them both working in the same layout with >> Linux. I just want to know if the fact that I can't get any sound out >> of the digital outputs is >> >> a) because the driver doesn't know about the digital output, or >> b) because I have it misconfigured >> c) because I'm doing something horribly stupid. >> >> I'm willing to do more investigation, but I want to start off in the >> correct direction, so a word to start me off the way would help out. >> >> BTW, I have a amd64 on this machine, but I could also try the i386 >> machine. >> _______________________________________________ >> 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 Apr 15 16:20:55 2005 Return-Path: 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 1C71A16A4D7; Fri, 15 Apr 2005 16:20:55 +0000 (GMT) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 768A043D2F; Fri, 15 Apr 2005 16:20:54 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.4.250] (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.13.3/8.13.3) with ESMTP id j3FGKrcN004213; Fri, 15 Apr 2005 09:20:54 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <20050414172147.GA772@laptop.santcroos.net> References: <20050414103154.GA11341@laptop.santcroos.net> <20050414135004.GB75334@unixpages.org> <20050414172147.GA772@laptop.santcroos.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Fri, 15 Apr 2005 09:20:52 -0700 To: Mark Santcroos X-Mailer: Apple Mail (2.619.2) cc: freebsd-acpi@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: Please test: ACPI-CA import 20050408 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 16:20:55 -0000 On Apr 14, 2005, at 10:21 AM, Mark Santcroos wrote: > On Thu, Apr 14, 2005 at 03:50:05PM +0200, Christian Brueffer wrote: >> looks like acopcode.h and acnames.h are not included in the patch. > > Oops, rusty cvs skills :) > > The following files have been added to the diff: > abcompare.c abmain.c acnames.h acopcode.h acpibin.h aecommon.h aeexec.c > aemain.c osunixdir.c > > Same location, more fun: > http://www.santcroos.net/mark/freebsd/files/ > acpi_import_20050408.diff.gz No problems on ia64. However the patch is still incomplete. A buildworld fails in src/usr.sbin/acpi: In file included from aslcompilerlex.l:122: /q/6.x/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler/ aslcompiler.h:148:23: asldefine.h: No such file or directory In file included from aslcompilerparse.y:127: /q/6.x/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler/ aslcompiler.h:148:23: asldefine.h: No such file or directory BTW: Is ACPICA getting slower? -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 16:28:25 2005 Return-Path: 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 8A77416A55B; Fri, 15 Apr 2005 16:28:25 +0000 (GMT) Received: from postman.ripe.net (postman.ripe.net [193.0.0.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1ED843D49; Fri, 15 Apr 2005 16:28:24 +0000 (GMT) (envelope-from marks@ripe.net) Received: by postman.ripe.net (Postfix, from userid 8) id D9C6A26504; Fri, 15 Apr 2005 18:28:23 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id E315826104; Fri, 15 Apr 2005 18:28:22 +0200 (CEST) Received: from laptop.santcroos.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id j3FGSLet022348; Fri, 15 Apr 2005 18:28:22 +0200 Received: (nullmailer pid 2217 invoked by uid 1001); Fri, 15 Apr 2005 16:28:21 -0000 Date: Fri, 15 Apr 2005 18:28:21 +0200 From: Mark Santcroos To: Marcel Moolenaar Message-ID: <20050415162821.GA691@laptop.santcroos.net> References: <20050414103154.GA11341@laptop.santcroos.net> <20050414135004.GB75334@unixpages.org> <20050414172147.GA772@laptop.santcroos.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-RIPE-Spam-Level: X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00,SUBJ_HAS_UNIQ_ID X-RIPE-Spam-Status: N 0.040854 / -4.6 X-RIPE-Signature: 7c49360346c8853aff633c6c34b1aaaf cc: freebsd-acpi@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: Please test: ACPI-CA import 20050408 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 16:28:25 -0000 Hi Marcel, On Fri, Apr 15, 2005 at 09:20:52AM -0700, Marcel Moolenaar wrote: > In file included from aslcompilerlex.l:122: > /q/6.x/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler/ > aslcompiler.h:148:23: asldefine.h: No such file or directory I fixed this yesterday, you probably fetched it before I uploaded the new version. > BTW: Is ACPICA getting slower? Might be. I don't have numbers on that. I guess we're still focusing on functionality and not so much on speed. Do you have a concrete area where you think we are loosing performance? Mark -- RIPE NCC - Delft University of Technology - The FreeBSD Project marks@ripe.net - m.a.santcroos@ewi.tudelft.nl - marks@freebsd.org From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 16:32:55 2005 Return-Path: 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 1D5CF16A4CE for ; Fri, 15 Apr 2005 16:32:55 +0000 (GMT) Received: from mail27.sea5.speakeasy.net (mail27.sea5.speakeasy.net [69.17.117.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3F5443D39 for ; Fri, 15 Apr 2005 16:32:54 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 30776 invoked from network); 15 Apr 2005 16:32:54 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 15 Apr 2005 16:32:52 -0000 Received: from [131.106.58.7] (p180.n-lapop01.stsn.com [12.129.240.180]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j3FGWf5w045787; Fri, 15 Apr 2005 12:32:42 -0400 (EDT) (envelope-from jhb@FreeBSD.org) In-Reply-To: <20050413125622.GA39802@squash.dsto.defence.gov.au> References: <20050413125622.GA39802@squash.dsto.defence.gov.au> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2cfc4c75bbcc0e0d0774d69b9796a32c@FreeBSD.org> Content-Transfer-Encoding: 7bit From: John Baldwin Date: Fri, 15 Apr 2005 12:32:40 -0400 To: "Wilkinson, Alex" X-Mailer: Apple Mail (2.619.2) X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: matthew.thyer@dsto.defence.gov.au cc: freebsd-current@FreeBSD.org Subject: Re: panic upon bootstrap'ing - 6.0-CURRENT #4: Wed Apr 13 2005 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 16:32:55 -0000 On Apr 13, 2005, at 8:56 AM, Wilkinson, Alex wrote: > FreeBSD 6.0-CURRENT #4: Wed Apr 13 21:06:05 CST 2005 > > FreeBSD/i386 bootstrap loader, Revision 1.1 > (root@hostname.dsto.defence.gov.au, Wed Apr 13 18:58:54 CST 2005) > Loading /boot/defaults/loader.conf > > /boot/kernel/kernel text=0x4e8874 data=0x7f7f0+0x9bd10 > syms=[0x4+0x59560+0x4+0x6da15] > /boot/kernel/linux.ko text=0x14ec8 data=0x1254+0x54 > syms=[0x4+0x28b0+0x4+0x263e] > /boot/kernel/agp.ko text=0xead4 data=0xc18+0x24 > syms=[0x4+0x1730+0x4+0x1fc6] > /boot/modules/nvidia.ko text=0x21a01c data=0x5d000+0x202a98 > syms=[0x4+0x1e5b0+0x4+0x16d12] > - > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > /boot/kernel/acpi.ko text=0x49ac0 data=0x2124+0x110c > syms=[0x4+0x77c0+0x4+0x9f1a] > GDB: no debug ports present > KDB: debugger backends: ddb > KDB: current backend: ddb > 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-CURRENT #4: Wed Apr 13 21:06:05 CST 2005 > root@hostname.dsto.defence.gov.au:/usr/obj/usr/src/sys/GENERIC > WARNING: WITNESS option enabled, expect reduced performance. > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2793.20-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 > > Features=0xbfebfbff E,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > real memory = 1073741824 (1024 MB) > avail memory = 1033625600 (985 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 > acpi0: Power Button (fixed) > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0xf808-0xf80b on acpi0 > cpu0: on acpi0 > acpi_throttle0: on cpu0 > pci_link0: irq 10 on acpi0 > pci_link1: irq 5 on acpi0 > pci_link2: irq 10 on acpi0 > pci_link3: irq 11 on acpi0 > pci_link4: irq 5 on acpi0 > pci_link5: irq 0 on acpi0 > pci_link6: irq 0 on acpi0 > pci_link7: irq 10 on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > agp0: mem 0xec000000-0xefffffff at > device 0.0 on pci0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > nvidia0: mem > 0xf9000000-0xf9ffffff,0xf0000000-0xf7ffffff irq 18 at device 0.0 on > pci1 > WARNING: Device driver "lock order reversal > 1st 0xc09831e0 cdev (cdev) @ /usr/src/sys/kern/kern_conf.c:60 > 2nd 0xc0982f84 user map (user map) @ /usr/src/sys/vm/vm_map.c:2998 > KDB: stack backtrace: > witness_checkorder(c0982f84,9,c08d9700,bb6,b) at > witness_checkorder+0x5f1 > _sx_xlock(c0982f84,c08d9700,bb6,1000001,480000) at _sx_xlock+0x5c > vm_map_lookup(c1420728,480000,1,c142072c,c142071c) at > vm_map_lookup+0x2e > vm_fault(c0982f40,480000,1,0,c0982de0) at vm_fault+0x7b > trap_pfault(480008,c142083c,c0682d05,c183afe4,480008) at > trap_pfault+0x159 > trap(18,c1420010,c06a0010,480008,c08bb8f5) at trap+0x34d > calltrap() at calltrap+0x5 > --- trap 0xc, eip = 0xc06d6224, esp = 0xc142083c, ebp = 0xc142083c --- > strlen(480008,c1420924,1,6,18) at strlen+0x8 Looks like a bad pointer passed to strlen(). Looks like the nvidia driver was doing a printf("Warning Device driver\"%s\"", foo) and that foo is a bad pointer somehow. Actually, this looks like it's in the FreeBSD driver code rather than in the nvidia driver. In fact, it's probably this code: if (devsw->d_version != D_VERSION_01) { printf( "WARNING: Device driver \"%s\" has wrong version %s\n", devsw->d_name, "and is disabled. Recompile KLD module."); You probably need to recompile your nvidia driver as the kernel has changed the devsw ABI since the last time you compiled it. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 16:53:54 2005 Return-Path: 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 381AD16A4CF for ; Fri, 15 Apr 2005 16:53:54 +0000 (GMT) Received: from mail23.sea5.speakeasy.net (mail23.sea5.speakeasy.net [69.17.117.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4EA5243D2F for ; Fri, 15 Apr 2005 16:53:53 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 27464 invoked from network); 15 Apr 2005 16:53:53 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 15 Apr 2005 16:53:51 -0000 Received: from [131.106.58.7] (p180.n-lapop01.stsn.com [12.129.240.180]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j3FGrfDl045911; Fri, 15 Apr 2005 12:53:44 -0400 (EDT) (envelope-from jhb@FreeBSD.org) In-Reply-To: <20050415063120.G93987@lexi.siliconlandmark.com> References: <20050415063120.G93987@lexi.siliconlandmark.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <17e130c77e0927c73945b43884069d10@FreeBSD.org> Content-Transfer-Encoding: 7bit From: John Baldwin Date: Fri, 15 Apr 2005 12:53:40 -0400 To: Andre Guibert de Bruet X-Mailer: Apple Mail (2.619.2) X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: alc@FreeBSD.org cc: current@FreeBSD.org Subject: Re: syscons joy: reproduceable panic on resolution change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 16:53:54 -0000 On Apr 15, 2005, at 8:27 AM, Andre Guibert de Bruet wrote: > Hi, > > While attempting to change from 90x60 to VESA_132x60... > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x0 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc051d257 > stack pointer = 0x28:0xe900ca18 > frame pointer = 0x28:0xe900ca38 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 85 (swi4: clock sio) > [thread pid 85 tid 100076 ] > Stopped at _mtx_lock_flags+0x47: cmpl $0xc0708208,0(%ebx) > db> tr > Tracing pid 85 tid 100076 td 0xc5014d80 > _mtx_lock_flags(0,0,c06e611e,127,e900cac4) at _mtx_lock_flags+0x47 > vm_fault(c1059000,c0100000,2,0,c5014d80) at vm_fault+0x28e > trap_pfault(e900cb9c,0,c0100000,2,c0100000) at trap_pfault+0x166 > trap(c5010008,28,c0530028,c0100000,c7084000) at trap+0x350 > calltrap() at calltrap+0x5 > --- trap 0xc, eip = 0xc06919b6, esp = 0xe900cbdc, ebp = 0xe900cc00 --- > generic_bcopy(c537c828,0,c537c80c,0,c0000,c06d240e,18a) at > generic_bcopy+0x1a > vga_txtdraw(c537c800,0,c0000,0,5cbf1d40) at vga_txtdraw+0xee > scrn_update(c537c800,1,c0730120,8,c06d4127) at scrn_update+0x2b2 > scrn_timer(c50d7000,0,c06d4127,107,c067317d) at scrn_timer+0x239 > softclock(0,0,c06d0909,256,c07300e0) at softclock+0x242 > ithread_loop(c5018400,e900cd38,c06d06f4,30c,c5018400) at > ithread_loop+0x159 > fork_exit(c0510b8f,c5018400,e900cd38) at fork_exit+0xc2 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xe900cd6c, ebp = 0 --- > db> ps > -- snip-- > 85 c50367f0 0 0 0 000020c [CPU 0] swi4: clock sio > -- snip -- > > I have both the debug kernel and a 3.5GB memory dump on hand, in case > there is additional information that I haven't listed in this email > that may aid in fixing this issue. > > The EIP points to: > > (gdb) l *0xc051d257 > 0xc051d257 is in _mtx_lock_flags (/usr/src/sys/kern/kern_mutex.c:268). > 263 void > 264 _mtx_lock_flags(struct mtx *m, int opts, const char *file, int > line) > 265 { > 266 > 267 MPASS(curthread != NULL); > 268 KASSERT(m->mtx_object.lo_class == > &lock_class_mtx_sleep, > 269 ("mtx_lock() of spin mutex %s @ %s:%d", > m->mtx_object.lo_name, > 270 file, line)); > 271 WITNESS_CHECKORDER(&m->mtx_object, opts | LOP_NEWORDER > | LOP_EXCLUSIVE, > 272 file, line); > > (kgdb) bt > #0 doadump () at pcpu.h:165 > #1 0xc0526951 in boot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:397 > #2 0xc0526cdd in panic (fmt=0x0) at > /usr/src/sys/kern/kern_shutdown.c:553 > #3 0xc045026d in db_fncall (dummy1=1016, dummy2=0, dummy3=3, > dummy4=0xe900c820 "\f") at /usr/src/sys/ddb/db_command.c:531 > #4 0xc045001c in db_command (last_cmdp=0xc0728064, cmd_table=0x0, > aux_cmd_tablep=0xc06f2678, aux_cmd_tablep_end=0xc06f267c) > at /usr/src/sys/ddb/db_command.c:349 > #5 0xc045010d in db_command_loop () at > /usr/src/sys/ddb/db_command.c:455 > #6 0xc0451f9d in db_trap (type=12, code=0) at > /usr/src/sys/ddb/db_main.c:221 > #7 0xc05432f5 in kdb_trap (type=0, code=0, tf=0xe900c9d8) > at /usr/src/sys/kern/subr_kdb.c:421 > #8 0xc0693d09 in trap_fatal (frame=0xe900c9d8, eva=0) > at /usr/src/sys/i386/i386/trap.c:801 > #9 0xc0693a18 in trap_pfault (frame=0xe900c9d8, usermode=0, eva=0) > at /usr/src/sys/i386/i386/trap.c:724 > #10 0xc06935f8 in trap (frame= > {tf_fs = -1068433400, tf_es = -1056636888, tf_ds = 40, tf_edi = > -1066508002, tf_esi = 295, tf_ebp = -385824200, tf_isp = -385824252, > tf_ebx = 0, tf_edx = 7, tf_ecx = -385824056, tf_eax = -989770368, > tf_trapno = 12, tf_err = 0, tf_eip = -1068379561, tf_cs = 32, > tf_eflags = 66178, tf_esp = -1067131464, tf_ss = -1056600064}) at > /usr/src/sys/i386/i386/trap.c:414 > #11 0xc067f91a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > #12 0xc0510008 in idle_setup (dummy=0x0) at > /usr/src/sys/kern/kern_idle.c:89 > #13 0xc0645d6e in vm_fault (map=0xc1059000, vaddr=3222274048, > fault_type=2 '\002', fault_flags=0) at > /usr/src/sys/vm/vm_fault.c:295 You have a truly unique nested panic here that I haven't seen in a long time. Somehow vm_map_lookup() is returning success, but it is setting fs.first_object to NULL. > #14 0xc06939c4 in trap_pfault (frame=0xe900cb9c, usermode=0, > eva=3222274048) > at /usr/src/sys/i386/i386/trap.c:713 > #15 0xc06935f8 in trap (frame= > {tf_fs = -989790200, tf_es = 40, tf_ds = -1068302296, tf_edi = > -1072693248, tf_esi = -955760640, tf_ebp = -385823744, tf_isp = > -385823800, tf_ebx = -1072988160, tf_edx = 1572864, tf_ecx = 319488, > tf_eax = -116932608, tf_trapno = 12, tf_err = 3, tf_eip = -1066853962, > tf_cs = 32, tf_eflags = 66054, tf_esp = 0, tf_ss = -986200024}) at > /usr/src/sys/i386/i386/trap.c:414 > #16 0xc067f91a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > #17 0xc5010008 in ?? () > #18 0x00000028 in ?? () > #19 0xc0530028 in ogetkerninfo (td=0xc537c828, uap=0xc0100000) > at /usr/src/sys/kern/kern_sysctl.c:1440 > #20 0xc066da8c in vga_txtdraw (scp=0xc537c800, from=0, count=786432, > flip=0) > at /usr/src/sys/dev/syscons/scvgarndr.c:196 I'm not sure why you are bcopy'ing a bad KVA here. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 16:55:50 2005 Return-Path: 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 5CA0416A4CE for ; Fri, 15 Apr 2005 16:55:50 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09D0743D1D for ; Fri, 15 Apr 2005 16:55:50 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id DB7CF72DD9; Fri, 15 Apr 2005 09:55:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id D600672DCB; Fri, 15 Apr 2005 09:55:49 -0700 (PDT) Date: Fri, 15 Apr 2005 09:55:49 -0700 (PDT) From: Doug White To: Daniel Eriksson In-Reply-To: Message-ID: <20050415095502.R34838@carver.gumbysoft.com> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: 'FreeBSD Current' Subject: Re: task queue: supervisor write, page not present X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 16:55:50 -0000 On Tue, 12 Apr 2005, Daniel Eriksson wrote: > > This is the third time in 4 days that I get the following crash on one of my > servers. It's a dual AthlonMP machine, and at the time of the crash it > wasn't doing much at all (running a few instances of a proprietary video > server app). There's a dmesg at the bottom too. > > The log below is from a system running CURRENT from earlier today > (2005.04.12.06.30.00). The other two crashes happened using sources dated > 2005.04.08.04.00.00. Can you get a crashdump and inspect the taskq with gdb? I'm assuming there's a bogus entry thats getting tripped over. > > /Daniel Eriksson > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 01 > fault virtual address = 0xc2b760b4 > fault code = supervisor write, page not present > instruction pointer = 0x8:0xc0578f53 > stack pointer = 0x10:0xe09e7ca4 > frame pointer = 0x10:0xe09e7ccc > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 40 (swi6: task queue) > [thread pid 40 tid 100036 ] > Stopped at taskqueue_run+0x123: andl $-0x2,0x14(%ebx) > db> where > Tracing pid 40 tid 100036 td 0xc1eccd80 > taskqueue_run(c1f3c180,e09e7d14,c053a678,0,0) at taskqueue_run+0x123 > taskqueue_swi_run(0,0,0,0,0) at taskqueue_swi_run+0x13 > ithread_loop(c1ed9180,e09e7d48,0,0,0) at ithread_loop+0x1a8 > fork_exit(c053a4d0,c1ed9180,e09e7d48) at fork_exit+0x80 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xe09e7d7c, ebp = 0 --- > db> ps > pid proc uid ppid pgrp flag stat wmesg wchan cmd > 11120 c25bb7f0 0 612 11120 0004100 [CPU 1] mcvidserv > 10639 c28c09ec 0 612 10639 0004100 [SLPQ biord 0xd17c6b30][SLP] > mcvidserv > 10532 c3e9a1fc 0 612 10532 0004100 [SLPQ sbwait 0xc2456cb4][SLP] > mcvidserv > 7902 c250e5f4 0 612 7902 0004100 [SLPQ sbwait 0xc2284cb4][SLP] > mcvidserv > 1725 c2814be8 0 612 1725 0004100 [SLPQ nanslp 0xc07930ac][SLP] > mcvidserv > 3372 c28bd9ec 0 533 533 0000101 [SLPQ select 0xc0799c04][SLP] smbd > 860 c25b57f0 0 850 860 0004002 [SLPQ nanslp 0xc07930ac][SLP] mfk > 850 c2814de4 0 849 850 0004002 [SLPQ pause 0xc2814e18][SLP] csh > 849 c25b59ec 0 1 849 0000000 [SLPQ select 0xc0799c04][SLP] screen > 771 c28c03f8 1001 1 771 0000002 [SLPQ select 0xc0799c04][SLP] ctrail > 720 c28145f4 0 1 720 0000000 [SLPQ ggwait 0xc27b6000][SLP] ggatec > 714 c212b1fc 0 1 714 0000000 [SLPQ ggwait 0xc27ac000][SLP] ggatec > 705 c218c9ec 0 1 705 0000000 [SLPQ ggwait 0xc27b5000][SLP] ggatec > 696 c25bb000 0 1 696 0000000 [SLPQ ggwait 0xc2773000][SLP] ggatec > 685 c25b53f8 0 1 685 0000000 [SLPQ ggwait 0xc215c000][SLP] ggatec > 678 c25b5de4 0 1 678 0000000 [SLPQ ggwait 0xc2506000][SLP] ggatec > 635 c25b5be8 0 0 0 0000204 [SLPQ - 0xc1f47000][SLP] g_bde > da0s1g.bde > 627 c250e9ec 0 0 0 0000204 [SLPQ - 0xc218e000][SLP] gv_v 480GB > 626 c25bb1fc 0 0 0 0000204 [SLPQ - 0xc1f88a00][SLP] gv_p > 480GB.p0 > 625 c25bb3f8 0 0 0 0000204 [SLPQ - 0xc25b9c00][SLP] gv_d vd2 > 624 c25bb5f4 0 0 0 0000204 [SLPQ - 0xc218ee00][SLP] gv_d vd3 > 623 c250f3f8 0 0 0 0000204 [SLPQ - 0xc21bab00][SLP] gv_d vd0 > 622 c250e7f0 0 0 0 0000204 [SLPQ - 0xc2513600][SLP] gv_d vd1 > 621 c212ade4 0 1 621 0004002 [SLPQ ttyin 0xc1fcfc10][SLP] getty > 620 c218c3f8 0 1 620 0004002 [SLPQ ttyin 0xc1fd7410][SLP] getty > 619 c212abe8 0 1 619 0004002 [SLPQ ttyin 0xc1fa3c10][SLP] getty > 618 c250f1fc 0 1 618 0004002 [SLPQ ttyin 0xc1fd7010][SLP] getty > 617 c212a9ec 0 1 617 0004002 [SLPQ ttyin 0xc1fd6810][SLP] getty > 612 c218c7f0 0 1 612 0000000 [SLPQ select 0xc0799c04][SLP] inetd > 572 c250e1fc 0 1 571 0000000 [SLPQ select 0xc0799c04][SLP] snmpd > 564 c250ebe8 0 1 563 0000000 [SLPQ nanslp 0xc07930ac][SLP] smartd > 560 c21899ec 0 559 560 0004002 [SLPQ ttyin 0xc20f0010][SLP] csh > 559 c250f000 1001 546 559 0004102 [SLPQ wait 0xc250f000][SLP] su > 546 c2189de4 1001 545 546 0004002 [SLPQ pause 0xc2189e18][SLP] csh > 545 c212b9ec 1001 542 542 0000100 [SLPQ select 0xc0799c04][SLP] sshd > 542 c1fdbde4 0 470 542 0004100 [SLPQ sbwait 0xc2490718][SLP] sshd > 541 c212b3f8 0 533 533 0000101 [SLPQ pause 0xc212b42c][SLP] smbd > 533 c21893f8 0 1 533 0000101 [SLPQ select 0xc0799c04][SLP] smbd > 529 c21891fc 0 1 529 0000001 [SLPQ select 0xc0799c04][SLP] nmbd > 509 c21897f0 65534 1 509 0000100 [SLPQ select 0xc0799c04][SLP] > identd > 496 c218c1fc 0 1 496 0000000 [SLPQ nanslp 0xc07930ac][SLP] cron > 480 c212bde4 25 1 480 0000100 [SLPQ pause 0xc212be18][SLP] > sendmail > 476 c212a1fc 0 1 476 0000100 [SLPQ select 0xc0799c04][SLP] > sendmail > 470 c212a5f4 0 1 470 0000100 [SLPQ select 0xc0799c04][SLP] sshd > 451 c21895f4 0 1 451 0000000 [SLPQ select 0xc0799c04][SLP] ntpd > 344 c218c000 0 1 344 0000000 [SLPQ select 0xc0799c04][SLP] > syslogd > 315 c212a7f0 0 1 315 0000000 [SLPQ select 0xc0799c04][SLP] devd > 171 c212a3f8 0 1 171 0000000 [SLPQ pause 0xc212a42c][SLP] > adjkerntz > 56 c212b7f0 0 0 0 0000204 [SLPQ - 0xe46a4d0c][SLP] schedcpu > 55 c1ecd3f8 0 0 0 0000204 [SLPQ - 0xc079d52c][SLP] nfsiod 3 > 54 c1ecd5f4 0 0 0 0000204 [SLPQ - 0xc079d528][SLP] nfsiod 2 > 53 c1ecd7f0 0 0 0 0000204 [SLPQ - 0xc079d524][SLP] nfsiod 1 > 52 c1ecd9ec 0 0 0 0000204 [SLPQ - 0xc079d520][SLP] nfsiod 0 > 51 c1ecdbe8 0 0 0 0000204 [SLPQ vlruwt 0xc1ecdbe8][SLP] vnlru > 50 c1ecdde4 0 0 0 0000204 [SLPQ syncer 0xc0792e0c][SLP] syncer > 49 c1fdb000 0 0 0 0000204 [SLPQ psleep 0xc079a170][SLP] > bufdaemon > 48 c1fdb1fc 0 0 0 0000204 [SLPQ pollid 0xc0792464][SLP] > idlepoll > 47 c1fdb3f8 0 0 0 000020c [SLPQ pgzero 0xc07a3c24][SLP] > pagezero > 46 c1fdb5f4 0 0 0 0000204 [SLPQ psleep 0xc07a3774][SLP] > vmdaemon > 45 c1fdb7f0 0 0 0 0000204 [SLPQ psleep 0xc07a3730][SLP] > pagedaemon > 9 c1fdb9ec 0 0 0 0000204 [SLPQ - 0xc1fb843c][SLP] fdc0 > 44 c1fdbbe8 0 0 0 0000204 [IWAIT] swi0: sio > 8 c1ec0be8 0 0 0 0000204 [SLPQ idle 0xc1f6dc74][SLP] > ciss_notify0 > 7 c1ec0de4 0 0 0 0000204 [SLPQ actask 0xc08a0f2c][SLP] > acpi_task0 > 43 c1ecb000 0 0 0 0000204 [IWAIT] swi5:+ > 42 c1ecb1fc 0 0 0 0000204 [IWAIT] swi6: acpitaskq > 6 c1ecb3f8 0 0 0 0000204 [SLPQ - 0xc1f3c080][SLP] thread > taskq > 41 c1ecb5f4 0 0 0 0000204 [IWAIT] swi6:+ > 40 c1ecb7f0 0 0 0 0000204 [CPU 0] swi6: task queue > 5 c1ecb9ec 0 0 0 0000204 [SLPQ - 0xc1f3c1c0][SLP] kqueue > taskq > 39 c1ecbbe8 0 0 0 0000204 [IWAIT] swi2: cambio > 38 c1ecbde4 0 0 0 0000204 [SLPQ - 0xc078bdc0][SLP] yarrow > 4 c1ecd000 0 0 0 0000204 [SLPQ - 0xc0790228][SLP] g_down > 3 c1ecd1fc 0 0 0 0000204 [SLPQ - 0xc0790224][SLP] g_up > 2 c1eb05f4 0 0 0 0000204 [SLPQ - 0xc079021c][SLP] g_event > 37 c1eb07f0 0 0 0 0000204 [RUNQ] swi1: net > 36 c1eb09ec 0 0 0 0000204 [IWAIT] swi3: vm > 35 c1eb0be8 0 0 0 000020c [RUNQ] swi4: clock sio > 34 c1eb0de4 0 0 0 0000204 [IWAIT] irq23: > 33 c1ec0000 0 0 0 0000204 [IWAIT] irq22: em1 > 32 c1ec01fc 0 0 0 0000204 [IWAIT] irq21: em0 > 31 c1ec03f8 0 0 0 0000204 [IWAIT] irq20: ciss0 > 30 c1ec05f4 0 0 0 0000204 [IWAIT] irq19: atapci3+ > 29 c1ec07f0 0 0 0 0000204 [IWAIT] irq18: > 28 c1ec09ec 0 0 0 0000204 [LOCK taskqueue c1e01140] irq17: > atapci1+ > 27 c1e0b1fc 0 0 0 0000204 [IWAIT] irq16: > 26 c1e0b3f8 0 0 0 0000204 [IWAIT] irq15: ata1 > 25 c1e0b5f4 0 0 0 0000204 [IWAIT] irq14: ata0 > 24 c1e0b7f0 0 0 0 0000204 [IWAIT] irq13: > 23 c1e0b9ec 0 0 0 0000204 [IWAIT] irq12: > 22 c1e0bbe8 0 0 0 0000204 [IWAIT] irq11: > 21 c1e0bde4 0 0 0 0000204 [IWAIT] irq10: > 20 c1eb0000 0 0 0 0000204 [IWAIT] irq9: acpi0 > 19 c1eb01fc 0 0 0 0000204 [IWAIT] irq8: > 18 c1eb03f8 0 0 0 0000204 [IWAIT] irq7: > 17 c1e06000 0 0 0 0000204 [IWAIT] irq6: fdc0 > 16 c1e061fc 0 0 0 0000204 [IWAIT] irq5: > 15 c1e063f8 0 0 0 0000204 [IWAIT] irq4: sio0 > 14 c1e065f4 0 0 0 0000204 [IWAIT] irq3: > 13 c1e067f0 0 0 0 0000204 [IWAIT] irq0: > 12 c1e069ec 0 0 0 0000204 [IWAIT] irq1: atkbd0 > 11 c1e06be8 0 0 0 000020c [Can run] idle: cpu0 > 10 c1e06de4 0 0 0 000020c [Can run] idle: cpu1 > 1 c1e0b000 0 0 1 0004200 [SLPQ wait 0xc1e0b000][SLP] init > 0 c0790320 0 0 0 0000200 [SLPQ sched 0xc0790320][SLP] swapper > > > > And here's part of the dmesg: > /boot/kernel/kernel text=0x3528bc data=0x36388+0x33c38 > syms=[0x4+0x42940+0x4+0x537ec] > /boot/kernel/acpi.ko text=0x49fa0 data=0x2124+0x110c > syms=[0x4+0x7730+0x4+0x9ec3] > KDB: debugger backends: ddb > KDB: current backend: ddb > 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-CURRENT #0: Tue Apr 12 10:23:40 CEST 2005 > daniel@xxx:/usr/obj/usr/src/sys/XXX > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: AMD Athlon(tm) MP 2600+ (2000.08-MHz 686-class CPU) > Origin = "AuthenticAMD" Id = 0x6a0 Stepping = 0 > > Features=0x383fbff CMOV,PAT,PSE36,MMX,FXSR,SSE> > AMD Features=0xc0480000 > real memory = 804782080 (767 MB) > avail memory = 778342400 (742 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 1 > cpu1 (AP): APIC ID: 0 > MADT: Forcing active-low polarity and level trigger for SCI > ioapic0 irqs 0-23 on motherboard > npx0: [FAST] > npx0: on motherboard > npx0: INT 16 interface > acpi0: on motherboard > acpi0: Power Button (fixed) > acpi0: Sleep Button (fixed) > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 > cpu0: on acpi0 > cpu1: on acpi0 > acpi_button0: on acpi0 > pcib0: port 0xcf8-0xcff,0x8000-0x807f,0x8080-0x80ff > iomem 0xd8000-0xdbfff on acpi0 > pci0: on pcib0 > agp0: port 0x1490-0x1493 mem > 0xec000000-0xedffffff,0xea100000-0xea100fff at device 0.0 on pci0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > pci1: at device 5.0 (no driver attached) > isab0: at device 7.0 on pci0 > isa0: on isab0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 7.1 on pci0 > ata0: on atapci0 > ata1: on atapci0 > pci0: at device 7.3 (no driver attached) > ciss0: port 0x1000-0x10ff mem > 0xe8100000-0xe813ffff,0xe8000000-0xe80fffff irq 20 at device 8.0 on pci0 > ciss0: [GIANT-LOCKED] > em0: port > 0x1400-0x143f mem 0xe81c0000-0xe81dffff,0xe8140000-0xe817ffff irq 21 at > device 9.0 on pci0 > em0: Ethernet address: 00:04:23:ac:20:8a > em0: Speed:N/A Duplex:N/A > em1: port > 0x1440-0x147f mem 0xe81e0000-0xe81fffff,0xe8180000-0xe81bffff irq 22 at > device 9.1 on pci0 > em1: Ethernet address: 00:04:23:ac:20:8b > em1: Speed:N/A Duplex:N/A > pcib2: at device 16.0 on pci0 > pci2: on pcib2 > atapci1: port > 0x3010-0x3017,0x3004-0x3007,0x3008-0x300f,0x3000-0x3003,0x2000-0x20ff irq 17 > at device 5.0 on pci2 > ata2: on atapci1 > ata3: on atapci1 > atapci2: port > 0x3028-0x302f,0x301c-0x301f,0x3020-0x3027,0x3018-0x301b,0x2400-0x24ff irq 17 > at device 5.1 on pci2 > ata4: on atapci2 > ata5: on atapci2 > atapci3: port > 0x3040-0x3047,0x3034-0x3037,0x3038-0x303f,0x3030-0x3033,0x2800-0x28ff irq 19 > at device 7.0 on pci2 > ata6: on atapci3 > ata7: on atapci3 > atapci4: port > 0x3058-0x305f,0x304c-0x304f,0x3050-0x3057,0x3048-0x304b,0x2c00-0x2cff irq 19 > at device 7.1 on pci2 > ata8: on atapci4 > ata9: on atapci4 > pci_link0: irq 5 on acpi0 > pci_link1: irq 3 on acpi0 > pci_link2: irq 11 on acpi0 > pci_link3: irq 10 on acpi0 > 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 > fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 > fdc0: [FAST] > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > pmtimer0 on isa0 > orm0: at iomem > 0xc0000-0xcafff,0xcb000-0xcefff,0xe0000-0xe3fff on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x100> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > Timecounters tick every 1.000 msec > ipfw2 initialized, divert loadable, rule-based forwarding disabled, default > to accept, logging unlimited > ad0: 117800MB at ata0-master UDMA100 > ad1: 117800MB at ata0-slave UDMA100 > ad2: 117800MB at ata1-master UDMA100 > ad3: 117800MB at ata1-slave UDMA100 > ad4: 238475MB at ata2-master UDMA100 > ad5: 238475MB at ata2-slave UDMA100 > ad6: 239372MB at ata3-master UDMA133 > ad7: 239372MB at ata3-slave UDMA133 > ad8: 194481MB at ata4-master UDMA133 > ad9: 194481MB at ata4-slave UDMA133 > ad10: 239372MB at ata5-master UDMA133 > ad12: 114473MB at ata6-master UDMA100 > ad13: 114473MB at ata6-slave UDMA100 > ad14: 117246MB at ata7-master UDMA133 > ad15: 117246MB at ata7-slave UDMA133 > ad16: 114473MB at ata8-master UDMA100 > ad17: 117800MB at ata8-slave UDMA100 > ad18: 194481MB at ata9-master UDMA133 > ad19: 239372MB at ata9-slave UDMA133 > da0 at ciss0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-0 device > da0: 135.168MB/s transfers > da0: 105008MB (215056800 512 byte sectors: 255H 32S/T 26355C) > da1 at ciss0 bus 0 target 1 lun 0 > da1: Fixed Direct Access SCSI-0 device > da1: 135.168MB/s transfers > da1: 486240MB (995821155 512 byte sectors: 255H 63S/T 61987C) > ATA PseudoRAID loaded > ar0: 476950MB status: READY > ar0: disk0 READY using ad4 at ata2-master > ar0: disk1 READY using ad5 at ata2-slave > ar1: 478744MB status: READY > ar1: disk0 READY using ad6 at ata3-master > ar1: disk1 READY using ad7 at ata3-slave > ar2: 583442MB status: READY > ar2: disk0 READY using ad8 at ata4-master > ar2: disk1 READY using ad9 at ata4-slave > ar2: disk2 READY using ad18 at ata9-master > ar3: 478744MB status: READY > ar3: disk0 READY using ad19 at ata9-slave > ar3: disk1 READY using ad10 at ata5-master > ar4: 343420MB status: READY > ar4: disk0 READY using ad12 at ata6-master > ar4: disk1 READY using ad13 at ata6-slave > ar4: disk2 READY using ad16 at ata8-master > ar5: 351740MB status: READY > ar5: disk0 READY using ad14 at ata7-master > ar5: disk1 READY using ad15 at ata7-slave > ar5: disk2 READY using ad17 at ata8-slave > SMP: AP CPU #1 Launched! > Trying to mount root from ufs:/dev/da0s1a > Pre-seeding PRNG: kickstart. > Loading configuration files. > kernel dumps on /dev/da0s1b > Entropy harvesting: point_to_point kickstart. > swapon: adding /dev/da0s1b as swap device > Starting file system checks: > /dev/da0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/da0s1a: clean, 124444 free (1100 frags, 15418 blocks, 0.4% > fragmentation) > /dev/da0s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/da0s1e: clean, 253807 free (31 frags, 31722 blocks, 0.0% fragmentation) > /dev/da0s1f: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/da0s1f: clean, 3082494 free (29310 frags, 381648 blocks, 0.6% > fragmentation) > /dev/da0s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/da0s1d: clean, 207823 free (975 frags, 25856 blocks, 0.4% > fragmentation) > /dev/da0s1h: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/da0s1h: clean, 31567485 free (557 frags, 3945866 blocks, 0.0% > fragmentation) > Setting hostname: xxx. > net.inet.tcp.sendspace: 32768 -> 2097152 > net.inet.tcp.recvspace: 65536 -> 2097152 > kern.ipc.maxsockbuf: 262144 -> 16777216 > kern.ipc.somaxconn: 128 -> 256 > net.inet.ip.intr_queue_maxlen: 50 -> 128 > kern.polling.enable: 0 -> 1 > kern.polling.burst_max: 150 -> 300 > kern.polling.each_burst: 5 -> 50 > kern.polling.poll_in_trap: 0 -> 1 > kern.polling.user_frac: 50 -> 33 > vfs.hirunningspace: 1048576 -> 8388608 > ... > > > _______________________________________________ > 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" > -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 16:59:49 2005 Return-Path: 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 7658316A4CE; Fri, 15 Apr 2005 16:59:49 +0000 (GMT) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39AD743D49; Fri, 15 Apr 2005 16:59:49 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.4.250] (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.13.3/8.13.3) with ESMTP id j3FGd2SD004296; Fri, 15 Apr 2005 09:39:03 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <20050415162821.GA691@laptop.santcroos.net> References: <20050414103154.GA11341@laptop.santcroos.net> <20050414135004.GB75334@unixpages.org> <20050414172147.GA772@laptop.santcroos.net> <20050415162821.GA691@laptop.santcroos.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5e7c3d2084ff2460d6e48786defc8f33@xcllnt.net> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Fri, 15 Apr 2005 09:39:01 -0700 To: Mark Santcroos X-Mailer: Apple Mail (2.619.2) cc: freebsd-acpi@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: Please test: ACPI-CA import 20050408 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 16:59:49 -0000 On Apr 15, 2005, at 9:28 AM, Mark Santcroos wrote: > On Fri, Apr 15, 2005 at 09:20:52AM -0700, Marcel Moolenaar wrote: >> In file included from aslcompilerlex.l:122: >> /q/6.x/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/ >> compiler/ >> aslcompiler.h:148:23: asldefine.h: No such file or directory > > I fixed this yesterday, you probably fetched it before I uploaded the > new version. Ah, ok. I'll refetch if needed. >> BTW: Is ACPICA getting slower? > > Might be. I don't have numbers on that. I guess we're still focusing on > functionality and not so much on speed. > Do you have a concrete area where you think we are loosing performance? No, not yet. It's just that there are 2 "dead" spots in the booting process of the plutos we have in the cluster and these "dead" spots appeared to be longer. I think there's a lot of AML interpretation going on during that time, but I might be wrong. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 17:00:48 2005 Return-Path: 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 8DD0D16A4D5 for ; Fri, 15 Apr 2005 17:00:48 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id E581543D5C for ; Fri, 15 Apr 2005 17:00:32 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id C700872DD9; Fri, 15 Apr 2005 10:00:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id C1FDA72DCB; Fri, 15 Apr 2005 10:00:32 -0700 (PDT) Date: Fri, 15 Apr 2005 10:00:32 -0700 (PDT) From: Doug White To: Kevin Oberman In-Reply-To: <20050412213428.41F1F5D07@ptavv.es.net> Message-ID: <20050415095629.W34838@carver.gumbysoft.com> References: <20050412213428.41F1F5D07@ptavv.es.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: Weird display problem in recent current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 17:00:48 -0000 On Tue, 12 Apr 2005, Kevin Oberman wrote: > Since I updated my current kernel yesterday, I have been seeing a weird > problem that appears to be in X. I did not have the problem with the > build I did on Friday, Apr. 8. > > I run gkrellm, a GTK based system monitor. I also run Gnome 2.10 and > X.org. All of these ports are up to date. System is a P4M IBM T30. > > After my new kernel was installed yesterday, gkrellm would work until > the screen blanks (screensaver set to blank). When the screen is > re-activated, all of the applications refresh except that one. I just > have an empty grey are where gkrellm should be. This is indicative of gkrellm not monitoring the X socket and getting the refresh message. This means its stuck doing something. > top shows that gkrellm is continually in RUN state, although it is using > very little CPU. > > The second problem is that Gnome will no longer shut down. (This may be > an artifact of th problems gkrellm is having.) I have to > CTRL-ALT-BS. (Ugh!) > > I'd look at gkrellm except that I only updated the kernel on Monday, not > world, let alone the gkrellm port. I thought some user-land/kernel > issue may have cropped up, so I just finished rebuilding both the kernel > and world. No change in behavior. > > Any ideas what might have changed between Friday morning and today to > cause this? I'm not even sure where to start looking. Being that gkrellm grubs around in the kernel, its possible some data structre it was looking at changed and now its looping off into space. I'd ktrace it and see what its doing when it goes awry -- that might help isolate the affected module. If that isn't useful then remove modules until you find the broken one. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 17:06:00 2005 Return-Path: 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 6118F16A4CE; Fri, 15 Apr 2005 17:06:00 +0000 (GMT) Received: from peter-laptop.wemm.org (p182.n-lapop01.stsn.com [12.129.240.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB6DB43D45; Fri, 15 Apr 2005 17:05:59 +0000 (GMT) (envelope-from peter@wemm.org) Received: from evilpete.dyndns.org (localhost [127.0.0.1]) by peter-laptop.wemm.org (8.13.3/8.13.3) with ESMTP id j3FH5RYd007762; Fri, 15 Apr 2005 10:05:27 -0700 (PDT) (envelope-from peter@wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by evilpete.dyndns.org (8.13.3/8.13.3/Submit) id j3FH5QmH007761; Fri, 15 Apr 2005 10:05:26 -0700 (PDT) (envelope-from peter@wemm.org) X-Authentication-Warning: evilpete.dyndns.org: peter set sender to peter@wemm.org using -f From: Peter Wemm To: freebsd-current@freebsd.org Date: Fri, 15 Apr 2005 10:05:25 -0700 User-Agent: KMail/1.8 References: <200504121201.j3CC1nZ1035643@gw.catspoiler.org> In-Reply-To: <200504121201.j3CC1nZ1035643@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504151005.25999.peter@wemm.org> cc: Don Lewis cc: current@freebsd.org cc: kris@obsecurity.org Subject: Re: Softupdates not preventing lengthy fsck X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 17:06:00 -0000 On Tuesday 12 April 2005 05:01 am, Don Lewis wrote: > On 11 Apr, Kris Kennaway wrote: > > On Mon, Apr 11, 2005 at 06:43:17PM -0700, Don Lewis wrote: > >> On 11 Apr, Kris Kennaway wrote: > >> > I'm seeing the following problem: on 6.0 machines which have had a lot > >> > of FS activity in the past but are currently quiet, an unclean reboot > >> > will require an hour or more of fscking and will end up clearing > >> > thousands of inodes: > >> > > >> > [...] > >> > /dev/da0s1e: UNREF FILE I=269731 OWNER=root MODE=100644 > >> > /dev/da0s1e: SIZE=8555 MTIME=Apr 18 02:29 2002 (CLEARED) > >> > > >> > /dev/da0s1e: UNREF FILE I=269741 OWNER=root MODE=100644 > >> > [...] > >> > > >> > It's as if dirty buffers aren't being written out properly, or > >> > something. Has anyone else seen this? > >> > >> This looks a lot like it could be a vnode refcnt leak. Files won't get > >> removed from the disk while they are still in use (the old unlink while > >> open trick). Could nullfs be a factor? > > > > Yes, I make extensive use of read-only nullfs. > > > > Kris (fsck still running) > > It would also be interesting to find out why fsck is taking so long to > run. I don't see anything obvious in the code. One HUGE time factor in a fsck run is serial consoles. Printing tens or hundreds of thousands of inode corrections at 9600 baud takes forever. At work, we found that some fsck runs that would take 20+ hours could be reduced to 15-20 minutes by simply redirecting fsck output to /dev/null instead of the serial console. At work, we experimented with a memory based logging process that buffered up its stdin and waited until the fs was writeable. eg: fsck -p 2>&1 | memlogger /var/log/fsck.log Memlogger would malloc memory to hold fsck's output and periodically poll for /var/log to become writable. (There was more to it than that, and I'm not sure that we figured out all the quirks to make it usable in the /etc/rc environment) -Peter From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 17:06:00 2005 Return-Path: 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 6118F16A4CE; Fri, 15 Apr 2005 17:06:00 +0000 (GMT) Received: from peter-laptop.wemm.org (p182.n-lapop01.stsn.com [12.129.240.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB6DB43D45; Fri, 15 Apr 2005 17:05:59 +0000 (GMT) (envelope-from peter@wemm.org) Received: from evilpete.dyndns.org (localhost [127.0.0.1]) by peter-laptop.wemm.org (8.13.3/8.13.3) with ESMTP id j3FH5RYd007762; Fri, 15 Apr 2005 10:05:27 -0700 (PDT) (envelope-from peter@wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by evilpete.dyndns.org (8.13.3/8.13.3/Submit) id j3FH5QmH007761; Fri, 15 Apr 2005 10:05:26 -0700 (PDT) (envelope-from peter@wemm.org) X-Authentication-Warning: evilpete.dyndns.org: peter set sender to peter@wemm.org using -f From: Peter Wemm To: freebsd-current@freebsd.org Date: Fri, 15 Apr 2005 10:05:25 -0700 User-Agent: KMail/1.8 References: <200504121201.j3CC1nZ1035643@gw.catspoiler.org> In-Reply-To: <200504121201.j3CC1nZ1035643@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504151005.25999.peter@wemm.org> cc: Don Lewis cc: current@freebsd.org cc: kris@obsecurity.org Subject: Re: Softupdates not preventing lengthy fsck X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 17:06:00 -0000 On Tuesday 12 April 2005 05:01 am, Don Lewis wrote: > On 11 Apr, Kris Kennaway wrote: > > On Mon, Apr 11, 2005 at 06:43:17PM -0700, Don Lewis wrote: > >> On 11 Apr, Kris Kennaway wrote: > >> > I'm seeing the following problem: on 6.0 machines which have had a lot > >> > of FS activity in the past but are currently quiet, an unclean reboot > >> > will require an hour or more of fscking and will end up clearing > >> > thousands of inodes: > >> > > >> > [...] > >> > /dev/da0s1e: UNREF FILE I=269731 OWNER=root MODE=100644 > >> > /dev/da0s1e: SIZE=8555 MTIME=Apr 18 02:29 2002 (CLEARED) > >> > > >> > /dev/da0s1e: UNREF FILE I=269741 OWNER=root MODE=100644 > >> > [...] > >> > > >> > It's as if dirty buffers aren't being written out properly, or > >> > something. Has anyone else seen this? > >> > >> This looks a lot like it could be a vnode refcnt leak. Files won't get > >> removed from the disk while they are still in use (the old unlink while > >> open trick). Could nullfs be a factor? > > > > Yes, I make extensive use of read-only nullfs. > > > > Kris (fsck still running) > > It would also be interesting to find out why fsck is taking so long to > run. I don't see anything obvious in the code. One HUGE time factor in a fsck run is serial consoles. Printing tens or hundreds of thousands of inode corrections at 9600 baud takes forever. At work, we found that some fsck runs that would take 20+ hours could be reduced to 15-20 minutes by simply redirecting fsck output to /dev/null instead of the serial console. At work, we experimented with a memory based logging process that buffered up its stdin and waited until the fs was writeable. eg: fsck -p 2>&1 | memlogger /var/log/fsck.log Memlogger would malloc memory to hold fsck's output and periodically poll for /var/log to become writable. (There was more to it than that, and I'm not sure that we figured out all the quirks to make it usable in the /etc/rc environment) -Peter From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 17:26:43 2005 Return-Path: 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 C5B3016A4CE for ; Fri, 15 Apr 2005 17:26:42 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A21B043D31 for ; Fri, 15 Apr 2005 17:26:42 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 93A0272DD9; Fri, 15 Apr 2005 10:26:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 9165672DCB; Fri, 15 Apr 2005 10:26:42 -0700 (PDT) Date: Fri, 15 Apr 2005 10:26:42 -0700 (PDT) From: Doug White To: Eirik =?ISO-8859-1?B?2A==?=verby In-Reply-To: Message-ID: <20050415102457.F34838@carver.gumbysoft.com> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE cc: "current@freebsd.org" Subject: Re: Panic after "in_cksum_skip: out of data by 260" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 17:26:43 -0000 On Wed, 13 Apr 2005, Eirik [ISO-8859-1] =D8verby wrote: > Hi, > > Today I received this message on my serial console: > > in_cksum_skip: out of data by 260 From=20a brief reading of the source it looks like this is a corrupted mbuf that got tripped over later. If you can reproduce this I'd turn the printf at the end of src/sys/i386/i386/in_cksum.c into a panic and get a crashdump so the bad data can be analysed. > Fatal trap 12: page fault while in kernel mode > cpuid =3D 1; apic id =3D 00 > fault virtual address =3D 0xc > fault code =3D supervisor read, page not present > instruction pointer =3D 0x8:0xc066ec33 > stack pointer =3D 0x10:0xd5437974 > frame pointer =3D 0x10:0xd5437998 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, def32 1, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 36 (swi1: net) > trap number =3D 12 > panic: page fault > cpuid =3D 1 > boot() called on cpu#0 > Uptime: 1d15h8m10s > > This server has been very stable for a very long time. This crash surpris= es > me somewhat. > Uname output: > FreeBSD carnen.net 5.3-STABLE FreeBSD 5.3-STABLE #0: Wed Feb 2 21:02:44 = CET > 2005 root@carnen.net:/usr/obj/usr/src/sys/CARNEN i386 > > Any idea what could have caused this? > > Thanks, > /Eirik > > > _______________________________________________ > 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 Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 17:29:30 2005 Return-Path: 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 C540316A4CE for ; Fri, 15 Apr 2005 17:29:30 +0000 (GMT) Received: from anduin.net (anduin.net [212.12.46.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 725BF43D54 for ; Fri, 15 Apr 2005 17:29:30 +0000 (GMT) (envelope-from ltning@anduin.net) Received: from [213.225.74.166] (helo=[10.0.16.10]) by anduin.net with esmtpa (Exim 4.50 (FreeBSD)) id 1DMUdE-000HEa-R4; Fri, 15 Apr 2005 19:29:29 +0200 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 15 Apr 2005 19:29:26 +0200 From: Eirik =?ISO-8859-1?B?2A==?=verby To: Doug White Message-ID: In-Reply-To: <20050415102457.F34838@carver.gumbysoft.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable cc: "current@freebsd.org" Subject: Re: Panic after "in_cksum_skip: out of data by 260" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 17:29:31 -0000 On 15-04-05 19:26, "Doug White" wrote: > On Wed, 13 Apr 2005, Eirik [ISO-8859-1] =D8verby wrote: >=20 >> Hi, >>=20 >> Today I received this message on my serial console: >>=20 >> in_cksum_skip: out of data by 260 >=20 > From a brief reading of the source it looks like this is a corrupted mbuf > that got tripped over later. If you can reproduce this I'd turn the > printf at the end of src/sys/i386/i386/in_cksum.c into a panic and get a > crashdump so the bad data can be analysed. If I could reproduce it I would have ;) But this is the first time I've see= n it, and I somehow doubt I'll be seeing it any time soon. I have enabled crash dumping and all that on the system though, so we'll see, but as it's = a production system I can't play around too much. I have instructed the monitoring and support folks what to do if it SHOULD happen again though, so we can get some proper data out of it. But don't hold your breath..... Thanks, /Eirik >=20 >> Fatal trap 12: page fault while in kernel mode >> cpuid =3D 1; apic id =3D 00 >> fault virtual address =3D 0xc >> fault code =3D supervisor read, page not present >> instruction pointer =3D 0x8:0xc066ec33 >> stack pointer =3D 0x10:0xd5437974 >> frame pointer =3D 0x10:0xd5437998 >> code segment =3D base 0x0, limit 0xfffff, type 0x1b >> =3D DPL 0, pres 1, def32 1, gran 1 >> processor eflags =3D interrupt enabled, resume, IOPL =3D 0 >> current process =3D 36 (swi1: net) >> trap number =3D 12 >> panic: page fault >> cpuid =3D 1 >> boot() called on cpu#0 >> Uptime: 1d15h8m10s >>=20 >> This server has been very stable for a very long time. This crash surpri= ses >> me somewhat. >> Uname output: >> FreeBSD carnen.net 5.3-STABLE FreeBSD 5.3-STABLE #0: Wed Feb 2 21:02:44= CET >> 2005 root@carnen.net:/usr/obj/usr/src/sys/CARNEN i386 >>=20 >> Any idea what could have caused this? >>=20 >> Thanks, >> /Eirik >>=20 >>=20 >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g" >>=20 From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 17:36:30 2005 Return-Path: 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 A6D8616A4CE; Fri, 15 Apr 2005 17:36:30 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34A4443D5A; Fri, 15 Apr 2005 17:36:30 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.3) id j3FHaRwe040220; Fri, 15 Apr 2005 12:36:27 -0500 (CDT) (envelope-from dan) Date: Fri, 15 Apr 2005 12:36:27 -0500 From: Dan Nelson To: Marcel Moolenaar Message-ID: <20050415173627.GQ4842@dan.emsphone.com> References: <20050414103154.GA11341@laptop.santcroos.net> <20050414135004.GB75334@unixpages.org> <20050414172147.GA772@laptop.santcroos.net> <20050415162821.GA691@laptop.santcroos.net> <5e7c3d2084ff2460d6e48786defc8f33@xcllnt.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ReaqsoxgOBHFXBhH" Content-Disposition: inline In-Reply-To: <5e7c3d2084ff2460d6e48786defc8f33@xcllnt.net> X-OS: FreeBSD 5.4-PRERELEASE X-message-flag: Outlook Error User-Agent: Mutt/1.5.8i cc: freebsd-acpi@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: Please test: ACPI-CA import 20050408 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 17:36:30 -0000 --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In the last episode (Apr 15), Marcel Moolenaar said: > On Apr 15, 2005, at 9:28 AM, Mark Santcroos wrote: > >On Fri, Apr 15, 2005 at 09:20:52AM -0700, Marcel Moolenaar wrote: > >>BTW: Is ACPICA getting slower? > > > > Might be. I don't have numbers on that. I guess we're still > > focusing on functionality and not so much on speed. Do you have a > > concrete area where you think we are loosing performance? > > No, not yet. It's just that there are 2 "dead" spots in the booting > process of the plutos we have in the cluster and these "dead" spots > appeared to be longer. I think there's a lot of AML interpretation > going on during that time, but I might be wrong. What I have personally seen is a long delay in bus_alloc_resource() on some older Dell machines (desktop and laptop, both under 500Mhz). If I apply the attached patch, I see between 15 and 20 rows of identical output, and each call to b_a_r takes a noticeable fraction of a second (i.e. the cursor spends most of its time after an IRQ, not after a 'y' or 'n'.) The delays probably add 45 seconds total to the boot time. Newer systems will just generate 4 or 5 lines total for the entire boot process. -- Dan Nelson dnelson@allantgroup.com --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="irq.diff" Index: acpi_pci_link.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi_pci_link.c,v retrieving revision 1.24.2.6 diff -u -p -r1.24.2.6 acpi_pci_link.c --- acpi_pci_link.c 7 Nov 2004 20:24:05 -0000 1.24.2.6 +++ acpi_pci_link.c 9 Nov 2004 03:43:52 -0000 @@ -804,17 +804,22 @@ acpi_pci_link_update_irq_penalty(device_ /* XXX try to get this IRQ in non-sharable mode. */ rid = 0; + printf("%d", irq); res = bus_alloc_resource(dev, SYS_RES_IRQ, &rid, irq, irq, 1, 0); if (res != NULL) { + printf("y"); bus_release_resource(dev, SYS_RES_IRQ, rid, res); + printf(" "); } else { /* this is in use, give 10. */ irq_penalty[irq] += 10; + printf("n "); } } + printf("\n"); /* initialize `sorted' possible IRQs. */ bcopy(link->interrupts, link->sorted_irq, sizeof(link->sorted_irq)); --ReaqsoxgOBHFXBhH-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 17:42:13 2005 Return-Path: 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 A045B16A4CE; Fri, 15 Apr 2005 17:42:13 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6076C43D54; Fri, 15 Apr 2005 17:42:12 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 5A46B7A425; Fri, 15 Apr 2005 10:42:09 -0700 (PDT) Message-ID: <425FFCF1.1080100@elischer.org> Date: Fri, 15 Apr 2005 10:42:09 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en, hu MIME-Version: 1.0 To: Giorgos Keramidas References: <425CC7F8.3030803@samsco.org> <425CD009.6040208@freebsd.org> <20050413132603.GA39006@orion.daedalusnetworks.priv> <425D2163.4090603@freebsd.org> <20050413140838.GA77217@renaissance.homeip.net> <20050413141957.GA40546@orion.daedalusnetworks.priv> <20050415055604.N93987@lexi.siliconlandmark.com> <20050415104814.GA5278@orion.daedalusnetworks.priv> <425FA2AB.4070905@freebsd.org> <20050415115005.GA5866@orion.daedalusnetworks.priv> In-Reply-To: <20050415115005.GA5866@orion.daedalusnetworks.priv> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: David Xu cc: Jiawei Ye cc: Anthony Ginepro Subject: Re: How does one know how many thread a process owns? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 17:42:13 -0000 Giorgos Keramidas wrote: >On 2005-04-15 19:16, David Xu wrote: > > >> > >I just checked what top does on SunOS, when a program has more than 999 >threads and it seems to clip the number of threads to 999, as if >something min(999, numthreads) is what is printed :-) > > you could proint " !!!" or "LOT" or do a roman numeral approx. e.g. MMC (2100).. what's roman for 10000? or 2E4 :-) >I'll change the width of THR to 4 columns if that's enough to fix the >wrapping issue of COMMAND, or even to 3 if that is not enough. Clipping >the value of numthreads to something less than or equal to 999 is also a >relatively good idea that shouldn't be too hard to implement. > >_______________________________________________ >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 Apr 15 17:44:12 2005 Return-Path: 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 D3CCA16A4CE for ; Fri, 15 Apr 2005 17:44:12 +0000 (GMT) Received: from pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FB1843D5E for ; Fri, 15 Apr 2005 17:44:12 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: from sentinel (195.198.193.104) by pne-smtpout1-sn2.hy.skanova.net (7.1.026.7) id 41E3216700CB5E77; Fri, 15 Apr 2005 19:44:09 +0200 From: "Daniel Eriksson" To: "'FreeBSD Current'" Date: Fri, 15 Apr 2005 19:44:44 +0200 Organization: Home Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <20050415095502.R34838@carver.gumbysoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcVB3fvrljJ2HSjxQlaS3k1+QVqOIQAA5Yog Subject: RE: task queue: supervisor write, page not present X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 17:44:13 -0000 Doug White wrote: > Can you get a crashdump and inspect the taskq with gdb? I'm assuming > there's a bogus entry thats getting tripped over. Dang, I was running low on space and removed the dump I had just a few hours ago since nobody had replied yet. Right now I'm back to running CURRENT as of 2005.03.11.12.00.00 (over a month old) because I know it works pretty well for me. I'm not very good with gdb. Are there any specific steps I should take to get the information needed to track this down (if I upgrade to latest CURRENT again)? Could this be related to me using a lot of r/w nullfs mounts? Thanks! /Daniel Eriksson From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 17:54:14 2005 Return-Path: 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 6649316A4CE; Fri, 15 Apr 2005 17:54:14 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34E4043D2F; Fri, 15 Apr 2005 17:54:14 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 227557A425; Fri, 15 Apr 2005 10:54:14 -0700 (PDT) Message-ID: <425FFFC5.3080504@elischer.org> Date: Fri, 15 Apr 2005 10:54:13 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en, hu MIME-Version: 1.0 To: Peter Wemm References: <200504121201.j3CC1nZ1035643@gw.catspoiler.org> <200504151005.25999.peter@wemm.org> In-Reply-To: <200504151005.25999.peter@wemm.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Don Lewis cc: freebsd-current@freebsd.org cc: current@freebsd.org cc: kris@obsecurity.org Subject: Re: Softupdates not preventing lengthy fsck X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 17:54:14 -0000 Peter Wemm wrote: >On Tuesday 12 April 2005 05:01 am, Don Lewis wrote: > > >>On 11 Apr, Kris Kennaway wrote: >> >> >>>On Mon, Apr 11, 2005 at 06:43:17PM -0700, Don Lewis wrote: >>> >>> >>>>On 11 Apr, Kris Kennaway wrote: >>>> >>>> >>>>>I'm seeing the following problem: on 6.0 machines which have had a lot >>>>>of FS activity in the past but are currently quiet, an unclean reboot >>>>>will require an hour or more of fscking and will end up clearing >>>>>thousands of inodes: >>>>> >>>>>[...] >>>>>/dev/da0s1e: UNREF FILE I=269731 OWNER=root MODE=100644 >>>>>/dev/da0s1e: SIZE=8555 MTIME=Apr 18 02:29 2002 (CLEARED) >>>>> >>>>>/dev/da0s1e: UNREF FILE I=269741 OWNER=root MODE=100644 >>>>>[...] >>>>> >>>>>It's as if dirty buffers aren't being written out properly, or >>>>>something. Has anyone else seen this? >>>>> >>>>> >>>>This looks a lot like it could be a vnode refcnt leak. Files won't get >>>>removed from the disk while they are still in use (the old unlink while >>>>open trick). Could nullfs be a factor? >>>> >>>> >>>Yes, I make extensive use of read-only nullfs. >>> >>>Kris (fsck still running) >>> >>> >>It would also be interesting to find out why fsck is taking so long to >>run. I don't see anything obvious in the code. >> >> > >One HUGE time factor in a fsck run is serial consoles. Printing tens or >hundreds of thousands of inode corrections at 9600 baud takes forever. At >work, we found that some fsck runs that would take 20+ hours could be reduced >to 15-20 minutes by simply redirecting fsck output to /dev/null instead of >the serial console. > >At work, we experimented with a memory based logging process that buffered up >its stdin and waited until the fs was writeable. > > We fsck the var partition first, then mount it and do our logging there. >eg: >fsck -p 2>&1 | memlogger /var/log/fsck.log > >Memlogger would malloc memory to hold fsck's output and periodically poll >for /var/log to become writable. (There was more to it than that, and I'm >not sure that we figured out all the quirks to make it usable in the /etc/rc >environment) > >-Peter > >_______________________________________________ >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 Apr 15 17:54:14 2005 Return-Path: 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 6649316A4CE; Fri, 15 Apr 2005 17:54:14 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34E4043D2F; Fri, 15 Apr 2005 17:54:14 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 227557A425; Fri, 15 Apr 2005 10:54:14 -0700 (PDT) Message-ID: <425FFFC5.3080504@elischer.org> Date: Fri, 15 Apr 2005 10:54:13 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en, hu MIME-Version: 1.0 To: Peter Wemm References: <200504121201.j3CC1nZ1035643@gw.catspoiler.org> <200504151005.25999.peter@wemm.org> In-Reply-To: <200504151005.25999.peter@wemm.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Don Lewis cc: freebsd-current@freebsd.org cc: current@freebsd.org cc: kris@obsecurity.org Subject: Re: Softupdates not preventing lengthy fsck X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 17:54:14 -0000 Peter Wemm wrote: >On Tuesday 12 April 2005 05:01 am, Don Lewis wrote: > > >>On 11 Apr, Kris Kennaway wrote: >> >> >>>On Mon, Apr 11, 2005 at 06:43:17PM -0700, Don Lewis wrote: >>> >>> >>>>On 11 Apr, Kris Kennaway wrote: >>>> >>>> >>>>>I'm seeing the following problem: on 6.0 machines which have had a lot >>>>>of FS activity in the past but are currently quiet, an unclean reboot >>>>>will require an hour or more of fscking and will end up clearing >>>>>thousands of inodes: >>>>> >>>>>[...] >>>>>/dev/da0s1e: UNREF FILE I=269731 OWNER=root MODE=100644 >>>>>/dev/da0s1e: SIZE=8555 MTIME=Apr 18 02:29 2002 (CLEARED) >>>>> >>>>>/dev/da0s1e: UNREF FILE I=269741 OWNER=root MODE=100644 >>>>>[...] >>>>> >>>>>It's as if dirty buffers aren't being written out properly, or >>>>>something. Has anyone else seen this? >>>>> >>>>> >>>>This looks a lot like it could be a vnode refcnt leak. Files won't get >>>>removed from the disk while they are still in use (the old unlink while >>>>open trick). Could nullfs be a factor? >>>> >>>> >>>Yes, I make extensive use of read-only nullfs. >>> >>>Kris (fsck still running) >>> >>> >>It would also be interesting to find out why fsck is taking so long to >>run. I don't see anything obvious in the code. >> >> > >One HUGE time factor in a fsck run is serial consoles. Printing tens or >hundreds of thousands of inode corrections at 9600 baud takes forever. At >work, we found that some fsck runs that would take 20+ hours could be reduced >to 15-20 minutes by simply redirecting fsck output to /dev/null instead of >the serial console. > >At work, we experimented with a memory based logging process that buffered up >its stdin and waited until the fs was writeable. > > We fsck the var partition first, then mount it and do our logging there. >eg: >fsck -p 2>&1 | memlogger /var/log/fsck.log > >Memlogger would malloc memory to hold fsck's output and periodically poll >for /var/log to become writable. (There was more to it than that, and I'm >not sure that we figured out all the quirks to make it usable in the /etc/rc >environment) > >-Peter > >_______________________________________________ >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 Apr 15 20:44:38 2005 Return-Path: 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 C4A4716A4CE; Fri, 15 Apr 2005 20:44:38 +0000 (GMT) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67DC543D41; Fri, 15 Apr 2005 20:44:38 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (localhost [127.0.0.1]) j3FKiZpe094016; Fri, 15 Apr 2005 16:44:35 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)j3FKiZwq094013; Fri, 15 Apr 2005 16:44:35 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Fri, 15 Apr 2005 16:44:35 -0400 (EDT) From: Andre Guibert de Bruet To: John Baldwin In-Reply-To: <17e130c77e0927c73945b43884069d10@FreeBSD.org> Message-ID: <20050415155645.H93987@lexi.siliconlandmark.com> References: <20050415063120.G93987@lexi.siliconlandmark.com> <17e130c77e0927c73945b43884069d10@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Information: Please contact the ISP for more information X-SL-MailScanner: Found to be clean X-SL-SpamCheck: not spam, SpamAssassin (score=-2.517, required 6, autolearn=not spam, AWL 0.08, BAYES_00 -2.60) X-MailScanner-From: andy@siliconlandmark.com cc: alc@FreeBSD.org cc: current@FreeBSD.org Subject: Re: syscons joy: reproduceable panic on resolution change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 20:44:39 -0000 On Fri, 15 Apr 2005, John Baldwin wrote: > On Apr 15, 2005, at 8:27 AM, Andre Guibert de Bruet wrote: > >> (kgdb) bt >> #9 0xc0693a18 in trap_pfault (frame=0xe900c9d8, usermode=0, eva=0) >> at /usr/src/sys/i386/i386/trap.c:724 >> #10 0xc06935f8 in trap (frame= >> {tf_fs = -1068433400, tf_es = -1056636888, tf_ds = 40, tf_edi = >> -1066508002, tf_esi = 295, tf_ebp = -385824200, tf_isp = -385824252, tf_ebx >> = 0, tf_edx = 7, tf_ecx = -385824056, tf_eax = -989770368, tf_trapno = 12, >> tf_err = 0, tf_eip = -1068379561, tf_cs = 32, tf_eflags = 66178, tf_esp = >> -1067131464, tf_ss = -1056600064}) at /usr/src/sys/i386/i386/trap.c:414 >> #11 0xc067f91a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 >> #12 0xc0510008 in idle_setup (dummy=0x0) at >> /usr/src/sys/kern/kern_idle.c:89 >> #13 0xc0645d6e in vm_fault (map=0xc1059000, vaddr=3222274048, >> fault_type=2 '\002', fault_flags=0) at /usr/src/sys/vm/vm_fault.c:295 > > You have a truly unique nested panic here that I haven't seen in a long time. > Somehow vm_map_lookup() is returning success, but it is setting > fs.first_object to NULL. This vm_map_lookup call would be performed before the callout that gets us here, right? >> #14 0xc06939c4 in trap_pfault (frame=0xe900cb9c, usermode=0, >> eva=3222274048) >> at /usr/src/sys/i386/i386/trap.c:713 >> #15 0xc06935f8 in trap (frame= >> {tf_fs = -989790200, tf_es = 40, tf_ds = -1068302296, tf_edi = >> -1072693248, tf_esi = -955760640, tf_ebp = -385823744, tf_isp = -385823800, >> tf_ebx = -1072988160, tf_edx = 1572864, tf_ecx = 319488, tf_eax = >> -116932608, tf_trapno = 12, tf_err = 3, tf_eip = -1066853962, tf_cs = 32, >> tf_eflags = 66054, tf_esp = 0, tf_ss = -986200024}) at >> /usr/src/sys/i386/i386/trap.c:414 >> #16 0xc067f91a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 >> #17 0xc5010008 in ?? () >> #18 0x00000028 in ?? () >> #19 0xc0530028 in ogetkerninfo (td=0xc537c828, uap=0xc0100000) >> at /usr/src/sys/kern/kern_sysctl.c:1440 >> #20 0xc066da8c in vga_txtdraw (scp=0xc537c800, from=0, count=786432, >> flip=0) >> at /usr/src/sys/dev/syscons/scvgarndr.c:196 > > I'm not sure why you are bcopy'ing a bad KVA here. tf_eip in #15 points to i386/i386/support.s:490. This would seem to indicate that frame #16 is our call to generic_bcopy... (kgdb) l *0xc06919b6 0xc06919b6 is at /usr/src/sys/i386/i386/support.s:490. 485 cmpl %ecx,%eax /* overlapping && src < dst? */ 486 jb 1f 487 488 shrl $2,%ecx /* copy by 32-bit words */ 489 cld /* nope, copy forwards */ 490 rep 491 movsl 492 movl 20(%esp),%ecx 493 andl $3,%ecx /* any bytes left? */ 494 rep How do we get from ogetkerninfo to generic_bcopy? I don't see ogetkerninfo getting called anywhere in the syscons driver. As you suggested, it looks like we're overlapping a vm fault over our humble syscons code path. Where to from here? Cheers, Andy | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 21:02:56 2005 Return-Path: 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 7067E16A4CE; Fri, 15 Apr 2005 21:02:56 +0000 (GMT) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1719B43D49; Fri, 15 Apr 2005 21:02:56 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (localhost [127.0.0.1]) j3FL2jJF094110; Fri, 15 Apr 2005 17:02:45 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)j3FL2c2K094104; Fri, 15 Apr 2005 17:02:38 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Fri, 15 Apr 2005 17:02:38 -0400 (EDT) From: Andre Guibert de Bruet To: Julian Elischer In-Reply-To: <425FFCF1.1080100@elischer.org> Message-ID: <20050415164941.E93987@lexi.siliconlandmark.com> References: <425CC7F8.3030803@samsco.org> <425CD009.6040208@freebsd.org> <20050413132603.GA39006@orion.daedalusnetworks.priv> <20050413140838.GA77217@renaissance.homeip.net> <20050413141957.GA40546@orion.daedalusnetworks.priv> <20050415055604.N93987@lexi.siliconlandmark.com> <425FA2AB.4070905@freebsd.org><425FFCF1.1080100@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Information: Please contact the ISP for more information X-SL-MailScanner: Found to be clean X-SL-SpamCheck: not spam, SpamAssassin (score=-2.518, required 6, autolearn=not spam, AWL 0.08, BAYES_00 -2.60) X-MailScanner-From: andy@siliconlandmark.com cc: Anthony Ginepro cc: freebsd-current@freebsd.org cc: Giorgos Keramidas cc: Jiawei Ye cc: David Xu Subject: Re: How does one know how many thread a process owns? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 21:02:56 -0000 On Fri, 15 Apr 2005, Julian Elischer wrote: > Giorgos Keramidas wrote: > >> On 2005-04-15 19:16, David Xu wrote: >> >> I just checked what top does on SunOS, when a program has more than 999 >> threads and it seems to clip the number of threads to 999, as if >> something min(999, numthreads) is what is printed :-) > > you could proint " !!!" or "LOT" > or do a roman numeral approx. > e.g. MMC (2100).. what's roman for 10000? > or 2E4 :-) I realize that top isn't an exact science, but I find that approximations are generally a bad idea. I am in favor of axing the useless CPU column and reclaiming some useful screen space for the others... :) Andy | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 21:39:16 2005 Return-Path: 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 41C6E16A4CE for ; Fri, 15 Apr 2005 21:39:16 +0000 (GMT) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06E0E43D3F for ; Fri, 15 Apr 2005 21:39:16 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id IBA74465; Fri, 15 Apr 2005 14:39:15 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 722B85D07; Fri, 15 Apr 2005 14:39:14 -0700 (PDT) To: Doug White In-reply-to: Your message of "Fri, 15 Apr 2005 10:00:32 PDT." <20050415095629.W34838@carver.gumbysoft.com> Date: Fri, 15 Apr 2005 14:39:14 -0700 From: "Kevin Oberman" Message-Id: <20050415213914.722B85D07@ptavv.es.net> cc: current@freebsd.org Subject: Re: Weird display problem in recent current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 21:39:16 -0000 > Date: Fri, 15 Apr 2005 10:00:32 -0700 (PDT) > From: Doug White > > On Tue, 12 Apr 2005, Kevin Oberman wrote: > > > Since I updated my current kernel yesterday, I have been seeing a weird > > problem that appears to be in X. I did not have the problem with the > > build I did on Friday, Apr. 8. > > > > I run gkrellm, a GTK based system monitor. I also run Gnome 2.10 and > > X.org. All of these ports are up to date. System is a P4M IBM T30. > > > > After my new kernel was installed yesterday, gkrellm would work until > > the screen blanks (screensaver set to blank). When the screen is > > re-activated, all of the applications refresh except that one. I just > > have an empty grey are where gkrellm should be. > > This is indicative of gkrellm not monitoring the X socket and getting the > refresh message. This means its stuck doing something. That's exactly what I had assumed, although I was less sure when I sent the message than I am now. > > top shows that gkrellm is continually in RUN state, although it is using > > very little CPU. > > > > The second problem is that Gnome will no longer shut down. (This may be > > an artifact of th problems gkrellm is having.) I have to > > CTRL-ALT-BS. (Ugh!) > > > > I'd look at gkrellm except that I only updated the kernel on Monday, not > > world, let alone the gkrellm port. I thought some user-land/kernel > > issue may have cropped up, so I just finished rebuilding both the kernel > > and world. No change in behavior. > > > > Any ideas what might have changed between Friday morning and today to > > cause this? I'm not even sure where to start looking. > > Being that gkrellm grubs around in the kernel, its possible some data > structre it was looking at changed and now its looping off into space. > I'd ktrace it and see what its doing when it goes awry -- that might help > isolate the affected module. If that isn't useful then remove modules > until you find the broken one. This is probably in the right direction, it won't be fast. The time it takes to lock up can be hours. That's why I am suspicious that it is some sort of resource exhaustion rather than simply pointing out to nowhere. ktrace is the obvious tool, but, having never used it before, I did not think of it. Thanks so much for getting back to me on this. My -current system is down for a while as I am building a new system on it and need to get the 5.4-RC2 disk burned. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 22:42:28 2005 Return-Path: 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 6073F16A4CE for ; Fri, 15 Apr 2005 22:42:28 +0000 (GMT) Received: from mail28.sea5.speakeasy.net (mail28.sea5.speakeasy.net [69.17.117.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id D14FE43D58 for ; Fri, 15 Apr 2005 22:42:27 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 11562 invoked from network); 15 Apr 2005 22:42:27 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 15 Apr 2005 22:42:27 -0000 Received: from [131.106.58.175] (p181.n-lapop01.stsn.com [12.129.240.181]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j3FMgKnv047772; Fri, 15 Apr 2005 18:42:21 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Andre Guibert de Bruet Date: Fri, 15 Apr 2005 18:23:38 -0400 User-Agent: KMail/1.8 References: <20050415063120.G93987@lexi.siliconlandmark.com> <17e130c77e0927c73945b43884069d10@FreeBSD.org> <20050415155645.H93987@lexi.siliconlandmark.com> In-Reply-To: <20050415155645.H93987@lexi.siliconlandmark.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504151823.39629.jhb@FreeBSD.org> X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: alc@FreeBSD.org cc: current@FreeBSD.org Subject: Re: syscons joy: reproduceable panic on resolution change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 22:42:28 -0000 On Friday 15 April 2005 04:44 pm, Andre Guibert de Bruet wrote: > On Fri, 15 Apr 2005, John Baldwin wrote: > > On Apr 15, 2005, at 8:27 AM, Andre Guibert de Bruet wrote: > >> (kgdb) bt > > > > >> #9 0xc0693a18 in trap_pfault (frame=0xe900c9d8, usermode=0, eva=0) > >> at /usr/src/sys/i386/i386/trap.c:724 > >> #10 0xc06935f8 in trap (frame= > >> {tf_fs = -1068433400, tf_es = -1056636888, tf_ds = 40, tf_edi = > >> -1066508002, tf_esi = 295, tf_ebp = -385824200, tf_isp = -385824252, > >> tf_ebx = 0, tf_edx = 7, tf_ecx = -385824056, tf_eax = -989770368, > >> tf_trapno = 12, tf_err = 0, tf_eip = -1068379561, tf_cs = 32, tf_eflags > >> = 66178, tf_esp = -1067131464, tf_ss = -1056600064}) at > >> /usr/src/sys/i386/i386/trap.c:414 #11 0xc067f91a in calltrap () at > >> /usr/src/sys/i386/i386/exception.s:139 #12 0xc0510008 in idle_setup > >> (dummy=0x0) at > >> /usr/src/sys/kern/kern_idle.c:89 > >> #13 0xc0645d6e in vm_fault (map=0xc1059000, vaddr=3222274048, > >> fault_type=2 '\002', fault_flags=0) at > >> /usr/src/sys/vm/vm_fault.c:295 > > > > You have a truly unique nested panic here that I haven't seen in a long > > time. Somehow vm_map_lookup() is returning success, but it is setting > > fs.first_object to NULL. > > This vm_map_lookup call would be performed before the callout that gets us > here, right? Yes. it's earlier in the vm_fault() function. > >> #14 0xc06939c4 in trap_pfault (frame=0xe900cb9c, usermode=0, > >> eva=3222274048) > >> at /usr/src/sys/i386/i386/trap.c:713 > >> #15 0xc06935f8 in trap (frame= > >> {tf_fs = -989790200, tf_es = 40, tf_ds = -1068302296, tf_edi = > >> -1072693248, tf_esi = -955760640, tf_ebp = -385823744, tf_isp = > >> -385823800, tf_ebx = -1072988160, tf_edx = 1572864, tf_ecx = 319488, > >> tf_eax = -116932608, tf_trapno = 12, tf_err = 3, tf_eip = -1066853962, > >> tf_cs = 32, tf_eflags = 66054, tf_esp = 0, tf_ss = -986200024}) at > >> /usr/src/sys/i386/i386/trap.c:414 > >> #16 0xc067f91a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > >> #17 0xc5010008 in ?? () > >> #18 0x00000028 in ?? () > >> #19 0xc0530028 in ogetkerninfo (td=0xc537c828, uap=0xc0100000) > >> at /usr/src/sys/kern/kern_sysctl.c:1440 > >> #20 0xc066da8c in vga_txtdraw (scp=0xc537c800, from=0, count=786432, > >> flip=0) > >> at /usr/src/sys/dev/syscons/scvgarndr.c:196 > > > > I'm not sure why you are bcopy'ing a bad KVA here. > > tf_eip in #15 points to i386/i386/support.s:490. This would seem to > indicate that frame #16 is our call to generic_bcopy... Oh, I know it's calling bcopy(). My point is that I don't see anything obviously wrong with the call to bcopy() in vga_txtdraw(). > How do we get from ogetkerninfo to generic_bcopy? I don't see ogetkerninfo > getting called anywhere in the syscons driver. As you suggested, it looks > like we're overlapping a vm fault over our humble syscons code path. The ogetkerninfo is a red herring because gdb doesn't know how to handle trap frames correctly. > Where to from here? Well, if you can reproduce this you can start looking at what is being passed to bcopy() in the vga function to try and figure out what is happening. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sat Apr 16 00:26:33 2005 Return-Path: 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 57A1316A4CE for ; Sat, 16 Apr 2005 00:26:33 +0000 (GMT) Received: from nixil.org (nixil.net [161.58.222.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8167043D2D for ; Sat, 16 Apr 2005 00:26:32 +0000 (GMT) (envelope-from oz@nixil.net) Received: from [10.20.12.64] (fw.oremut02.us.wh.verio.net [198.65.168.24]) (authenticated bits=0) by nixil.org (8.13.1/8.13.1) with ESMTP id j3G0QVFT087842 for ; Fri, 15 Apr 2005 18:26:32 -0600 (MDT) Message-ID: <42605BAF.8040707@nixil.net> Date: Fri, 15 Apr 2005 18:26:23 -0600 From: Phil Oleson User-Agent: Mozilla Thunderbird 1.0 (X11/20050323) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4244AC9C.7010803@nixil.net> <20050326030927.GA86483@xor.obsecurity.org> <424CAF89.60209@nixil.net> <20050331233821.Q328@sasami.jurai.net> <424DD28E.9040000@nixil.net> <20050401203604.B22960@sasami.jurai.net> In-Reply-To: <20050401203604.B22960@sasami.jurai.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-1.5.6 (nixil.org [161.58.222.1]); Fri, 15 Apr 2005 18:26:32 -0600 (MDT) X-Virus-Scanned: ClamAV 0.83/832/Fri Apr 15 16:24:08 2005 on nixil.org X-Virus-Status: Clean Subject: Re: request: libedit sync X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 16 Apr 2005 00:26:33 -0000 So.. could someone with the commit privs take a look at http://www.freebsd.org/cgi/query-pr.cgi?pr=79418 and consider checking in these patches. The diff's were taken from cvs HEAD snapshots event though I logged my 5.4pre system in the PR info. Phil. From owner-freebsd-current@FreeBSD.ORG Sat Apr 16 01:10:47 2005 Return-Path: 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 85FE716A4CE; Sat, 16 Apr 2005 01:10:47 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9DE8F43D54; Sat, 16 Apr 2005 01:10:46 +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 j3G1AklZ032957; Fri, 15 Apr 2005 21:10: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 j3G1AwSb074975; Fri, 15 Apr 2005 21:10:59 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id A3AD57306E; Fri, 15 Apr 2005 21:10:45 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050416011045.A3AD57306E@freebsd-current.sentex.ca> Date: Fri, 15 Apr 2005 21:10:45 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.82, clamav-milter version 0.82 on clamscanner4 X-Virus-Status: Clean Subject: [current tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2005 01:10:47 -0000 TB --- 2005-04-15 23:22:50 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-15 23:22:50 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2005-04-15 23:22:50 - checking out the source tree TB --- 2005-04-15 23:22:50 - cd /home/tinderbox/CURRENT/ia64/ia64 TB --- 2005-04-15 23:22:50 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-15 23:29:12 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-15 23:29:12 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2005-04-15 23:29: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-04-16 01:01:12 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-16 01:01:12 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2005-04-16 01:01:12 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Apr 16 01:01:12 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 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/ia64/ia64/src/sys -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/altq -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/pf -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/ia64/ia64/src/sys/dev/twa -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/CURRENT/ia64/ia64 /src/sys/vm/vm_meter.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 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/ia64/ia64/src/sys -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/altq -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/pf -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/ia64/ia64/src/sys/dev/twa -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/CURRENT/ia64/ia64 /src/sys/vm/vm_mmap.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 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/ia64/ia64/src/sys -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/altq -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/pf -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/ia64/ia64/src/sys/dev/twa -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/CURRENT/ia64/ia64 /src/sys/vm/vm_object.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 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/ia64/ia64/src/sys -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/altq -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/pf -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/ia64/ia64/src/sys/dev/twa -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/CURRENT/ia64/ia64 /src/sys/vm/vm_page.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 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/ia64/ia64/src/sys -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/altq -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/pf -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/ia64/ia64/src/sys/dev/twa -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/CURRENT/ia64/ia64 /src/sys/vm/vm_pageout.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 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/ia64/ia64/src/sys -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/altq -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/pf -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/ia64/ia64/src/sys/dev/twa -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/CURRENT/ia64/ia64 /src/sys/vm/vm_pageq.c /tinderbox/CURRENT/ia64/ia64/src/sys/vm/vm_pageq.c: In function `vm_pageq_add_new_page': /tinderbox/CURRENT/ia64/ia64/src/sys/vm/vm_pageq.c:133: warning: unsigned int format, different type arg (arg 2) *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. TB --- 2005-04-16 01:10:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-16 01:10:45 - ERROR: failed to build generic kernel TB --- 2005-04-16 01:10:45 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sat Apr 16 01:48:07 2005 Return-Path: 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 D7FC916A4CE; Sat, 16 Apr 2005 01:48:07 +0000 (GMT) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67CBB43D1D; Sat, 16 Apr 2005 01:48:07 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (localhost [127.0.0.1]) j3G1m3ZW095574; Fri, 15 Apr 2005 21:48:03 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)j3G1m3jT095571; Fri, 15 Apr 2005 21:48:03 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Fri, 15 Apr 2005 21:48:02 -0400 (EDT) From: Andre Guibert de Bruet To: John Baldwin In-Reply-To: <200504151823.39629.jhb@FreeBSD.org> Message-ID: <20050415213404.E93987@lexi.siliconlandmark.com> References: <20050415063120.G93987@lexi.siliconlandmark.com> <20050415155645.H93987@lexi.siliconlandmark.com> <200504151823.39629.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Information: Please contact the ISP for more information X-SL-MailScanner: Found to be clean X-SL-SpamCheck: not spam, SpamAssassin (score=-2.519, required 6, autolearn=not spam, AWL 0.08, BAYES_00 -2.60) X-MailScanner-From: andy@siliconlandmark.com cc: alc@FreeBSD.org cc: current@FreeBSD.org Subject: Re: syscons joy: reproduceable panic on resolution change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 16 Apr 2005 01:48:08 -0000 On Fri, 15 Apr 2005, John Baldwin wrote: > On Friday 15 April 2005 04:44 pm, Andre Guibert de Bruet wrote: >> On Fri, 15 Apr 2005, John Baldwin wrote: >>> On Apr 15, 2005, at 8:27 AM, Andre Guibert de Bruet wrote: >>>> #13 0xc0645d6e in vm_fault (map=0xc1059000, vaddr=3222274048, >>>> fault_type=2 '\002', fault_flags=0) at >>>> /usr/src/sys/vm/vm_fault.c:295 >>> >>> You have a truly unique nested panic here that I haven't seen in a long >>> time. Somehow vm_map_lookup() is returning success, but it is setting >>> fs.first_object to NULL. >> >> This vm_map_lookup call would be performed before the callout that gets us >> here, right? > > Yes. it's earlier in the vm_fault() function. Fair enough. >>>> #14 0xc06939c4 in trap_pfault (frame=0xe900cb9c, usermode=0, >>>> eva=3222274048) >>>> at /usr/src/sys/i386/i386/trap.c:713 >>>> #15 0xc06935f8 in trap (frame= >>>> {tf_fs = -989790200, tf_es = 40, tf_ds = -1068302296, tf_edi = >>>> -1072693248, tf_esi = -955760640, tf_ebp = -385823744, tf_isp = >>>> -385823800, tf_ebx = -1072988160, tf_edx = 1572864, tf_ecx = 319488, >>>> tf_eax = -116932608, tf_trapno = 12, tf_err = 3, tf_eip = -1066853962, >>>> tf_cs = 32, tf_eflags = 66054, tf_esp = 0, tf_ss = -986200024}) at >>>> /usr/src/sys/i386/i386/trap.c:414 >>>> #16 0xc067f91a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 >>>> #17 0xc5010008 in ?? () >>>> #18 0x00000028 in ?? () >>>> #19 0xc0530028 in ogetkerninfo (td=0xc537c828, uap=0xc0100000) >>>> at /usr/src/sys/kern/kern_sysctl.c:1440 >>>> #20 0xc066da8c in vga_txtdraw (scp=0xc537c800, from=0, count=786432, >>>> flip=0) >>>> at /usr/src/sys/dev/syscons/scvgarndr.c:196 >>> >>> I'm not sure why you are bcopy'ing a bad KVA here. >> >> tf_eip in #15 points to i386/i386/support.s:490. This would seem to >> indicate that frame #16 is our call to generic_bcopy... > > Oh, I know it's calling bcopy(). My point is that I don't see anything > obviously wrong with the call to bcopy() in vga_txtdraw(). > >> How do we get from ogetkerninfo to generic_bcopy? I don't see ogetkerninfo >> getting called anywhere in the syscons driver. As you suggested, it looks >> like we're overlapping a vm fault over our humble syscons code path. > > The ogetkerninfo is a red herring because gdb doesn't know how to handle trap > frames correctly. > >> Where to from here? > > Well, if you can reproduce this you can start looking at what is being passed > to bcopy() in the vga function to try and figure out what is happening. I am currently 40 miles (64 km) away from this system so it is sort of hard to switch VTs. I do have ssh access to the machine and the corefile that I obtained. I can spend some time this weekend trying to figure out a SoE for this... Wish me luck! Thanks John! Andy | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > From owner-freebsd-current@FreeBSD.ORG Sat Apr 16 02:56:50 2005 Return-Path: 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 C6FC416A4CE for ; Sat, 16 Apr 2005 02:56:50 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A56F943D41 for ; Sat, 16 Apr 2005 02:56:50 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 9709F72DE4; Fri, 15 Apr 2005 19:56:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 917EB72DDB; Fri, 15 Apr 2005 19:56:50 -0700 (PDT) Date: Fri, 15 Apr 2005 19:56:50 -0700 (PDT) From: Doug White To: Daniel Eriksson In-Reply-To: Message-ID: <20050415195545.W38788@carver.gumbysoft.com> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: 'FreeBSD Current' Subject: RE: task queue: supervisor write, page not present X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 16 Apr 2005 02:56:50 -0000 On Fri, 15 Apr 2005, Daniel Eriksson wrote: > Doug White wrote: > > > Can you get a crashdump and inspect the taskq with gdb? I'm assuming > > there's a bogus entry thats getting tripped over. > > Dang, I was running low on space and removed the dump I had just a few hours > ago since nobody had replied yet. Sorry, we don't guarantee 4 hour response -- that costs money. :) > Right now I'm back to running CURRENT as of 2005.03.11.12.00.00 (over a > month old) because I know it works pretty well for me. > > I'm not very good with gdb. Are there any specific steps I should take to > get the information needed to track this down (if I upgrade to latest > CURRENT again)? Could this be related to me using a lot of r/w nullfs > mounts? I don't think so... nullfs has it sown problems, but not random memory corruption. Next time, could you make the crashdump and debug kernel available for download? -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sat Apr 16 03:49:20 2005 Return-Path: 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 0CE2216A4CE; Sat, 16 Apr 2005 03:49:20 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DB4043D72; Sat, 16 Apr 2005 03:49:19 +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 j3G3nIBc038207; Fri, 15 Apr 2005 23:49:18 -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 j3G3nIo5012257; Fri, 15 Apr 2005 23:49:18 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 590647306E; Fri, 15 Apr 2005 23:49:18 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050416034918.590647306E@freebsd-current.sentex.ca> Date: Fri, 15 Apr 2005 23:49:18 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on clamscanner2 X-Virus-Status: Clean Subject: [current tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2005 03:49:20 -0000 TB --- 2005-04-16 02:29:45 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-16 02:29:45 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2005-04-16 02:29:45 - checking out the source tree TB --- 2005-04-16 02:29:45 - cd /home/tinderbox/CURRENT/sparc64/sparc64 TB --- 2005-04-16 02:29:45 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-16 02:36:26 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-16 02:36:26 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-04-16 02:36:26 - /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-04-16 03:43:34 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-16 03:43:34 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-04-16 03:43:34 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Apr 16 03:43:35 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 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medlow -msoft-float -ffreestanding -Werror /tinderbox/CURRENT/sparc64/sparc64/src/sys/vm/vm_meter.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 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medlow -msoft-float -ffreestanding -Werror /tinderbox/CURRENT/sparc64/sparc64/src/sys/vm/vm_mmap.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 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medlow -msoft-float -ffreestanding -Werror /tinderbox/CURRENT/sparc64/sparc64/src/sys/vm/vm_object.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 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medlow -msoft-float -ffreestanding -Werror /tinderbox/CURRENT/sparc64/sparc64/src/sys/vm/vm_page.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 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medlow -msoft-float -ffreestanding -Werror /tinderbox/CURRENT/sparc64/sparc64/src/sys/vm/vm_pageout.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 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medlow -msoft-float -ffreestanding -Werror /tinderbox/CURRENT/sparc64/sparc64/src/sys/vm/vm_pageq.c /tinderbox/CURRENT/sparc64/sparc64/src/sys/vm/vm_pageq.c: In function `vm_pageq_add_new_page': /tinderbox/CURRENT/sparc64/sparc64/src/sys/vm/vm_pageq.c:133: warning: unsigned int format, different type arg (arg 2) *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2005-04-16 03:49:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-16 03:49:18 - ERROR: failed to build generic kernel TB --- 2005-04-16 03:49:18 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sat Apr 16 04:19:50 2005 Return-Path: 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 B193B16A4CE; Sat, 16 Apr 2005 04:19:50 +0000 (GMT) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92AA443D5F; Sat, 16 Apr 2005 04:19:49 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.12.11/8.12.10) with ESMTP id j3G4JjLp015885; Sat, 16 Apr 2005 13:49:46 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Sat, 16 Apr 2005 13:49:38 +0930 User-Agent: KMail/1.8 References: <20050415063120.G93987@lexi.siliconlandmark.com> <200504151823.39629.jhb@FreeBSD.org> <20050415213404.E93987@lexi.siliconlandmark.com> In-Reply-To: <20050415213404.E93987@lexi.siliconlandmark.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart8189420.iGy96xjs1P"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504161349.39693.doconnor@gsoft.com.au> X-Spam-Score: -2.5 () IN_REP_TO,PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) cc: alc@freebsd.org cc: current@freebsd.org Subject: Re: syscons joy: reproduceable panic on resolution change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 16 Apr 2005 04:19:50 -0000 --nextPart8189420.iGy96xjs1P Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sat, 16 Apr 2005 11:18, Andre Guibert de Bruet wrote: > I am currently 40 miles (64 km) away from this system so it is sort of > hard to switch VTs. I do have ssh access to the machine and the corefile > that I obtained. I can spend some time this weekend trying to figure out a > SoE for this... Wish me luck! Does vidcontrol -s X cause the problem? =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart8189420.iGy96xjs1P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBCYJJb5ZPcIHs/zowRApYMAKCB5AjXcGJZ7jWedUrH90I5mI78YgCeJEF6 sI6AMXAVQXR4sJel1HoZQJw= =O1Fg -----END PGP SIGNATURE----- --nextPart8189420.iGy96xjs1P-- From owner-freebsd-current@FreeBSD.ORG Sat Apr 16 04:19:50 2005 Return-Path: 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 B193B16A4CE; Sat, 16 Apr 2005 04:19:50 +0000 (GMT) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92AA443D5F; Sat, 16 Apr 2005 04:19:49 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.12.11/8.12.10) with ESMTP id j3G4JjLp015885; Sat, 16 Apr 2005 13:49:46 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Sat, 16 Apr 2005 13:49:38 +0930 User-Agent: KMail/1.8 References: <20050415063120.G93987@lexi.siliconlandmark.com> <200504151823.39629.jhb@FreeBSD.org> <20050415213404.E93987@lexi.siliconlandmark.com> In-Reply-To: <20050415213404.E93987@lexi.siliconlandmark.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart8189420.iGy96xjs1P"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504161349.39693.doconnor@gsoft.com.au> X-Spam-Score: -2.5 () IN_REP_TO,PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) cc: alc@freebsd.org cc: current@freebsd.org Subject: Re: syscons joy: reproduceable panic on resolution change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 16 Apr 2005 04:19:50 -0000 --nextPart8189420.iGy96xjs1P Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sat, 16 Apr 2005 11:18, Andre Guibert de Bruet wrote: > I am currently 40 miles (64 km) away from this system so it is sort of > hard to switch VTs. I do have ssh access to the machine and the corefile > that I obtained. I can spend some time this weekend trying to figure out a > SoE for this... Wish me luck! Does vidcontrol -s X cause the problem? =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart8189420.iGy96xjs1P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBCYJJb5ZPcIHs/zowRApYMAKCB5AjXcGJZ7jWedUrH90I5mI78YgCeJEF6 sI6AMXAVQXR4sJel1HoZQJw= =O1Fg -----END PGP SIGNATURE----- --nextPart8189420.iGy96xjs1P-- From owner-freebsd-current@FreeBSD.ORG Sat Apr 16 05:55:39 2005 Return-Path: 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 BE17416A4CE for ; Sat, 16 Apr 2005 05:55:39 +0000 (GMT) Received: from portpc-design.spb.ru (ns2.portpc-design.spb.ru [195.161.118.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BFC843D41 for ; Sat, 16 Apr 2005 05:55:38 +0000 (GMT) (envelope-from mcsi@mcsi.pp.ru) Received: from [83.237.208.89] (ppp83-237-208-89.pppoe.mtu-net.ru [83.237.208.89]) (authenticated bits=0) by portpc-design.spb.ru (8.13.4/8.13.4) with ESMTP id j3G5tZrh018553 for ; Sat, 16 Apr 2005 09:55:35 +0400 (MSD) (envelope-from mcsi@mcsi.pp.ru) Message-ID: <4260A8D1.2040203@mcsi.pp.ru> Date: Sat, 16 Apr 2005 09:55:29 +0400 From: Maxim Maximov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.6) Gecko/20050326 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 81.176.64.226 X-Virus-Status: Clean Subject: current panics X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 16 Apr 2005 05:55:39 -0000 Hi, I'm getting reproducible panic on latest current. FreeBSD is running on notebook with USB kbd attached FWIW. Mon Apr 11 22:01:59 MSD kernel doesn't have this problem. 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-CURRENT #1: Fri Apr 15 19:09:49 MSD 2005 mcsi@ultra.domain:/usr/obj/usr/src/sys/ULTRA WARNING: WITNESS option enabled, expect reduced performance. ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2992.52-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff Hyperthreading: 2 logical CPUs real memory = 536674304 (511 MB) avail memory = 514891776 (491 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) acpi_ec0: port 0x62,0x66 on acpi0 acpi_ec0: can't allocate data port device_attach: acpi_ec0 attach returned 6 pci_link0: irq 9 on acpi0 pci_link1: irq 5 on acpi0 pci_link2: irq 5 on acpi0 pci_link3: irq 0 on acpi0 pci_link4: irq 0 on acpi0 pci_link5: irq 0 on acpi0 pci_link6: irq 0 on acpi0 pci_link7: irq 5 on acpi0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 cpu0: on acpi0 p4tcc0: on cpu0 cpu1: on acpi0 p4tcc1: on cpu1 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) uhci0: port 0xe000-0xe01f 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 0xe400-0xe41f 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 0xe800-0xe81f 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 0xec00-0xec1f 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 0xfebffc00-0xfebfffff 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 pcib2: at device 30.0 on pci0 pci2: on pcib2 skc0: <3Com 3C940 Gigabit Ethernet> port 0xa800-0xa8ff mem 0xfeafc000-0xfeafffff irq 18 at device 0.0 on pci2 skc0: interrupt moderation is 100 us skc0: 3Com Gigabit LOM (3C940) rev. (0x1) sk0: on skc0 sk0: Ethernet address: 00:0e:a6:b9:f9:f8 miibus0: on sk0 e1000phy0: on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto cbb0: irq 16 at device 1.0 on pci2 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb1: irq 17 at device 1.1 on pci2 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 fwohci0: mem 0xfeafb000-0xfeafb7ff irq 18 at device 1.2 on pci2 fwohci0: OHCI version 1.0 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:e0:18:00:03:18:f3:bc fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:e0:18:18:f3:bc fwe0: Ethernet address: 02:e0:18:18:f3:bc fwe0: if_start running deferred for Giant sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) pci2: at device 1.3 (no driver attached) pci2: at device 1.4 (no driver attached) ndis0: mem 0xfeaf8000-0xfeaf9fff irq 17 at device 2.0 on pci2 ndis0: NDIS API version: 5.0 ndis0: Ethernet address: 00:0e:a6:c2:00:e4 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 pcm0: port 0xd400-0xd4ff,0xd000-0xd03f mem 0xfebff800-0xfebff9ff,0xfebff400-0xfebff4ff irq 17 at device 31.5 on pci0 pcm0: [GIANT-LOCKED] pcm0: pci0: at device 31.6 (no driver attached) acpi_button0: on acpi0 acpi_lid0: on acpi0 acpi_button1: on acpi0 acpi_tz0: on acpi0 acpi_acad0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0xc0824bef stack pointer = 0x28:0xc0c20a94 frame pointer = 0x28:0xc0c21f74 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) [thread pid 0 tid 0] Stopped at vm86_boisret+0x4f: pop %gs db> trace Tracing pid 0 tid 0 td 0xc09c8460 vm86_biosret(c0c21fa8) at vm86_biosret+0x4f trap(0,0,0,0,0) at trap+0x37a calltrap() at calltrap+0x5 -- Maxim Maximov From owner-freebsd-current@FreeBSD.ORG Sat Apr 16 08:14:51 2005 Return-Path: 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 089DD16A4CF for ; Sat, 16 Apr 2005 08:14:51 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B34E43D2D for ; Sat, 16 Apr 2005 08:14:50 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by rproxy.gmail.com with SMTP id j1so721875rnf for ; Sat, 16 Apr 2005 01:14:50 -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:content-transfer-encoding:content-disposition; b=E9dsz7znZiIuIrwWz2Ks7jr1OSDyyyYGtD7R4+IIFQzGSdafiHHcFRzZpQU1nytNepIGN+hAqRh+Nr2k+sjJK9ZQivA4uL0reoSMVP50iwnriq2bjrReOXQyJpEKlG2MjUOeW3lIwj9vbMUWG/7AhrBmQqJgi7T4cJvsPyRz/Bc= Received: by 10.38.209.15 with SMTP id h15mr193641rng; Sat, 16 Apr 2005 01:14:50 -0700 (PDT) Received: by 10.38.209.22 with HTTP; Sat, 16 Apr 2005 01:14:50 -0700 (PDT) Message-ID: <84dead72050416011463890e0e@mail.gmail.com> Date: Sat, 16 Apr 2005 08:14:50 +0000 From: Joseph Koshy To: freebsd-performance@freebsd.org, FreeBSD Current Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: New snapshot of the CPU performance monitoring counter work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Joseph Koshy List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2005 08:14:51 -0000 A new snapshot of the CPU PMC driver and associated userland tools is available. o Support for performance monitoring counters in Intel(r) Pentium=20 Pro, Pentium-II, Pentium-III, Celeron and Pentium-M has been added. o A Python interface to libpmc has been added. o Many bug fixes, esp. for P4/HTT CPUs. http://people.freebsd.org/~jkoshy/projects/perf-measurement/snapshot-6.html From owner-freebsd-current@FreeBSD.ORG Sat Apr 16 09:21:54 2005 Return-Path: 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 D133D16A4CE; Sat, 16 Apr 2005 09:21:54 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB74943D46; Sat, 16 Apr 2005 09:21:54 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j3G9LnuY066385; Sat, 16 Apr 2005 09:21:50 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4260D92C.1030703@freebsd.org> Date: Sat, 16 Apr 2005 17:21:48 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050306 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andre Guibert de Bruet References: <425CC7F8.3030803@samsco.org> <425CD009.6040208@freebsd.org> <20050413132603.GA39006@orion.daedalusnetworks.priv> <20050413140838.GA77217@renaissance.homeip.net> <20050413141957.GA40546@orion.daedalusnetworks.priv> <20050415055604.N93987@lexi.siliconlandmark.com> <425FA2AB.4070905@freebsd.org><425FFCF1.1080100@elischer.org> <20050415164941.E93987@lexi.siliconlandmark.com> In-Reply-To: <20050415164941.E93987@lexi.siliconlandmark.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: Giorgos Keramidas cc: Julian Elischer cc: Jiawei Ye cc: Anthony Ginepro Subject: Re: How does one know how many thread a process owns? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 16 Apr 2005 09:21:54 -0000 Andre Guibert de Bruet wrote: > > On Fri, 15 Apr 2005, Julian Elischer wrote: > >> Giorgos Keramidas wrote: >> >>> On 2005-04-15 19:16, David Xu wrote: >>> >>> I just checked what top does on SunOS, when a program has more than 999 >>> threads and it seems to clip the number of threads to 999, as if >>> something min(999, numthreads) is what is printed :-) >> >> >> you could proint " !!!" or "LOT" >> or do a roman numeral approx. >> e.g. MMC (2100).. what's roman for 10000? >> or 2E4 :-) > > > I realize that top isn't an exact science, but I find that > approximations are generally a bad idea. I am in favor of axing the > useless CPU column and reclaiming some useful screen space for the > others... :) > > Andy > > | Andre Guibert de Bruet | Enterprise Software Consultant > > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > CPU column is not very useful when displaying process and thread count, if it is only useful if it is displaying individual thread which is activated by 'H' key. David Xu From owner-freebsd-current@FreeBSD.ORG Sat Apr 16 09:28:34 2005 Return-Path: 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 A439016A4CF; Sat, 16 Apr 2005 09:28:34 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 856BF43D39; Sat, 16 Apr 2005 09:28:34 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j3G9SO6H066458; Sat, 16 Apr 2005 09:28:26 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4260DAB7.6010204@freebsd.org> Date: Sat, 16 Apr 2005 17:28:23 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050306 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Xu References: <425CC7F8.3030803@samsco.org> <425CD009.6040208@freebsd.org> <20050413132603.GA39006@orion.daedalusnetworks.priv> <20050413140838.GA77217@renaissance.homeip.net> <20050413141957.GA40546@orion.daedalusnetworks.priv> <20050415055604.N93987@lexi.siliconlandmark.com> <425FA2AB.4070905@freebsd.org><425FFCF1.1080100@elischer.org> <20050415164941.E93987@lexi.siliconlandmark.com> <4260D92C.1030703@freebsd.org> In-Reply-To: <4260D92C.1030703@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Anthony Ginepro cc: freebsd-current@freebsd.org cc: Giorgos Keramidas cc: Jiawei Ye cc: Julian Elischer Subject: Re: How does one know how many thread a process owns? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 16 Apr 2005 09:28:34 -0000 David Xu wrote: Oops, > > CPU column is not very useful when displaying process and ^C column, not very useful. > thread count, if it is only useful if it is displaying individual > thread which is activated by 'H' key. > > David Xu > From owner-freebsd-current@FreeBSD.ORG Sat Apr 16 09:51:20 2005 Return-Path: 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 5036516A4CE for ; Sat, 16 Apr 2005 09:51:20 +0000 (GMT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DB5B43D2D for ; Sat, 16 Apr 2005 09:51:19 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru (8.13.0/vak/3.0) id j3G9mQUF008460 for freebsd-current@freebsd.org.checked; Sat, 16 Apr 2005 13:48:26 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from cronyx.ru (localhost.cronyx.ru [127.0.0.1]) by hanoi.cronyx.ru (8.13.0/vak/3.0) with ESMTP id j3G9kPEt008451; Sat, 16 Apr 2005 13:46:25 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <4260DCB2.1000108@cronyx.ru> Date: Sat, 16 Apr 2005 13:36:50 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.2.1) Gecko/20030426 X-Accept-Language: ru-ru, en MIME-Version: 1.0 To: Max Laier References: <200504080220.57899.max@love2party.net> <4256F545.90401@elischer.org> <200504151342.07851.max@love2party.net> In-Reply-To: <200504151342.07851.max@love2party.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org cc: freebsd-current@freebsd.org cc: monthly@freebsd.org Subject: Re: Call for FreeBSD status reports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 16 Apr 2005 09:51:20 -0000 IIRC most of reports should valid from the last call since they wasn't published. Am I right, or we should send them again? rik Max Laier: >All, > >as I wrote last week: > > >>Submissions are due on April 15. Thanks a lot, and we are hoping for a >>big turn-out. >> >> > >As always this is not final, but please get your reports ready by monday and >maybe let us know that you are planing to submit. Unfortunately we have a >dramatically lower turn-out so far, I hope to see more reports floating in >over the weekend. Thanks a lot! > >http://www.FreeBSD.org/news/status/ > > > From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 19:08:15 2005 Return-Path: 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 8388A16A4CE for ; Fri, 15 Apr 2005 19:08:15 +0000 (GMT) Received: from natasha.tepid.org (natasha.tepid.org [68.148.0.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A4F743D3F for ; Fri, 15 Apr 2005 19:08:15 +0000 (GMT) (envelope-from weingart@tepid.org) Received: from natasha.tepid.org (localhost [127.0.0.1]) by natasha.tepid.org (Postfix) with ESMTP id BAC543F3C; Fri, 15 Apr 2005 13:08:14 -0600 (MDT) To: Peter Jeremy In-Reply-To: Message from Peter Jeremy <20050414210840.GT89047@cirb503493.alcatel.com.au> Date: Fri, 15 Apr 2005 13:08:14 -0600 Message-ID: <163.1113592094@natasha.tepid.org> From: Tobias Weingartner X-Mailman-Approved-At: Sat, 16 Apr 2005 12:00:03 +0000 cc: Ted Unangst cc: tech@openbsd.org cc: freebsd-current@freebsd.org Subject: Re: strtonum(3) in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 19:08:15 -0000 On Friday, April 15, Peter Jeremy wrote: > > This means you can't use it in a simple parser to handle the user > entering "10k" to mean 10000 or "128m" to mean 128000000. dd(1) needs > this and I've used it on occasion. Again, it's being sold as a > replacement for strtol() but isn't. 10k is 10 * 1024, not 10000. And yes, dd(1) interprets it that way. My pet peave... K, M, G, T are the 2^whatever versions when we're talking about computer quantities. Why do we have to introduce Ki- whatever? If you need the power that strtol() can provide, then yes, you need strtol() and/or it's cousins. Most of the time you do not need that sort of power (or their extensions). The strtonum() function will do what you want just fine. So, pick your poison. Make your choice. Live with them. --Toby. From owner-freebsd-current@FreeBSD.ORG Sat Apr 16 02:00:34 2005 Return-Path: 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 4264F16A4CF for ; Sat, 16 Apr 2005 02:00:34 +0000 (GMT) Received: from thor.66h.42h.de (mirsolutions.de [81.169.132.156]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9567343D49 for ; Sat, 16 Apr 2005 02:00:30 +0000 (GMT) (envelope-from tg@66h.42h.de) Received: from odem.66h.42h.de (root@odem.66h.42h.de [IPv6:2001:6f8:94d:1:2c0:9fff:fe1a:6a01]) by thor.66h.42h.de (8.13.1/8.13.1) with ESMTP id j3G20Mkj007729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 16 Apr 2005 02:00:25 GMT Received: from localhost (tg@localhost [IPv6:::1]) by odem.66h.42h.de (8.13.3/8.13.3) with ESMTP id j3G20J2p004698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 Apr 2005 02:00:20 GMT Date: Sat, 16 Apr 2005 02:00:18 +0000 (UTC) From: Thorsten Glaser In-Reply-To: <163.1113592094@natasha.tepid.org> Message-ID: References: <163.1113592094@natasha.tepid.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Sat, 16 Apr 2005 12:00:03 +0000 cc: tech@openbsd.org cc: freebsd-current@freebsd.org Subject: Re: strtonum(3) in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 16 Apr 2005 02:00:34 -0000 Tobias Weingartner dixit: >Why do we have to introduce Ki- >whatever? SI and IEC 60027-2 say: k = 1000 M = 1000000 m = 1/1000 K may so be 1024, but M may not, because M must be 1000000, always. SI prefices are the same among all units. //mirabile -- > Hi, does anyone sell openbsd stickers by themselves and not packaged > with other products? No, the only way I've seen them sold is for $40 with a free OpenBSD CD. -- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc From owner-freebsd-current@FreeBSD.ORG Sat Apr 16 13:05:22 2005 Return-Path: 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 A19E316A4CE for ; Sat, 16 Apr 2005 13:05:22 +0000 (GMT) Received: from post-22.mail.nl.demon.net (post-22.mail.nl.demon.net [194.159.73.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A08443D48 for ; Sat, 16 Apr 2005 13:05:22 +0000 (GMT) (envelope-from jeffrey@hierwater.com) Received: from aschilperoord.demon.nl ([212.238.153.59]:59012 helo=jeffrey834d23f) by post-22.mail.nl.demon.net with esmtp (Exim 4.43) id 1DMmzA-0001xY-Vu for freebsd-current@freebsd.org; Sat, 16 Apr 2005 13:05:21 +0000 From: "Jeffrey" To: Date: Sat, 16 Apr 2005 15:05:23 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcVChPNIqrnBfzY/QhyTJ0SkLRwHpQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Message-Id: <20050416130522.1A08443D48@mx1.FreeBSD.org> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Can't get ata-mk3m.tar.gz X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 16 Apr 2005 13:05:22 -0000 HI, I have been trying to download the newest version of the ATA mkIII patches. But the files doesn't exist anymore on his website. Can anyone help me ? Greetings Jeffrey From owner-freebsd-current@FreeBSD.ORG Sat Apr 16 13:20:22 2005 Return-Path: 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 091B216A4CF for ; Sat, 16 Apr 2005 13:20:22 +0000 (GMT) Received: from mailgate.uni-paderborn.de (mailgate.uni-paderborn.de [131.234.22.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2483D43D55 for ; Sat, 16 Apr 2005 13:20:21 +0000 (GMT) (envelope-from arne@rfc2549.org) Received: from dsl-213-023-210-167.arcor-ip.net ([213.23.210.167] helo=[192.168.42.200]) by mailgate.uni-paderborn.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.43) id 1DMnDn-0001ua-G9; Sat, 16 Apr 2005 15:20:27 +0200 Message-ID: <42611105.5060708@rfc2549.org> Date: Sat, 16 Apr 2005 15:20:05 +0200 From: Arne Schwabe User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey References: <20050416130522.1A08443D48@mx1.FreeBSD.org> In-Reply-To: <20050416130522.1A08443D48@mx1.FreeBSD.org> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-UNI-PB_FAK-EIM-MailScanner-Information: Please see http://imap.uni-paderborn.de for details X-UNI-PB_FAK-EIM-MailScanner: Found to be clean X-UNI-PB_FAK-EIM-MailScanner-SpamCheck: not spam, SpamAssassin (score=-0.443, required 4, AUTH_EIM_USER -5.00, RCVD_IN_DSBL 2.77, RCVD_IN_NJABL_DUL 1.66, RCVD_IN_SORBS_DUL 0.14) X-MailScanner-From: arne@rfc2549.org cc: freebsd-current@freebsd.org Subject: Re: Can't get ata-mk3m.tar.gz X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 16 Apr 2005 13:20:22 -0000 Jeffrey wrote: >HI, > > > >I have been trying to download the newest version of the ATA mkIII patches. >But the files doesn't exist anymore on his website. Can anyone help me ? > > > > ATA mkIIII has been commited to current Arne From owner-freebsd-current@FreeBSD.ORG Sat Apr 16 13:51:07 2005 Return-Path: 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 5354416A4CE for ; Sat, 16 Apr 2005 13:51:07 +0000 (GMT) Received: from mailserv1.neuroflux.com (ns2.neuroflux.com [204.228.228.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id DEEF543D1D for ; Sat, 16 Apr 2005 13:51:06 +0000 (GMT) (envelope-from ryans@gamersimpact.com) Received: (qmail 58607 invoked by uid 1003); 16 Apr 2005 13:51:06 -0000 Received: from ryans@gamersimpact.com by mailserv1.neuroflux.com by uid 89 with qmail-scanner-1.22 (clamscan: 0.65. spamassassin: 2.60. Clear:RC:1(63.231.170.25):. Processed in 1.24885 secs); 16 Apr 2005 13:51:06 -0000 Received: from unknown (HELO ?192.168.0.5?) (63.231.170.25) by mailserv1.neuroflux.com with SMTP; 16 Apr 2005 13:51:04 -0000 Message-ID: <4261185D.1060202@gamersimpact.com> Date: Sat, 16 Apr 2005 08:51:25 -0500 From: Ryan Sommers User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thorsten Glaser References: <163.1113592094@natasha.tepid.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: tech@openbsd.org cc: freebsd-current@freebsd.org Subject: Re: strtonum(3) in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 16 Apr 2005 13:51:07 -0000 Thorsten Glaser wrote: > SI and IEC 60027-2 say: > > k = 1000 > M = 1000000 > m = 1/1000 > > K may so be 1024, but M may not, because M must be 1000000, > always. SI prefices are the same among all units. When talking about digital data storage K means times 2^10, M means times 2^20, G means 2^30 and T means 2^40. 1K = 1 * 2^10 bytes = 1024 bytes 1M = 1 * 2^20 bytes = 1048576 bytes 1G = 1 * 2^30 bytes = 1073741824 bytes If you think otherwise go google "what is a megabyte". Didn't you ever wonder why your computer with 512 megabytes of ram always showed 536870912 bytes? Or even hop on a FreeBSD box and do a: dd if=/dev/random of=bigfile bs=1 count=1M Watch as it reports "1048676 blocks in/out". -- Ryan Sommers ryans@gamersimpact.com From owner-freebsd-current@FreeBSD.ORG Sat Apr 16 14:01:25 2005 Return-Path: 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 2232516A4CE for ; Sat, 16 Apr 2005 14:01:25 +0000 (GMT) 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 578F143D1F for ; Sat, 16 Apr 2005 14:01:24 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.13.3/8.13.3) with ESMTP id j3GE1H0v010791; Sat, 16 Apr 2005 16:01:21 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <42611A45.7010006@DeepCore.dk> Date: Sat, 16 Apr 2005 15:59:33 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey References: <20050416130522.1A08443D48@mx1.FreeBSD.org> In-Reply-To: <20050416130522.1A08443D48@mx1.FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-mail-scanned: by DeepCore Virus & Spam killer v1.12 cc: freebsd-current@freebsd.org Subject: Re: Can't get ata-mk3m.tar.gz X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 16 Apr 2005 14:01:25 -0000 Jeffrey wrote: > HI, >=20 > =20 >=20 > I have been trying to download the newest version of the ATA mkIII patc= hes. > But the files doesn't exist anymore on his website. Can anyone help me = ? Actually the website isn't mine, its the FreeBSD projects... Anyhow, ATA mkIII has been committet to -current (and then some) so you dont need the patches there anymore. The latest version of the patches for 5-stable is ata-mk3l thats on http://people.freebsd.org/~sos/ATA as usual. --=20 -S=F8ren From owner-freebsd-current@FreeBSD.ORG Sat Apr 16 14:10:47 2005 Return-Path: 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 906E716A4CE for ; Sat, 16 Apr 2005 14:10:47 +0000 (GMT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.FreeBSD.org (Postfix) with SMTP id 28AF143D5D for ; Sat, 16 Apr 2005 14:10:46 +0000 (GMT) (envelope-from sthaug@nethelp.no) Received: (qmail 13593 invoked by uid 1001); 16 Apr 2005 14:10:44 -0000 To: ryans@gamersimpact.com From: sthaug@nethelp.no In-Reply-To: Your message of "Sat, 16 Apr 2005 08:51:25 -0500" References: <4261185D.1060202@gamersimpact.com> X-Mailer: Mew version 1.05+ on Emacs 19.34.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Sat, 16 Apr 2005 16:10:44 +0200 Message-ID: <13591.1113660644@bizet.nethelp.no> cc: tech@openbsd.org cc: freebsd-current@freebsd.org Subject: Re: strtonum(3) in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 16 Apr 2005 14:10:47 -0000 > > K may so be 1024, but M may not, because M must be 1000000, > > always. SI prefices are the same among all units. > > When talking about digital data storage K means times 2^10, M means > times 2^20, G means 2^30 and T means 2^40. > > 1K = 1 * 2^10 bytes = 1024 bytes > 1M = 1 * 2^20 bytes = 1048576 bytes > 1G = 1 * 2^30 bytes = 1073741824 bytes The disk drive manufacturers seem to disagree with you. For instance Seagate: http://www.seagate.com/products/discselect/glossary/index.html#cap "Most disc drive companies, including Seagate, calculate disc capacity based on the assumption that 1 megabyte = 1000 kilobytes and 1 gigabyte=1000 megabytes." My own conclusion is simply that there is no universal agreement which says that kilo, mega, giga and tera mean something different (using powers of 2) when applied to data storage. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-current@FreeBSD.ORG Sat Apr 16 14:27:07 2005 Return-Path: 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 C7AE516A4CE for ; Sat, 16 Apr 2005 14:27:07 +0000 (GMT) Received: from meisai.numachi.com (meisai.numachi.com [198.175.254.6]) by mx1.FreeBSD.org (Postfix) with SMTP id 0318443D1D for ; Sat, 16 Apr 2005 14:27:07 +0000 (GMT) (envelope-from reichert@numachi.com) Received: (qmail 2699 invoked from network); 16 Apr 2005 14:27:05 -0000 Received: from natto.numachi.com (198.175.254.216) by meisai.numachi.com with SMTP; 16 Apr 2005 14:27:05 -0000 Received: (qmail 55136 invoked by uid 1001); 16 Apr 2005 14:27:01 -0000 Date: Sat, 16 Apr 2005 10:27:01 -0400 From: Brian Reichert To: sthaug@nethelp.no Message-ID: <20050416142701.GO19606@numachi.com> References: <4261185D.1060202@gamersimpact.com> <13591.1113660644@bizet.nethelp.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <13591.1113660644@bizet.nethelp.no> User-Agent: Mutt/1.5.8i cc: ryans@gamersimpact.com cc: tech@openbsd.org cc: freebsd-current@freebsd.org Subject: Re: strtonum(3) in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 16 Apr 2005 14:27:07 -0000 On Sat, Apr 16, 2005 at 04:10:44PM +0200, sthaug@nethelp.no wrote: > My own conclusion is simply that there is no universal agreement which > says that kilo, mega, giga and tera mean something different (using > powers of 2) when applied to data storage. Some other discourse: http://en.wikipedia.org/wiki/Kibi > Steinar Haug, Nethelp consulting, sthaug@nethelp.no -- Brian Reichert 55 Crystal Ave. #286 Daytime number: (603) 434-6842 Derry NH 03038-1725 USA BSD admin/developer at large From owner-freebsd-current@FreeBSD.ORG Sat Apr 16 14:55:45 2005 Return-Path: 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 AB73216A4CE; Sat, 16 Apr 2005 14:55:45 +0000 (GMT) Received: from kane.otenet.gr (kane.otenet.gr [195.170.0.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0A4A43D2F; Sat, 16 Apr 2005 14:55:44 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from gothmog.gr (patr530-b193.otenet.gr [212.205.244.201]) j3GEsUUJ030320; Sat, 16 Apr 2005 17:54:30 +0300 Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.13.3/8.13.3) with ESMTP id j3GEtTK4000873; Sat, 16 Apr 2005 17:55:29 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from giorgos@localhost) by gothmog.gr (8.13.3/8.13.3/Submit) id j3GEtQCS000872; Sat, 16 Apr 2005 17:55:26 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Sat, 16 Apr 2005 17:55:26 +0300 From: Giorgos Keramidas To: David Xu Message-ID: <20050416145525.GA821@gothmog.gr> References: <425CC7F8.3030803@samsco.org> <425CD009.6040208@freebsd.org> <20050413132603.GA39006@orion.daedalusnetworks.priv> <20050413140838.GA77217@renaissance.homeip.net> <20050413141957.GA40546@orion.daedalusnetworks.priv> <20050415055604.N93987@lexi.siliconlandmark.com> <20050415164941.E93987@lexi.siliconlandmark.com> <4260D92C.1030703@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4260D92C.1030703@freebsd.org> cc: freebsd-current@freebsd.org cc: Jiawei Ye cc: Julian Elischer cc: Anthony Ginepro Subject: Re: How does one know how many thread a process owns? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 16 Apr 2005 14:55:45 -0000 On 2005-04-16 17:21, David Xu wrote: >>I realize that top isn't an exact science, but I find that >>approximations are generally a bad idea. I am in favor of axing the >>useless CPU column and reclaiming some useful screen space for the >>others... :) I considered that, but didn't know when or if the CPU column does make sense. > CPU column is not very useful when displaying process and thread > count, if it is only useful if it is displaying individual thread > which is activated by 'H' key. Thanks for that. This is good to know :-) Unfortunately, the current implementation of top makes it absurdly difficult to set up different "fields" for each mode that top supports; but it's ok, I'm already looking at ways to make all the visible columns configurable by the current mode. From owner-freebsd-current@FreeBSD.ORG Sat Apr 16 15:43:21 2005 Return-Path: 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 BCC3216A4CE for ; Sat, 16 Apr 2005 15:43:21 +0000 (GMT) Received: from post-23.mail.nl.demon.net (post-23.mail.nl.demon.net [194.159.73.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42E1243D58 for ; Sat, 16 Apr 2005 15:43:21 +0000 (GMT) (envelope-from jeffrey@hierwater.com) Received: from aschilperoord.demon.nl ([212.238.153.59]:49797 helo=jeffrey834d23f) by post-23.mail.nl.demon.net with esmtp (Exim 4.43) id 1DMpS4-000IMn-Bw for freebsd-current@freebsd.org; Sat, 16 Apr 2005 15:43:20 +0000 From: "Jeffrey" To: Date: Sat, 16 Apr 2005 17:43:23 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcVCmwWjirb8l1aiQfSHqXkrX/f0SA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Message-Id: <20050416154321.42E1243D58@mx1.FreeBSD.org> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: promise fasttrak tx 4200 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 16 Apr 2005 15:43:21 -0000 Does anyone know more about support for the promise fasttrak tx 4200? It isn't in the current. Greetings Jeffrey From owner-freebsd-current@FreeBSD.ORG Sat Apr 16 15:44:20 2005 Return-Path: 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 400A016A4CE; Sat, 16 Apr 2005 15:44:20 +0000 (GMT) Received: from rosebud.otenet.gr (rosebud.otenet.gr [195.170.0.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 331C443D48; Sat, 16 Apr 2005 15:44:19 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from gothmog.gr (patr530-b193.otenet.gr [212.205.244.201]) j3GFhEri031507; Sat, 16 Apr 2005 18:43:14 +0300 Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.13.3/8.13.3) with ESMTP id j3GFiDBM007357; Sat, 16 Apr 2005 18:44:13 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from giorgos@localhost) by gothmog.gr (8.13.3/8.13.3/Submit) id j3GFiCRo007356; Sat, 16 Apr 2005 18:44:12 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Sat, 16 Apr 2005 18:44:12 +0300 From: Giorgos Keramidas To: Andre Guibert de Bruet Message-ID: <20050416154412.GA7299@gothmog.gr> References: <425CC7F8.3030803@samsco.org> <425CD009.6040208@freebsd.org> <20050413132603.GA39006@orion.daedalusnetworks.priv> <425D2163.4090603@freebsd.org> <20050413140838.GA77217@renaissance.homeip.net> <20050413141957.GA40546@orion.daedalusnetworks.priv> <20050415055604.N93987@lexi.siliconlandmark.com> <20050415104814.GA5278@orion.daedalusnetworks.priv> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050415104814.GA5278@orion.daedalusnetworks.priv> cc: freebsd-current@freebsd.org cc: David Xu cc: Anthony Ginepro cc: Jiawei Ye Subject: Re: How does one know how many thread a process owns? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 16 Apr 2005 15:44:20 -0000 On 2005-04-15 13:48, Giorgos Keramidas wrote: >On 2005-04-15 06:02, Andre Guibert de Bruet wrote: >> Please commit the following patch which unbreaks the display problems >> which appear on 80-column terminals with the THR column (The D would wrap >> and cause weird behavior): >> >> http://bling.properkernel.com/freebsd/top.machine.c.patch > > This seems reasonable. I only have UP machines, which don't need the change > from COMMAND to CMD, but Andrey Chernov has already brought to my attention > that adding the THR column broke the listing in SMP machines. Should be fixed now. I shortened THR to 4 columns. From owner-freebsd-current@FreeBSD.ORG Sat Apr 16 16:49:15 2005 Return-Path: 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 15B0216A4CE for ; Sat, 16 Apr 2005 16:49:15 +0000 (GMT) Received: from mx.nsu.ru (mx.nsu.ru [212.192.164.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7851543D55 for ; Sat, 16 Apr 2005 16:49:14 +0000 (GMT) (envelope-from danfe@regency.nsu.ru) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.50) id 1DMqWn-0005vs-EG; Sat, 16 Apr 2005 23:52:17 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.13.3/8.13.1) with ESMTP id j3GGo6gB071848; Sat, 16 Apr 2005 23:50:06 +0700 (NOVST) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.13.3/8.13.1/Submit) id j3GGo009070790; Sat, 16 Apr 2005 23:50:00 +0700 (NOVST) (envelope-from danfe) Date: Sat, 16 Apr 2005 23:50:00 +0700 From: Alexey Dokuchaev To: sthaug@nethelp.no Message-ID: <20050416165000.GA69374@regency.nsu.ru> References: <4261185D.1060202@gamersimpact.com> <13591.1113660644@bizet.nethelp.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <13591.1113660644@bizet.nethelp.no> User-Agent: Mutt/1.4.2.1i cc: ryans@gamersimpact.com cc: tech@openbsd.org cc: freebsd-current@freebsd.org Subject: Re: strtonum(3) in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 16 Apr 2005 16:49:15 -0000 On Sat, Apr 16, 2005 at 04:10:44PM +0200, sthaug@nethelp.no wrote: > > > K may so be 1024, but M may not, because M must be 1000000, > > > always. SI prefices are the same among all units. > > > > When talking about digital data storage K means times 2^10, M means > > times 2^20, G means 2^30 and T means 2^40. > > > > 1K = 1 * 2^10 bytes = 1024 bytes > > 1M = 1 * 2^20 bytes = 1048576 bytes > > 1G = 1 * 2^30 bytes = 1073741824 bytes > > The disk drive manufacturers seem to disagree with you. For instance > Seagate: > > http://www.seagate.com/products/discselect/glossary/index.html#cap > > "Most disc drive companies, including Seagate, calculate disc capacity > based on the assumption that 1 megabyte = 1000 kilobytes and 1 > gigabyte=1000 megabytes." So their drives look bigger than they really are. Duh! ./danfe From owner-freebsd-current@FreeBSD.ORG Sat Apr 16 17:17:30 2005 Return-Path: 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 6636216A4CE for ; Sat, 16 Apr 2005 17:17:30 +0000 (GMT) Received: from smtp-vbr13.xs4all.nl (smtp-vbr13.xs4all.nl [194.109.24.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id C033943D39 for ; Sat, 16 Apr 2005 17:17:29 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) j3GHHRVk045294; Sat, 16 Apr 2005 19:17:27 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.13.3/8.12.9) with ESMTP id j3GHHRZe027310; Sat, 16 Apr 2005 19:17:27 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.13.3/8.13.1/Submit) id j3GHHQuf027309; Sat, 16 Apr 2005 19:17:26 +0200 (CEST) (envelope-from wb) Date: Sat, 16 Apr 2005 19:17:26 +0200 From: Wilko Bulte To: Alexey Dokuchaev Message-ID: <20050416171726.GA27283@freebie.xs4all.nl> References: <4261185D.1060202@gamersimpact.com> <13591.1113660644@bizet.nethelp.no> <20050416165000.GA69374@regency.nsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050416165000.GA69374@regency.nsu.ru> X-OS: FreeBSD 4.11-STABLE User-Agent: Mutt/1.5.6i X-Virus-Scanned: by XS4ALL Virus Scanner cc: ryans@gamersimpact.com cc: tech@openbsd.org cc: sthaug@nethelp.no cc: freebsd-current@freebsd.org Subject: Re: strtonum(3) in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 16 Apr 2005 17:17:30 -0000 On Sat, Apr 16, 2005 at 11:50:00PM +0700, Alexey Dokuchaev wrote.. > On Sat, Apr 16, 2005 at 04:10:44PM +0200, sthaug@nethelp.no wrote: > > > > K may so be 1024, but M may not, because M must be 1000000, > > > > always. SI prefices are the same among all units. > > > > > > When talking about digital data storage K means times 2^10, M means > > > times 2^20, G means 2^30 and T means 2^40. > > > > > > 1K = 1 * 2^10 bytes = 1024 bytes > > > 1M = 1 * 2^20 bytes = 1048576 bytes > > > 1G = 1 * 2^30 bytes = 1073741824 bytes > > > > The disk drive manufacturers seem to disagree with you. For instance > > Seagate: > > > > http://www.seagate.com/products/discselect/glossary/index.html#cap > > > > "Most disc drive companies, including Seagate, calculate disc capacity > > based on the assumption that 1 megabyte = 1000 kilobytes and 1 > > gigabyte=1000 megabytes." > > So their drives look bigger than they really are. Duh! Whether you like it or not, this is pretty much the industry standard in the storage industry. Not much option but to get used to it.. -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sat Apr 16 18:03:15 2005 Return-Path: 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 4623816A4CE for ; Sat, 16 Apr 2005 18:03:15 +0000 (GMT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2804743D58 for ; Sat, 16 Apr 2005 18:03:15 +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.50 (FreeBSD)) id 1DMrdQ-0004Oo-Fg; Sat, 16 Apr 2005 18:03:12 +0000 Received: from [127.0.0.1] (helo=roam.psg.com.psg.com) by roam.psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DMrdO-0001HO-Cn; Sat, 16 Apr 2005 08:03:10 -1000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16993.21341.792720.225462@roam.psg.com> Date: Sat, 16 Apr 2005 08:03:09 -1000 To: "Kevin Oberman" References: <20050415095629.W34838@carver.gumbysoft.com> <20050415213914.722B85D07@ptavv.es.net> cc: current@freebsd.org Subject: Re: Weird display problem in recent current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 16 Apr 2005 18:03:15 -0000 kevin, what was the last cvsup date which gave you a workable current on your thinkpad. i will revert to it and see if it addresses the inability to start my window system on a t41 randy From owner-freebsd-current@FreeBSD.ORG Sat Apr 16 18:33:13 2005 Return-Path: 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 0F91716A4CE for ; Sat, 16 Apr 2005 18:33:13 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.194.102.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id AAF4243D55 for ; Sat, 16 Apr 2005 18:33:12 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id D6BD652048; Sat, 16 Apr 2005 11:33:11 -0700 (PDT) Date: Sat, 16 Apr 2005 11:33:11 -0700 From: Kris Kennaway To: Doug White Message-ID: <20050416183311.GA61065@xor.obsecurity.org> References: <20050415195545.W38788@carver.gumbysoft.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MGYHOYXEY6WxJCY8" Content-Disposition: inline In-Reply-To: <20050415195545.W38788@carver.gumbysoft.com> User-Agent: Mutt/1.4.2.1i cc: 'FreeBSD Current' cc: Daniel Eriksson Subject: Re: task queue: supervisor write, page not present X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 16 Apr 2005 18:33:13 -0000 --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 15, 2005 at 07:56:50PM -0700, Doug White wrote: > On Fri, 15 Apr 2005, Daniel Eriksson wrote: >=20 > > Doug White wrote: > > > > > Can you get a crashdump and inspect the taskq with gdb? I'm assuming > > > there's a bogus entry thats getting tripped over. > > > > Dang, I was running low on space and removed the dump I had just a few = hours > > ago since nobody had replied yet. >=20 > Sorry, we don't guarantee 4 hour response -- that costs money. :) >=20 > > Right now I'm back to running CURRENT as of 2005.03.11.12.00.00 (over a > > month old) because I know it works pretty well for me. > > > > I'm not very good with gdb. Are there any specific steps I should take = to > > get the information needed to track this down (if I upgrade to latest > > CURRENT again)? Could this be related to me using a lot of r/w nullfs > > mounts? >=20 > I don't think so... nullfs has it sown problems, but not random memory > corruption. Actually r/w nullfs used to work in 5.x and 6.x (and r/o still does), so if someone is seeing otherwise they need to report it. Kris --MGYHOYXEY6WxJCY8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCYVpnWry0BWjoQKURAngjAJ9TlQOJgPPMf4v9WiWojLywmUnHEgCaAwUE ZrLkq/NMDYoiR1XPGLR6P00= =jyjP -----END PGP SIGNATURE----- --MGYHOYXEY6WxJCY8-- From owner-freebsd-current@FreeBSD.ORG Sat Apr 16 18:56:04 2005 Return-Path: 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 AF9A516A4CE for ; Sat, 16 Apr 2005 18:56:04 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id E4CA043D3F for ; Sat, 16 Apr 2005 18:56:03 +0000 (GMT) (envelope-from null@dnswatch.com) Received: from fast.dnswatch.com (localhost.dnswatch.com [127.0.0.1]) by fast.dnswatch.com (8.12.6/8.12.6) with ESMTP id j3GIu0sm096385 for ; Sat, 16 Apr 2005 11:56:03 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3GItxOq096384; Sat, 16 Apr 2005 11:55:59 -0700 (PDT) (envelope-from null@dnswatch.com) X-Authentication-Warning: fast.dnswatch.com: www set sender to null@dnswatch.com using -f Received: from mail.1command.com ([216.177.243.35]) (DNSwatch.com_WebMail authenticated user null) by webmail.dnswatch.com with HTTP; Sat, 16 Apr 2005 11:55:58 -0700 (PDT) Message-ID: <50589.216.177.243.35.1113677758.localmail@webmail.dnswatch.com> In-Reply-To: <13591.1113660644@bizet.nethelp.no> References: <4261185D.1060202@gamersimpact.com> <13591.1113660644@bizet.nethelp.no> Date: Sat, 16 Apr 2005 11:55:58 -0700 (PDT) From: "/dev/null" To: freebsd-current@freebsd.org User-Agent: DNSwatch.com_WebMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Subject: Re: strtonum(3) in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 16 Apr 2005 18:56:04 -0000 >> > K may so be 1024, but M may not, because M must be 1000000, >> > always. SI prefices are the same among all units. >> >> When talking about digital data storage K means times 2^10, M means >> times 2^20, G means 2^30 and T means 2^40. >> >> 1K = 1 * 2^10 bytes = 1024 bytes >> 1M = 1 * 2^20 bytes = 1048576 bytes >> 1G = 1 * 2^30 bytes = 1073741824 bytes > > The disk drive manufacturers seem to disagree with you. For instance > Seagate: > > http://www.seagate.com/products/discselect/glossary/index.html#cap > > "Most disc drive companies, including Seagate, calculate disc capacity > based on the assumption that 1 megabyte = 1000 kilobytes and 1 > gigabyte=1000 megabytes." > I don't know about you. But have you ever noticed how the capacity of your drive as reported by the manufacturers suddenly shrank after formatting it? Point being, they have always used the one which reported the *larger* capacity. ;) In short; the standard is... there is no standard. :) -Chris > My own conclusion is simply that there is no universal agreement which > says that kilo, mega, giga and tera mean something different (using > powers of 2) when applied to data storage. > > Steinar Haug, Nethelp consulting, sthaug@nethelp.no > _______________________________________________ > 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" > //////////////////////////////////////////////////// If only Western Electric had found a way to offer binary licenses for the UNIX system back in 1974, the UNIX system would be running on all PC's today rather than DOS/Windows. //////////////////////////////////////////////////// From owner-freebsd-current@FreeBSD.ORG Sat Apr 16 19:38:08 2005 Return-Path: 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 474FA16A4CE for ; Sat, 16 Apr 2005 19:38:08 +0000 (GMT) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3494443D48 for ; Sat, 16 Apr 2005 19:38:07 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [192.168.42.22] (andersonbox2.centtech.com [192.168.42.22]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id j3GJc6nx008885 for ; Sat, 16 Apr 2005 14:38:06 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <42616975.9060303@centtech.com> Date: Sat, 16 Apr 2005 14:37:25 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050325 X-Accept-Language: en-us, en MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: gstat shows > 100% busy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 16 Apr 2005 19:38:08 -0000 Is gstat supposed to show > 100% sometimes? What does that mean, or is it a bug? dT: 0.501 flag_I 500000us sizeof 240 i -1 L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name 2 260 146 14912 10.7 114 14565 2.8 148.1| ad0 0 0 0 0 0.0 0 0 0.0 0.0| ad0s1 2 260 146 14912 10.7 114 14565 2.9 148.2| ad0s2 0 0 0 0 0.0 0 0 0.0 0.0| ad0s3 0 0 0 0 0.0 0 0 0.0 0.0| ad0s4 1 146 146 14912 10.7 0 0 0.0 146.2| ad0s2a 0 0 0 0 0.0 0 0 0.0 0.0| ad0s2b 0 0 0 0 0.0 0 0 0.0 0.0| ad0s2c 1 114 0 0 0.0 114 14565 2.9 31.8| ad0s2d 0 0 0 0 0.0 0 0 0.0 0.0| ad0s5 0 0 0 0 0.0 0 0 0.0 0.0| ad0s6 uname: FreeBSD neutrino.centtech.com 6.0-CURRENT FreeBSD 6.0-CURRENT #14: Fri Apr 15 13:59:39 CDT 2005 i386 dmesg snippets: atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xbfa0-0xbfaf irq 9 at device 31.2 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xbfa0 ata0: on atapci0 ... ad0: 76319MB at ata0-master UDMA100 ad0: 156301488 sectors [155061C/16H/63S] 16 sectors/interrupt 1 depth queue Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology A lost ounce of gold may be found, a lost moment of time never. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Sat Apr 16 19:42:22 2005 Return-Path: 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 06A4116A4CE for ; Sat, 16 Apr 2005 19:42:22 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.194.102.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC49D43D46 for ; Sat, 16 Apr 2005 19:42:21 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id F0B7451355; Sat, 16 Apr 2005 12:42:19 -0700 (PDT) Date: Sat, 16 Apr 2005 12:42:19 -0700 From: Kris Kennaway To: Eric Anderson Message-ID: <20050416194219.GA77361@xor.obsecurity.org> References: <42616975.9060303@centtech.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="X1bOJ3K7DJ5YkBrT" Content-Disposition: inline In-Reply-To: <42616975.9060303@centtech.com> User-Agent: Mutt/1.4.2.1i cc: FreeBSD Current Subject: Re: gstat shows > 100% busy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 16 Apr 2005 19:42:22 -0000 --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 16, 2005 at 02:37:25PM -0500, Eric Anderson wrote: > Is gstat supposed to show > 100% sometimes? What does that mean, or is i= t=20 > a bug? The stats aren't 100% accurate over short times. On SMP machines you can also see negative values for some of them due to races. Kris --X1bOJ3K7DJ5YkBrT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCYWqbWry0BWjoQKURAtrRAJ48jQbMrXRq6yRMZwocvECdK7m1HgCfe4nw a7o00fKxmbTB9pc8qe7oPx4= =vgUI -----END PGP SIGNATURE----- --X1bOJ3K7DJ5YkBrT-- From owner-freebsd-current@FreeBSD.ORG Sat Apr 16 19:42:43 2005 Return-Path: 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 A1CA316A4CE for ; Sat, 16 Apr 2005 19:42:43 +0000 (GMT) Received: from gate.bitblocks.com (bitblocks.com [209.204.185.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59E2543D1F for ; Sat, 16 Apr 2005 19:42:43 +0000 (GMT) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost [127.0.0.1]) by gate.bitblocks.com (8.13.3/8.13.1) with ESMTP id j3GJgSxg088850; Sat, 16 Apr 2005 12:42:29 -0700 (PDT) (envelope-from bakul@bitblocks.com) Message-Id: <200504161942.j3GJgSxg088850@gate.bitblocks.com> To: Wilko Bulte In-reply-to: Your message of "Sat, 16 Apr 2005 19:17:26 +0200." <20050416171726.GA27283@freebie.xs4all.nl> Date: Sat, 16 Apr 2005 12:42:28 -0700 From: Bakul Shah cc: ryans@gamersimpact.com cc: Alexey Dokuchaev cc: tech@openbsd.org cc: sthaug@nethelp.no cc: freebsd-current@freebsd.org Subject: Re: strtonum(3) in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 16 Apr 2005 19:42:43 -0000 > > > > When talking about digital data storage K means times 2^10, M means > > > > times 2^20, G means 2^30 and T means 2^40. > > > > > > > > 1K = 1 * 2^10 bytes = 1024 bytes > > > > 1M = 1 * 2^20 bytes = 1048576 bytes > > > > 1G = 1 * 2^30 bytes = 1073741824 bytes > > > > > > The disk drive manufacturers seem to disagree with you. For instance > > > Seagate: > > > > > > http://www.seagate.com/products/discselect/glossary/index.html#cap > > > > > > "Most disc drive companies, including Seagate, calculate disc capacity > > > based on the assumption that 1 megabyte = 1000 kilobytes and 1 > > > gigabyte=1000 megabytes." > > > > So their drives look bigger than they really are. Duh! Disk vendors' use is actually what the SI (International System of Units) people prefer. They want G to mean 10^9 s and *not* 2^30 s regardless of what is being measured/counted. > Whether you like it or not, this is pretty much the industry standard > in the storage industry. Not much option but to get used to it.. Or we can all start using metric unit prefixes for decimal and binary numbers and there'd be no ambiguity. Right now even within the computer industry what a G means depends on what is being measured and who is doing the measuring. The IEC 27-2 and IEEE 1541-2002 binary prefixes are: factor Symbol Name Origin 2^10 Ki kibi kilobinary 2^20 Mi mibi megabinary 2^30 Gi gibi gigabinary 2^40 Ti tebi terabinary 2^50 Pi pebi petabinary 2^60 Ei exbi exabinary See http://physics.nist.gov/cuu/Units/binary.html http://www.cofc.edu/~frysingj/binprefixes.html http://www.cl.cam.ac.uk/~mgk25/metric-system-faq.txt From owner-freebsd-current@FreeBSD.ORG Sat Apr 16 19:46:54 2005 Return-Path: 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 C9A4F16A4CE for ; Sat, 16 Apr 2005 19:46:54 +0000 (GMT) Received: from pfepc.post.tele.dk (pfepc.post.tele.dk [195.41.46.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B3F243D45 for ; Sat, 16 Apr 2005 19:46:54 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (0x50a07c69.naenxx7.adsl-dhcp.tele.dk [80.160.124.105]) by pfepc.post.tele.dk (Postfix) with ESMTP id C3BFC262814 for ; Sat, 16 Apr 2005 21:46:52 +0200 (CEST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.3/8.13.3) with ESMTP id j3GJkpBj003704; Sat, 16 Apr 2005 21:46:52 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Eric Anderson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 16 Apr 2005 14:37:25 CDT." <42616975.9060303@centtech.com> Date: Sat, 16 Apr 2005 21:46:51 +0200 Message-ID: <3703.1113680811@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: FreeBSD Current Subject: Re: gstat shows > 100% busy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 16 Apr 2005 19:46:54 -0000 In message <42616975.9060303@centtech.com>, Eric Anderson writes: >Is gstat supposed to show > 100% sometimes? What does that mean, >or is it a bug? > >dT: 0.501 flag_I 500000us sizeof 240 i -1 > L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name > 2 260 146 14912 10.7 114 14565 2.8 148.1| ad0 > 0 0 0 0 0.0 0 0 0.0 0.0| ad0s1 The reason gstat shows >100% busy is that there are some outstanding requests. (the 2 in the left hand column). I tried to make the statistics collection as cheap as possible, and as a side effect some of the columns can be somewhat misleading. The length of the queue "L(q)" can be plain wrong due to a race in updating the counters and %busy can go over 100% while there are outstanding requests. The sysctl kern.geom.collectstats can be used to tune some aspects of the statistics collection, but the %busy issue is just something you have to live with. The reason why I don't want to spend cpu time on the %busy field is that it is useless as a performance indication for all modern disks and most ancient ones as well. The "ms/r" and "ms/w" give you the time it takes to send a transaction through (in milliseconds, for read and write respectively) and those are the numbers you should monitor. -- 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 Sat Apr 16 19:55:14 2005 Return-Path: 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 CC69116A4CE for ; Sat, 16 Apr 2005 19:55:14 +0000 (GMT) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09A0143D41 for ; Sat, 16 Apr 2005 19:55:14 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [192.168.42.22] (andersonbox2.centtech.com [192.168.42.22]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id j3GJtCRj041839 for ; Sat, 16 Apr 2005 14:55:12 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <42616D77.2070205@centtech.com> Date: Sat, 16 Apr 2005 14:54:31 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050325 X-Accept-Language: en-us, en MIME-Version: 1.0 To: FreeBSD Current References: <3703.1113680811@critter.freebsd.dk> In-Reply-To: <3703.1113680811@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/833/Fri Apr 15 21:31:36 2005 on mh1.centtech.com X-Virus-Status: Clean Subject: Re: gstat shows > 100% busy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 16 Apr 2005 19:55:14 -0000 Poul-Henning Kamp wrote: > In message <42616975.9060303@centtech.com>, Eric Anderson writes: > > >>Is gstat supposed to show > 100% sometimes? What does that mean, >>or is it a bug? >> >>dT: 0.501 flag_I 500000us sizeof 240 i -1 >> L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name >> 2 260 146 14912 10.7 114 14565 2.8 148.1| ad0 >> 0 0 0 0 0.0 0 0 0.0 0.0| ad0s1 > > > The reason gstat shows >100% busy is that there are some outstanding > requests. (the 2 in the left hand column). > > I tried to make the statistics collection as cheap as possible, and > as a side effect some of the columns can be somewhat misleading. Makes perfect sense, and I was thinking that was the case. I love how fast and non-cpu intensive it is. I use this tool like *crazy* on my servers. Thanks for writing it! > The length of the queue "L(q)" can be plain wrong due to a race in > updating the counters and %busy can go over 100% while there are > outstanding requests. > > The sysctl kern.geom.collectstats can be used to tune some aspects > of the statistics collection, but the %busy issue is just something > you have to live with. > > The reason why I don't want to spend cpu time on the %busy field > is that it is useless as a performance indication for all modern > disks and most ancient ones as well. Why is that? I have a general notion, but I'd like to know more details. If this is documented somewhere, just give me a pointer and I'll read away. > The "ms/r" and "ms/w" give you the time it takes to send a transaction > through (in milliseconds, for read and write respectively) and those > are the numbers you should monitor. Thanks! I've been reading man pages and such trying to figure out what else is cool I'm missing. I just happened to stumble into the tool while messing with ggate (another really awesome tool). Is there a place to grab those stats in a more 'script friendly' way? I am the author of a (rather cheesy) tool called bsdsar, and I'm thinking about updating it with all the new cool 5.X-isms. Thanks for the quick responses! Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology A lost ounce of gold may be found, a lost moment of time never. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Sat Apr 16 20:55:13 2005 Return-Path: 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 C58DA16A4CE; Sat, 16 Apr 2005 20:55:13 +0000 (GMT) Received: from ylpvm43.prodigy.net (ylpvm43-ext.prodigy.net [207.115.57.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 482D443D2F; Sat, 16 Apr 2005 20:55:13 +0000 (GMT) (envelope-from julian@elischer.org) Received: from pimout2-ext.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101])j3GKtEl8009681; Sat, 16 Apr 2005 16:55:14 -0400 X-ORBL: [68.124.205.128] Received: from [192.168.2.2] (adsl-68-124-205-128.dsl.snfc21.pacbell.net [68.124.205.128])j3GKt6cU427820; Sat, 16 Apr 2005 16:55:06 -0400 Message-ID: <42617BA9.8070101@elischer.org> Date: Sat, 16 Apr 2005 13:55:05 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050214 X-Accept-Language: en, hu MIME-Version: 1.0 To: David Xu References: <425CC7F8.3030803@samsco.org> <425CD009.6040208@freebsd.org> <20050413132603.GA39006@orion.daedalusnetworks.priv> <20050413140838.GA77217@renaissance.homeip.net> <20050413141957.GA40546@orion.daedalusnetworks.priv> <20050415055604.N93987@lexi.siliconlandmark.com> <425FA2AB.4070905@freebsd.org><425FFCF1.1080100@elischer.org> <20050415164941.E93987@lexi.siliconlandmark.com> <4260D92C.1030703@freebsd.org> In-Reply-To: <4260D92C.1030703@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: Jiawei Ye cc: Anthony Ginepro cc: Giorgos Keramidas Subject: Re: How does one know how many thread a process owns? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 16 Apr 2005 20:55:13 -0000 David Xu wrote: > Andre Guibert de Bruet wrote: > >> >> On Fri, 15 Apr 2005, Julian Elischer wrote: >> >>> Giorgos Keramidas wrote: >>> >>>> On 2005-04-15 19:16, David Xu wrote: >>>> >>>> I just checked what top does on SunOS, when a program has more than 999 >>>> threads and it seems to clip the number of threads to 999, as if >>>> something min(999, numthreads) is what is printed :-) >>> >>> >>> >>> you could proint " !!!" or "LOT" >>> or do a roman numeral approx. >>> e.g. MMC (2100).. what's roman for 10000? >>> or 2E4 :-) >> >> >> >> I realize that top isn't an exact science, but I find that >> approximations are generally a bad idea. I am in favor of axing the >> useless CPU column and reclaiming some useful screen space for the >> others... :) >> >> Andy >> >> | Andre Guibert de Bruet | Enterprise Software Consultant > >> | Silicon Landmark, LLC. | http://siliconlandmark.com/ > > > > > CPU column is not very useful when displaying process and > thread count, if it is only useful if it is displaying individual > thread which is activated by 'H' key. > > David Xu CPU and thread count column could be shared [CPU] )[1] [2] [3] ...[99] could be CPUnum.. that implies 1 thread 2..9999 is a thread count when H mode is on, then we just show [CPUNUM] wnen not we show [CPUNUM] or threadcount. From owner-freebsd-current@FreeBSD.ORG Sat Apr 16 21:05:24 2005 Return-Path: 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 9F1E416A4CE for ; Sat, 16 Apr 2005 21:05:24 +0000 (GMT) Received: from pfepa.post.tele.dk (pfepa.post.tele.dk [195.41.46.235]) by mx1.FreeBSD.org (Postfix) with ESMTP id 29E8F43D1F for ; Sat, 16 Apr 2005 21:05:24 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (0x50a07c69.naenxx7.adsl-dhcp.tele.dk [80.160.124.105]) by pfepa.post.tele.dk (Postfix) with ESMTP id 86F7347FEB2 for ; Sat, 16 Apr 2005 23:05:22 +0200 (CEST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.3/8.13.3) with ESMTP id j3GL5HiD004282; Sat, 16 Apr 2005 23:05:18 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Eric Anderson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 16 Apr 2005 14:54:31 CDT." <42616D77.2070205@centtech.com> Date: Sat, 16 Apr 2005 23:05:17 +0200 Message-ID: <4281.1113685517@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: FreeBSD Current Subject: Re: gstat shows > 100% busy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 16 Apr 2005 21:05:24 -0000 In message <42616D77.2070205@centtech.com>, Eric Anderson writes: >> The reason why I don't want to spend cpu time on the %busy field >> is that it is useless as a performance indication for all modern >> disks and most ancient ones as well. > >Why is that? I have a general notion, but I'd like to know more details. If >this is documented somewhere, just give me a pointer and I'll read away. Busy says how big a fraction of the time the disk had an outstanding request, but that doesn't tell you how much more traffic it would be able to sneak in without affecting the throughput of the current traffik. If you had a process doing essentially: while (1) { read_sector(0); write_sector(N-1); } That would give you 100% disk busy. But you can throw a lot more traffic at the disk without affecting (the abysmal) performance you already see, for instance you can probably read the first and last tracks of the disks for 100% free. The trouble is that %busy says something about how much of the time the disk had something to do, but says nothing about how much more the disk could have accomplished in the same time. >> The "ms/r" and "ms/w" give you the time it takes to send a transaction >> through (in milliseconds, for read and write respectively) and those >> are the numbers you should monitor. These on the other hand are what people really care about: how fast (or slow) will it be to access the disk. If you run a disk benchmark you will notice that the service time has seismographic sensitivity, run a stupid access pattern and it explodes into the 100s of milliseconds. >Is there a place to grab those stats in a more 'script friendly' >way? I am the author of a (rather cheesy) tool called bsdsar, and >I'm thinking about updating it with all the new cool 5.X-isms. Go for it. There is a pretty simple API to pull it out of the kernel, check the gstat source. -- 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 Sat Apr 16 21:31:46 2005 Return-Path: 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 B96BE16A4CE; Sat, 16 Apr 2005 21:31:45 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 520F443D1F; Sat, 16 Apr 2005 21:31: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 j3GLViGK067013; Sat, 16 Apr 2005 17:31: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 j3GLVx7m012967; Sat, 16 Apr 2005 17:31:59 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 9A08C7306E; Sat, 16 Apr 2005 17:31:44 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050416213144.9A08C7306E@freebsd-current.sentex.ca> Date: Sat, 16 Apr 2005 17:31:44 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.82, clamav-milter version 0.82 on clamscanner1 X-Virus-Status: Clean Subject: [current tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2005 21:31:46 -0000 TB --- 2005-04-16 19:51:01 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-16 19:51:01 - starting CURRENT tinderbox run for i386/pc98 TB --- 2005-04-16 19:51:02 - checking out the source tree TB --- 2005-04-16 19:51:02 - cd /home/tinderbox/CURRENT/i386/pc98 TB --- 2005-04-16 19:51:02 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-16 19:57:50 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-16 19:57:50 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2005-04-16 19:57:50 - /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-04-16 21:05:23 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-16 21:05:23 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2005-04-16 21:05:23 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Apr 16 21:05:23 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 Sat Apr 16 21:20:10 UTC 2005 TB --- 2005-04-16 21:20:10 - generating LINT kernel config TB --- 2005-04-16 21:20:10 - cd /home/tinderbox/CURRENT/i386/pc98/src/sys/pc98/conf TB --- 2005-04-16 21:20:10 - /usr/bin/make -B LINT TB --- 2005-04-16 21:20:10 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-16 21:20:10 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2005-04-16 21:20:10 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Apr 16 21:20:11 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 [...] : undefined reference to `drm_debug_flag' sis_mm.o(.text+0x992): more undefined references to `drm_debug_flag' follow tdfx_drv.o(.text+0x8c): In function `tdfx_probe': : undefined reference to `drm_probe' tdfx_drv.o(.text+0xe8): In function `tdfx_attach': : undefined reference to `drm_attach' tdfx_drv.o(.data+0x48): undefined reference to `drm_devclass' tdfx_drv.o(.data+0x94): undefined reference to `drm_detach' *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. TB --- 2005-04-16 21:31:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-16 21:31:44 - ERROR: failed to build lint kernel TB --- 2005-04-16 21:31:44 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sat Apr 16 21:45:49 2005 Return-Path: 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 8B65B16A4CE for ; Sat, 16 Apr 2005 21:45:49 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 303F043D2D for ; Sat, 16 Apr 2005 21:45:49 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.3) id j3GLjla3089651; Sat, 16 Apr 2005 16:45:47 -0500 (CDT) (envelope-from dan) Date: Sat, 16 Apr 2005 16:45:47 -0500 From: Dan Nelson To: Poul-Henning Kamp Message-ID: <20050416214547.GS4842@dan.emsphone.com> References: <42616D77.2070205@centtech.com> <4281.1113685517@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4281.1113685517@critter.freebsd.dk> X-OS: FreeBSD 5.4-PRERELEASE X-message-flag: Outlook Error User-Agent: Mutt/1.5.8i cc: FreeBSD Current cc: Eric Anderson Subject: Re: gstat shows > 100% busy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 16 Apr 2005 21:45:49 -0000 In the last episode (Apr 16), Poul-Henning Kamp said: > In message <42616D77.2070205@centtech.com>, Eric Anderson writes: > >> The "ms/r" and "ms/w" give you the time it takes to send a > >> transaction through (in milliseconds, for read and write > >> respectively) and those are the numbers you should monitor. > > These on the other hand are what people really care about: how fast > (or slow) will it be to access the disk. If you run a disk benchmark > you will notice that the service time has seismographic sensitivity, > run a stupid access pattern and it explodes into the 100s of > milliseconds. > > >Is there a place to grab those stats in a more 'script friendly' > >way? I am the author of a (rather cheesy) tool called bsdsar, and > >I'm thinking about updating it with all the new cool 5.X-isms. > > Go for it. There is a pretty simple API to pull it out of the > kernel, check the gstat source. Also see the devstat manpage and the source to iostat. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Sat Apr 16 22:03:29 2005 Return-Path: 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 B836D16A4CE for ; Sat, 16 Apr 2005 22:03:29 +0000 (GMT) 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 E799143D49 for ; Sat, 16 Apr 2005 22:03:28 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.13.3/8.13.3) with ESMTP id j3GM3MhY015878; Sun, 17 Apr 2005 00:03:26 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <42618B42.2020107@DeepCore.dk> Date: Sun, 17 Apr 2005 00:01:38 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey References: <20050416154321.42E1243D58@mx1.FreeBSD.org> In-Reply-To: <20050416154321.42E1243D58@mx1.FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-mail-scanned: by DeepCore Virus & Spam killer v1.12 cc: freebsd-current@freebsd.org Subject: Re: promise fasttrak tx 4200 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 16 Apr 2005 22:03:29 -0000 Jeffrey wrote: > Does anyone know more about support for the promise fasttrak tx 4200? I= t > isn't in the current. It should be supported in current, but it might be the have yet another=20 chipid for this than the one I've got. Could you provide me with the=20 output from pciconf -l from the system with it ? --=20 -S=F8ren From owner-freebsd-current@FreeBSD.ORG Sat Apr 16 22:10:50 2005 Return-Path: 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 38D5916A4CE for ; Sat, 16 Apr 2005 22:10:50 +0000 (GMT) Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBA7843D5E for ; Sat, 16 Apr 2005 22:10:49 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: from sentinel (195.198.193.104) by pne-smtpout2-sn2.hy.skanova.net (7.1.026.7) id 41E3223E00C708A6; Sun, 17 Apr 2005 00:10:48 +0200 From: "Daniel Eriksson" To: "'FreeBSD Current'" Date: Sun, 17 Apr 2005 00:11:13 +0200 Organization: Home Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <20050416183311.GA61065@xor.obsecurity.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcVCss4jCG2ykhiJS1eaCbhRUUqDdgAHYdkg cc: 'Kris Kennaway' Subject: RE: task queue: supervisor write, page not present X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 16 Apr 2005 22:10:50 -0000 Kris Kennaway wrote: > Actually r/w nullfs used to work in 5.x and 6.x (and r/o still does), > so if someone is seeing otherwise they need to report it. I've been using r/w nullfs mounts for the last 9+ months and haven't noticed any problems before, so they probably still work just fine. The only reason I asked the question was that one of the crashes I had happened while I was copying files to a nullfs mount (and the video server constantly reads from one or more nullfs mounts). /Daniel Eriksson From owner-freebsd-current@FreeBSD.ORG Sat Apr 16 23:02:12 2005 Return-Path: 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 EE66B16A4CE for ; Sat, 16 Apr 2005 23:02:12 +0000 (GMT) Received: from pinus.cc.fer.hr (pinus.cc.fer.hr [161.53.73.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 099EE43D5A for ; Sat, 16 Apr 2005 23:02:12 +0000 (GMT) (envelope-from ivoras@fer.hr) Received: from [161.53.72.113] (lara.cc.fer.hr [161.53.72.113]) by pinus.cc.fer.hr (8.12.2/8.12.2) with ESMTP id j3GN2qhE009479; Sun, 17 Apr 2005 01:02:53 +0200 (MEST) Message-ID: <4261996A.2030204@fer.hr> Date: Sun, 17 Apr 2005 01:02:02 +0200 From: Ivan Voras User-Agent: Mozilla Thunderbird 1.0 (X11/20041213) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Poul-Henning Kamp , current@freebsd.org References: <42616975.9060303@centtech.com> <3703.1113680811@critter.freebsd.dk> In-Reply-To: <3703.1113680811@critter.freebsd.dk> Content-Type: multipart/mixed; boundary="------------020703080201030807020200" Subject: Re: gstat shows > 100% busy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 16 Apr 2005 23:02:13 -0000 This is a multi-part message in MIME format. --------------020703080201030807020200 Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Poul-Henning Kamp wrote: > The reason gstat shows >100% busy is that there are some outstanding > requests. (the 2 in the left hand column). > > I tried to make the statistics collection as cheap as possible, and > as a side effect some of the columns can be somewhat misleading. Could it be (for reasons of prettyfication) clipped to [0-100] range? Something like in the attached? --------------020703080201030807020200 Content-Type: text/plain; name="patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch" --- gstat_ori.c Sun Apr 17 00:45:32 2005 +++ gstat.c Sun Apr 17 00:59:44 2005 @@ -51,6 +51,7 @@ static int flag_I = 500000; static void usage(void); +static double clip_double(double x, double min, double max); int main(int argc, char **argv) @@ -209,7 +210,7 @@ else i = 1; attron(COLOR_PAIR(i)); - printw(" %6.1lf", (double)ld[7]); + printw(" %6.1lf", clip_double((double)ld[7], 0, 100)); attroff(COLOR_PAIR(i)); printw("|"); if (gid == NULL) { @@ -264,3 +265,18 @@ exit(1); /* NOTREACHED */ } + + +/* + * Clip a double value to [min..max] + */ +static double +clip_double(double x, double min, double max) +{ + if (x > max) + return max; + if (x < min) + return min; + return x; +} + --------------020703080201030807020200--